From ghc-devs at haskell.org Mon May 1 00:00:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 00:00:14 -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.b7f97bbf915c2276fe4b645da0561304@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 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): GHC certainly retains information about modules it has finished compiling in `--make` mode, by design--the information it wrote to the interface file, and would read back from the interface file if needed. It has "always" worked this way, though of course it's possible that the space usage of this retained data has increased, or that there is other data being retained unintentionally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 00:07:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 00:07:19 -0000 Subject: [GHC] #10675: GHC does not check the functional dependency consistency condition correctly In-Reply-To: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> References: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> Message-ID: <061.62cab129c28ebf4a0276345a39d4d2db@haskell.org> #10675: GHC does not check the functional dependency consistency condition correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: FunDeps Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well let's please not continue using the word "undecidable" to have anything to do with the coverage conditions. I can't imagine it was originally anything but an oversight to have `UndecidableInstances` completely disable the coverage conditions. `UndecidableInstances` is supposed to be just about termination of instance search. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 00:08:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 00:08:20 -0000 Subject: [GHC] #13604: ghci no longer loads dynamic .o files by default if they were built with -O (was: regression in ghc 8.2.1-rc1 (8.2.0.20170404)) In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.324e8493bd669537d48627b0908cce54@haskell.org> #13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 00:11:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 00:11:45 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.d269584c8014dae3c597776c5d09a6f6@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The need to access the type from a finalizer seems a bit roundabout and restrictive. Of course you can't access the quote's type from within the expansion of the quasiquote for causality reasons, but what about a type class and typed quasiquotes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 00:13:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 00:13:50 -0000 Subject: [GHC] #13577: Compiler performance on open-symbology parser module regressed in GHC 8.2 In-Reply-To: <046.8370c5a51cf6fd43771bbc3f135011a3@haskell.org> References: <046.8370c5a51cf6fd43771bbc3f135011a3@haskell.org> Message-ID: <061.931275419ef19e1219b288557dff3e40@haskell.org> #13577: Compiler performance on open-symbology parser module regressed in GHC 8.2 -------------------------------------+------------------------------------- Reporter: bgamari | 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: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I don't understand the title and version number of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 00:15:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 00:15:09 -0000 Subject: [GHC] #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope In-Reply-To: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> References: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> Message-ID: <065.e122653e78750683e026f6742a3c0afb@haskell.org> #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: mpickering Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3515 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): > The problem is that name clash errors are reported too eagerly. I guess you must know what you are talking about, but this sounds weird to me since I can't see what name clash there is in the original program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 00:16:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 00:16:59 -0000 Subject: [GHC] #13577: Compiler performance on open-symbology parser module regressed in GHC 8.2 In-Reply-To: <046.8370c5a51cf6fd43771bbc3f135011a3@haskell.org> References: <046.8370c5a51cf6fd43771bbc3f135011a3@haskell.org> Message-ID: <061.9a3bf4e3dff223acd6a1ec24c131d669@haskell.org> #13577: Compiler performance on open-symbology parser module regressed in GHC 8.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 01:27:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 01:27:50 -0000 Subject: [GHC] #13632: Frontend plugin arguments are reversed Message-ID: <043.ec28fd3dbabc434a0844f0f3787cf432@haskell.org> #13632: Frontend plugin arguments are reversed -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: frontend01 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The arguments passed to a frontend plugin are passed in the opposite order to that with which they were passed to the command line. I will attach a diff that modifies the frontend01 test to exhibit the error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 01:28:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 01:28:09 -0000 Subject: [GHC] #13632: Frontend plugin arguments are reversed In-Reply-To: <043.ec28fd3dbabc434a0844f0f3787cf432@haskell.org> References: <043.ec28fd3dbabc434a0844f0f3787cf432@haskell.org> Message-ID: <058.204173cd09cc1e9320d71a6582349582@haskell.org> #13632: Frontend plugin arguments are reversed -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: frontend01 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "frontend-opts-bug.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 02:06:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 02:06:35 -0000 Subject: [GHC] #13577: Compiler performance on open-symbology parser module regressed in GHC 8.2 In-Reply-To: <046.8370c5a51cf6fd43771bbc3f135011a3@haskell.org> References: <046.8370c5a51cf6fd43771bbc3f135011a3@haskell.org> Message-ID: <061.03b76d41e9e8656e0b8fe0c8ad8621fe@haskell.org> #13577: Compiler performance on open-symbology parser module regressed in GHC 8.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 8.0.1 => 8.2.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 02:12:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 02:12:42 -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.4aaed5d2a76df16550c185c5767adbef@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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: kavon (added) Comment: Kavon, I noticed you mentioned evaluating which LLVM optimizations passes are worthwhile in ticket:10074#comment:25. This is the ticket I created a while back to track this. Feel free to leave notes here when you end up picking this up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 02:14:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 02:14:59 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.c1c1111b33b333213eb754f87b645bab@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: angerman Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Comment (by angerman): My current plan is to do [opt +] clang, and having opt disabled by default, until someone has the time to investigate different opt configurations. Piping opt to llc, would still incur serialization and deserialization overhead. My current standpoint is, that unless we explicitly gain something by using opt + clang or opt + llc right now, I'd rather have a dumb and simple solution. Regarding LTO, I believe we can do LTO at the bitcode level with `llvm- link` and `opt`. However this would need to be explored, and until done so, I'd rather have a simple solution. The opt+llc -> clang diff I posted to phabricator clamps the `-O` in `[1,3]`. Such that we always get mem2reg; the current design doesn't allow to trivially pass `-Os` I'm afraid, as ghc expects `-O` to be numeric. In general clang doesn't really handle `opt` or `llc` flags or passes them down properly. There are supposed to be some escape hatches but afaict they do not cover all cases. Thus we'd be left with what clang offers. Yet again I'd like to stress the point that someone would need to seriously take ownership of the opt/llc code, ensure that all the hacks are still necessary, that opt and llc flags match up, and ensure that they work with new llvm version. While bundling llvm would lessen the need to care for the latter, I imagine we'd still want to upgrade llvm from time to time? What I hope to be able to complete this year is: - simplify the llvm logic: replacing opt+llc with opt+clang or clang for the time being - integrating the Data.BitCode modules to directly generate BitCode IR (without so much aliasing) from GHC - try to see if we can teach GHC that BitCode is a valid object like format. The last point being essential to use llvm-link. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 02:15:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 02:15:06 -0000 Subject: [GHC] #13632: Frontend plugin arguments are reversed In-Reply-To: <043.ec28fd3dbabc434a0844f0f3787cf432@haskell.org> References: <043.ec28fd3dbabc434a0844f0f3787cf432@haskell.org> Message-ID: <058.42d0756a7fecd56d1d2847b776fffdcd@haskell.org> #13632: Frontend plugin arguments are reversed -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: frontend01 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Comment: Thanks for the test! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 02:16:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 02:16:38 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.0ad6c4371848957ba0fc5e5bc7d5d8a4@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: angerman Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Comment (by angerman): I forgot to mention that getting rid of the mangler is also essential in a pure BitCode pipeline, as the mangler operates at the assembly level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 02:33:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 02:33:28 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.55c4dacbb56830e5c816ddffdef9a43c@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: linker Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * cc: angerman (added) * keywords: => linker * milestone: => 8.4.1 Comment: Wow, I didn't know that. That is terrible! My understanding is that the linker (at least in the case of ELF) actually maps sections incorrectly anyways: We ought to be using the object file's segments, not sections, for the purposes of mapping. This will likely reduce the number of mappings we need to setup, and allow us to set the correct RWX access control bits (e.g. currently we map code as writable, which is rather terrifying from a security perspective). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 02:46:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 02:46:46 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.0202df5f953fece1f57e442ed663f3fa@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: linker Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): For what it's worth the macho/aarch64 does this already, and elf/armv7, elf/aarch64 linker will do it. They essentially requests memory via mmap, and memcpy the data per section; this makes sections being page aligned, which I believe satisfies most alignment requirements. An additional check wouldn't hurt though. However we can't use segments, as segments can contain multiple sections that are not bound to the same type. A segment can contain data and text section; which in turn need to live in different pages for them to be properly mprotected. This then means we can't mmap segments. However what we could try to reduce memory footprint is to aggregate text and data sections across object files. Of course mmap + memcpy is slower than directly mmapping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 02:56:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 02:56:59 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.671dad290b9a42d00ce313b75be290b7@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: linker Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, each segment has an associated set of permission flags. IIRC, two sections of mapping characteristics won't end up in the same segment. However, we nevertheless can't use segments for an unrelated reason: only executables and shared objects are organized into segments. Our runtime linker is only concerned with object files, which have no useful segment organizations AFAIK. Oh well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 03:21:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 03:21:43 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.753c4b867fdaa5cd4919b97d409d88c2@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: stage1/T13609 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3496 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => stage1/T13609 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 05:01:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 05:01:20 -0000 Subject: [GHC] #13378: LLVM backend doesn't support MacOS dead code stripping (was: ghc-stage2 broken for quick-llvm) In-Reply-To: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> References: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> Message-ID: <062.d0ba653f3a6d663c35060bb70e0d9568@haskell.org> #13378: LLVM backend doesn't support MacOS dead code stripping -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Retitling issue in view of comment:8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 06:22:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 06:22:39 -0000 Subject: [GHC] #13564: Why does memory usage increase so much during CoreTidy? In-Reply-To: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> References: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> Message-ID: <062.aa6be169e5b49d777c4318d1fb0a5210@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3516 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => patch * differential: => Phab:D3516 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 08:30:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 08:30:38 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.f174cda51ffe54d9162a464d5fd881a3@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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 michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 08:47:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 08:47:40 -0000 Subject: [GHC] #13633: testwsdeque failure on POWER8 Message-ID: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> #13633: testwsdeque failure on POWER8 ---------------------------------------+---------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Keywords: SMP | Operating System: Linux Architecture: powerpc64 | Type of failure: Runtime crash Test Case: rts/testwsdeque | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+---------------------------------- On a POWER8 `testwsdeque` fails occasionally under load: {{{ Wrong exit code for testwsdeque(threaded1)(expected 0 , actual 134 ) Stderr ( testwsdeque ): internal error: FAIL: 277808608 3 13 (GHC version 8.3.20170430 for powerpc64le_unknown_linux) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 08:58:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 08:58:48 -0000 Subject: [GHC] #13634: num009 fails on POWER8 Message-ID: <047.91c77b7baae4e3fa8bc1163d9b8de491@haskell.org> #13634: num009 fails on POWER8 -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.1 libraries/base | Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Incorrect result Test Case: | at runtime libraries/base/tests/Numeric/num009| Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le: {{{ +uh oh! tanf 1.5707964 +-2.2877334e7 +-2.2877332e7 +(-11438667,1) +(-11438666,1) Done }}} The test passes on a PowerPC 970MP (PowerMac G5) running openSUSE 13.2 powerpc64 (big endian). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 12:20:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 12:20:12 -0000 Subject: [GHC] #13635: Incorrect result at runtime with list comprehensions in that case Message-ID: <044.1a958e7cc7f5a3b23c2bee2563d56889@haskell.org> #13635: Incorrect result at runtime with list comprehensions in that case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 1. With GHC 8.0.2\\ {{{ Prelude> [x | x <- [_, _], False] :1:12: error: * Found hole: _ :: t Where: `t' is a rigid type variable bound by the inferred type of it :: [t] at :1:1 * In the expression: _ In the expression: [_, _] In a stmt of a list comprehension: x <- [_, _] * Relevant bindings include it :: [t] (bound at :1:1) :1:15: error: * Found hole: _ :: t Where: `t' is a rigid type variable bound by the inferred type of it :: [t] at :1:1 * In the expression: _ In the expression: [_, _] In a stmt of a list comprehension: x <- [_, _] * Relevant bindings include it :: [t] (bound at :1:1) Prelude>\\ }}} This result makes no sense here.\\ The result will always be the empty list [].\\ 2. With GHC 7.6.3\\ {{{ Prelude> [x | x <- [_, _], False] :2:12: Pattern syntax in expression context: _ :2:12: Pattern syntax in expression context: _ Prelude> }}} This result also makes no sense here.\\ Similarly this result will always be the empty list []. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 14:17:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 14:17:50 -0000 Subject: [GHC] #13636: Enable -Wcpp-undef Message-ID: <046.158ec470c576ad7ea7046a8ce856111c@haskell.org> #13636: Enable -Wcpp-undef -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- e5b3492f23c2296d0d8221e1787ee585331f726e tried (again) to enable `-Wcpp- undef` in `mk/warnings.mk`, {{{#!make SRC_HC_OPTS_STAGE1 += $(WERROR) #-Wcpp-undef SRC_HC_OPTS_STAGE2 += $(WERROR) #-Wcpp-undef }}} Unfortunately, this caused build failures in boot libraries on some platforms (e.g. `time` on Darwin). Resolve these and reenable `-Wcpp- undef`. An alternative would be to instead only add `-Wcpp-undef` to `GhcRtsHcOpts`, `GhcStage1HcOpts` and `GhcStage2HcOpts`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 14:18:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 14:18:04 -0000 Subject: [GHC] #13636: Enable -Wcpp-undef In-Reply-To: <046.158ec470c576ad7ea7046a8ce856111c@haskell.org> References: <046.158ec470c576ad7ea7046a8ce856111c@haskell.org> Message-ID: <061.e7dbe736d7652a5c375430db07d4a8fd@haskell.org> #13636: Enable -Wcpp-undef -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 8.1 => 8.3 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 14:52:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 14:52:16 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.558203ee995697111e08dd4b1a98d2b1@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: stage1/T13609 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3496 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7567b9ddba7c4304e8d0226e9bf82a054f37ce91/ghc" 7567b9dd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7567b9ddba7c4304e8d0226e9bf82a054f37ce91" Ignore ANN pragmas with no TH and no external interpreter. Reviewers: hvr, austin, bgamari, RyanGlScott Reviewed By: bgamari Subscribers: angerman, RyanGlScott, rwbarton, thomie GHC Trac Issues: #13609 Differential Revision: https://phabricator.haskell.org/D3496 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 14:52:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 14:52:16 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.bff05c25acd65812b3e562b8fdffe101@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: stage1/T13609 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3496 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"18fbb9d32cbc157e3bbd235e392f1625f77321e3/ghc" 18fbb9d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="18fbb9d32cbc157e3bbd235e392f1625f77321e3" testsuite: Add test for #13609 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 15:10:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 15:10:43 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.af453f7cf6827cacbe09caa2ffd1dc6c@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: stage1/T13609 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3496 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c04bd55a8daaf254436cef02934215d0b4ccfa2f/ghc" c04bd55a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c04bd55a8daaf254436cef02934215d0b4ccfa2f" Fix capitalization in message for #13609 I had meant to do this before merging but forgot. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 15:29:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 15:29:28 -0000 Subject: [GHC] #13635: Incorrect result at runtime with list comprehensions in that case In-Reply-To: <044.1a958e7cc7f5a3b23c2bee2563d56889@haskell.org> References: <044.1a958e7cc7f5a3b23c2bee2563d56889@haskell.org> Message-ID: <059.014346efe81e1908cf07053d56876652@haskell.org> #13635: Incorrect result at runtime with list comprehensions in that case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): And with `-fdefer-typed-holes`, you get the behavior that you want. (But be aware of [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #deferred-type-errors-in-ghci this restriction] about deferred type errors and GHCi.) I argue that GHC's behavior in both cases is correct. As the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #typed-holes manual] says, a hole terminates compilation without `-fdefer- typed-holes`. So the GHC 8.0.2 behavior agrees with the specification. As there were no typed holes in GHC 7.6.3, a `_` in an expression really is invalid syntax, so terminating with an error is appropriate there, too. With `-fdefer-typed-holes`, you will still get warnings about the holes in your code. But you can suppress these with `-Wno-typed-holes`. My guess is that `{-# OPTIONS_GHC -fdefer-typed-holes -Wno-typed-holes #-}` will get you exactly the behavior you want. If you agree with this analysis, please close the ticket. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 15:40:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 15:40:41 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.ba2e45ea4bfdb9028528d36460537d55@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: angerman Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Comment (by kavon): > Yet again I'd like to stress the point that someone would need to seriously take ownership of the opt/llc code, ensure that all the hacks are still necessary, that opt and llc flags match up, and ensure that they work with new llvm version. I'll take ownership of all of these things! > As the Imrpoved LLVM Proposal was about bundling llvm with ghc, to have better control over the llvm backend, bundling clang (or if we really must opt+llc) looks to me like the way to go. Bundling a customized clang is '''not''' the way to go. Clang is just the C/C++ frontend for LLVM, and we lose control over LLVM by trying to access it through clang... how will we use any of our customizations? If we want to write our own IR optimization/analysis passes, we would end up exposing the flag to run it via opt... hacking up clang to access the pass is much harder! I also would like to stress that we cannot rely on the system's version of clang. For example, on OS X the default clang is built against Apple's LLVM, whose source code is unknown. The opt/llc obtained by package managers are always the open-source version. > Regarding LTO, I believe we can do LTO at the bitcode level with llvm- link and opt. Yes, I'm quite certain that's all you do, and I'd be willing to look into this. It really shouldn't be too difficult. --- Overall, I still don't see good motivation for moving to opt/clang instead of opt/llc, other than an attempt to reduce compilation time. If I missed something in the prior discussion please forgive me. If compilation time with LLVM is very important, I think there are more profitable ways of reducing it than using clang: Here are the timings I'm seeing on a GHC produced 2.6MB LLVM IR file (the Move module from the mate benchmark) with a Debug build of LLVM 5 with assertions on, so these times ''are'' inflated in unknown ways: `opt -time-passes -O1 Move.ll | llc -O1 -time-passes -o blah.s` 1.08 seconds were spent by `opt` parsing the textual LLVM IR we generated. `opt` spent 0.19 seconds emitting bitcode, and `llc` spent 0.16 seconds parsing it, so 0.35 seconds between `opt` and `llc`. The total time spent to complete that pipeline was 18.15 seconds, so 2% of this time is owed to bitcode serialization between `opt` and `llc`, whereas 6% is owed to parsing textual LLVM IR from GHC. This doesn't include the time spent by GHC emitting the textual IR too! Thus, to reduce compile times, I think it would make more sense to either generate LLVM bitcode, or switch to using Haskell bindings for LLVM to access the API directly. Neither of these are small tasks, but I think they're better for us in the long-run. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 15:46:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 15:46:13 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.09e0c1af60e11b4239f52fa8093470b7@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest Comment: I think we should regard this as highest as it breaks existing stream fusion users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 15:56:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 15:56:57 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.983054e46da63a562457f7276dfa91b2@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: angerman Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Comment (by angerman): Well, I'm all for someone to ensure that opt and llc work. That's fantastic! I never intend to actually customize much of clang, opt or llc. However if we run into cases again where we have upstream patches that are needed, and have even been merged, but there has no llvm release been cut, we will need to have some form of customized interim binary. As you said it is unknown if apples clang *is* identical or not and which customization have been applied. I would still hope we will be able to ideally use the systems provided clang at some point. Which of course won't work if we need opt, and that is not provided. If we end up flat our refusing to use apples clang on ideological grounds, and apple ends up customizing their clang to the point where you are required to use their clang, or won't be able to take play in their walled garden, do we want to make that sacrifice? This of course is hypothetical. I would though stay away from ever generating any assembly, and have llvm produce object code directly, either via opt+llc, or opt+clang or clang. Ideally it should be .bc -> [llvm blackbox which allows us to pass flags where and how we need it] -> .o Switching to haskell bindings for LLVM has been no option for various reasons. I don't know if this stand has ever changed. Due to this though, I do have a pure haskell bitcode generator (https://github.com/angerman/data-bitcode, https://github.com/angerman /data-bitcode-llvm, ...) these are by no means complete, the plugin I have can compile and link trivial haskell programs; I do plan on integrating them into ghc, without the plugin approach, as that requires a significant amount of rewriting the plugin interface in ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 16:29:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 16:29:35 -0000 Subject: [GHC] #13564: Why does memory usage increase so much during CoreTidy? In-Reply-To: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> References: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> Message-ID: <062.777a06c510c0fbe8bd0987086d225763@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3516 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5c602d2228d28530621cc6c94fbb736b13f474fb/ghc" 5c602d22/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5c602d2228d28530621cc6c94fbb736b13f474fb" Avoid excessive space usage from unfoldings in CoreTidy Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie GHC Trac Issues: #13564 Differential Revision: https://phabricator.haskell.org/D3516 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 16:34:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 16:34:37 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.23b86b135e3e1f2e17a3f59705a54e9b@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: stage1/T13609 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3496 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 944630400117acdf2f97759b7ed8678e8d6cdf92, f8d909ba2ab9ccc89cf59a1097d78da8f82c793f, and f8d909ba2ab9ccc89cf59a1097d78da8f82c793f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 16:45:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 16:45:54 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.9e203b7abb7fc135b48c06851b967f5f@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "LoopReduced2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 16:46:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 16:46:15 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.d7786e630120cb9b9c5ce8e04d61c7d2@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "mainReduced2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 16:46:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 16:46:35 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.bbc3d8f89686a5fef408b11f1e303c90@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "dumpbefore.tgz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 16:46:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 16:46:54 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.7849051a8ae7e4ce2e78bed2fcab6dea@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "dumpafter.tgz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 16:55:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 16:55:15 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.d04fcfcccfcb6941d616403747aa1eab@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I reduced the test case again. See `LoopReduced2.hs` and `mainReduced2.hs` (you'll have to rename the `LoopReduced2.hs` file to `Loop.hs` to compile). I attached `-dverbose-core2core` results before and after the early inlining patch as `dumpbefore.tgz` and `dumpafter.tgz`. I haven't figured out where things go wrong just yet, but if you look at `dumpbefore/main.dump-simpl`, you'll see {{{#!hs Rec { -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} Main.$s$fArrayXe_$dNum [Occ=LoopBreaker] :: Num Word8 [GblId, Str=b] Main.$s$fArrayXe_$dNum = Main.$s$fArrayXe_$dNum end Rec } }}} which is very obviously very bad. For some reason we're "optimizing" a dictionary into a reference to itself! My vague guess is that GHC sees that it can get a `Num Word8` dictionary from an `Array` or `ColorSpace` dictionary, and that it can get `ColorSpace` and `Array` dictionaries from `Num` ones, and makes some very bad decisions. I have no idea why the early inline patch fixes this, but I'm rather nervous about it being a proper fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 16:59:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 16:59:31 -0000 Subject: [GHC] #13310: Cut a new array release In-Reply-To: <046.78a1c6814a975bd87284888ceb2402ce@haskell.org> References: <046.78a1c6814a975bd87284888ceb2402ce@haskell.org> Message-ID: <061.f53674f3060758127cd6538fcc446dbb@haskell.org> #13310: Cut a new array release -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): As of f7b69e9cb914cb69bbede5264729523fb8669db1 I believe the tree is ready for release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 17:10:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 17:10:18 -0000 Subject: [GHC] #13635: Incorrect result at runtime with list comprehensions in that case In-Reply-To: <044.1a958e7cc7f5a3b23c2bee2563d56889@haskell.org> References: <044.1a958e7cc7f5a3b23c2bee2563d56889@haskell.org> Message-ID: <059.0feb2336a9e0942e79373052a5536865@haskell.org> #13635: Incorrect result at runtime with list comprehensions in that case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Hello goldfire,\\ yes, I agree with you. It is not a bug. However this behavior is irrational. Reason has disappeared, good sense no longer exists.\\ See ticket #13557.\\ In this ticket simonpj said " I think this is correct behaviour".\\ Yes simonpj, this behavior is correct since you coded it as well! The compiler is stupid, where is the good sense? \\ It is because this good sense did not appear in GHC 7.6.3 that this continues. The compiler would have a better behavior, with more good sense, if "typed holes" was set off as of launch, I think.\\ If you want to comment before I close the ticket, thank you. Soon I open a new feature request ticket to repeat this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 17:52:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 17:52:35 -0000 Subject: [GHC] #13635: Incorrect result at runtime with list comprehensions in that case In-Reply-To: <044.1a958e7cc7f5a3b23c2bee2563d56889@haskell.org> References: <044.1a958e7cc7f5a3b23c2bee2563d56889@haskell.org> Message-ID: <059.473bbb5b034ac36ef881de231e5b0306@haskell.org> #13635: Incorrect result at runtime with list comprehensions in that case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): vanto, why, concretely, do you think this is irrational? In general it is impossible for the compiler to know whether any given subexpression of your program will be evaluated. Consequently, we make no effort to adjust error messages for reachability (except when reachability can be determined by type information, e.g. pattern matching on a GADT). Typed holes are intended to be an aid to development and really shouldn't be found in production code. GHC's default behavior, like that of most compilers, is to assume the user is compiling for a production setting. The compiler's default treatment of typed holes reflects this. If you want the program to compile despite holes then we offer `-fdefer-typed-holes`. If you feel like this default should be changed then perhaps we can discuss this, but I'll admit I'm rather skeptical. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 18:20:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 18:20:06 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.61d12a32cf3be1dd565e9e414a490a58@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "LoopReduced3.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 18:20:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 18:20:40 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.a46ff58300a5cab742d34b1da073cdec@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "dump-before3.tgz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 18:35:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 18:35:47 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.6b3a2808bbc7b9c779c510e96f3a839c@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I've reduced it once more. I believe the fundamental problem here happens in specialization. We get {{{ Rec { -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} $dArray_s1RC :: Array X Word8 [LclId] $dArray_s1RC = Loop.$fArrayXe @ Word8 GHC.Word.$fNumWord8 -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} $dArray1_s1RG [Occ=OnceL] :: Array X Word8 [LclId] $dArray1_s1RG = Loop.$fArrayXe @ Word8 $dNum_s1RH -- RHS size: {terms: 2, types: 2, coercions: 0, joins: 0/0} $dNum_s1RH :: Num Word8 [LclId] $dNum_s1RH = Loop.$p1Array @ X @ Word8 $dArray_s1RC -- RHS size: {terms: 7, types: 5, coercions: 0, joins: 0/0} $s$fArrayXe_s1RS [InlPrag=CONLIKE] :: Array X Word8 [LclId, Unf=DFun: \ -> Loop.C:Array TYPE: X TYPE: Word8 Loop.$fArrayXe_$cp1Array @ Word8 $dNum_s1RH Loop.$fArrayXe_$cpromote @ Word8 $dNum_s1RH Loop.$fArrayXe_$cmakeImage @ Word8 $dNum_s1RH] $s$fArrayXe_s1RS = Loop.C:Array @ X @ Word8 (Loop.$fArrayXe_$cp1Array @ Word8 $dNum_s1RH) (Loop.$fArrayXe_$cpromote @ Word8 $dNum_s1RH) (Loop.$fArrayXe_$cmakeImage @ Word8 $dNum_s1RH) ... }}} which doesn't seem ''inherently'' bad (although it's not very clean), but then we also get this rather awful specialization rule: {{{ "SPEC/Main $fArrayXe @ Word8" forall (v_s1RJ :: Num Word8). Loop.$fArrayXe @ Word8 v_s1RJ = $s$fArrayXe_s1RS }}} If this rule fires in the RHS of `$dArray_s1RC`, then we get {{{ $dArray_s1RC = $s$fArrayXe_s1RS }}} Inlining that into `$dNum_s1RH` gives {{{ $dNum_s1RH = Loop.$p1Array @ X @ Word8 $s$fArrayXe_s1RS }}} But `$dNum_s1RH` is used in the definition of `$s$fArrayXe_s1RS`, so we have a loop. I don't know if I've told exactly the right story here, but I think the real story is probably pretty similar. The results will be excruciatingly fragile, depending on whether the right or wrong specialization rule fires. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 18:58:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 18:58:31 -0000 Subject: [GHC] #8443: cannot find normal object file when compiling TH code In-Reply-To: <047.2f61f8c2ce8e4b4c9fecbd7d2a24e60d@haskell.org> References: <047.2f61f8c2ce8e4b4c9fecbd7d2a24e60d@haskell.org> Message-ID: <062.fd620bb89e58139cb8fc0e2f78477baa@haskell.org> #8443: cannot find normal object file when compiling TH code -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | 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 nh2): 2 years later, some insight on *why* `other-extensions: TemplateHaskell` helps here: > thoughtpolice: -dynamic-too is sort of designed to not have too much overhead but it's a giant shitshow how it works > > In short, it will only re-run the assembler, mostly, since it 'just' has to change some stuff like relocations, etc in the backend for a shared object. It used to not be so easy on windows; the way it's implemented is a hack. > > And yeah, Cabal does use the knowledge of TemplateHaskell to know when to turn on -dynamic-too automatically for GHC, so it will build shared object files, which it can link in the background and load in GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 19:14:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 19:14:36 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "LoopReduced3.hs" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 19:14:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 19:14:36 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.52aa4c663ee9671db64492714eab06f7@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "LoopReduced3.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 19:30:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 19:30:18 -0000 Subject: [GHC] #12075: Fails to build on powerpcspe because of inline assembly In-Reply-To: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> References: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> Message-ID: <062.ceee2cea58206c4882e33516032a8551@haskell.org> #12075: Fails to build on powerpcspe because of inline assembly ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Comment (by glaubitz): So, this actually seems to be fairly easy to fix but I cannot come up with a satisfiable patch. Basically, we just need to disable rts/AdjustorAsm.S in rts/ghc.mk if the C compiler defines {{{__NO_FPRS__}}}. When this macro is defined, the CPU is using FPU emulation instead of a hardware FPU, so basically the same as for ARM soft-float. Looking at the main {{{ghc.mk}}}, it does something similar for ARM but it actually defines a Haskell constructor with "SOFT" defined for armABI in case of FPU emulation. Can someone more familiar with the build system suggest a patch which I can test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 20:38:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 20:38:20 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.72e15f7986edece6ffaec07799c5c629@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:12 heisenbug]: > Copying a use-case from #9196: > > My point is that I'd like to have polymorphic (multiparameter) constraints, where the param universally abstracted over is a non-`*` kind, that is an ADT. > > See: > {{{ > class Foo a where ... > data Bar (b :: Bool) x = ... > instance Foo (Bar True x) where ... > instance Foo (Bar False x) where ... > > test :: (forall b. Foo (Bar b x)) =>... > }}} > Here the `forall` condition is satisfiable, as all `Bool` alternatives are covered with `instance` declarations. Actually, the `forall` condition is ''not'' satisfiable. The smaller problem is that stuck type families like `Any` can inhabit `Bool` without being `'True` or `'False`. The bigger problem is that Haskell's "logic" is inherently constructive. The claim that for any type `b :: Bool` there exists some instance `Foo b x` does not translate to a way to actually get the dictionary representing that instance. So I think your beautiful dream is, sadly, almost certainly unrealizable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 20:59:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 20:59:21 -0000 Subject: [GHC] #13635: Incorrect result at runtime with list comprehensions in that case In-Reply-To: <044.1a958e7cc7f5a3b23c2bee2563d56889@haskell.org> References: <044.1a958e7cc7f5a3b23c2bee2563d56889@haskell.org> Message-ID: <059.3f44668bda2f505c22a2694777309d7d@haskell.org> #13635: Incorrect result at runtime with list comprehensions in that case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: new => closed * resolution: => invalid Comment: Hello bgamari,\\ Thank you all for your views. Well from my point of view it is best not to have Typed holes activated by default. It is preferable to let the programmer activate it if needed. Enable it by default, It's like putting the cart before the horses.\\ But it is a minor matter.\\ Good sense is common to every person and sometimes is difficult to explain.\\ I close the ticket and will not open new feature request.\\ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 1 21:50:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 May 2017 21:50:54 -0000 Subject: [GHC] #12075: Fails to build on powerpcspe because of inline assembly In-Reply-To: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> References: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> Message-ID: <062.da07a2e9769352b9f5255627f1701d4c@haskell.org> #12075: Fails to build on powerpcspe because of inline assembly ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Comment (by bgamari): glaubitz, see Phab:D3519 for a sketch of such a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 00:23:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 00:23:00 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.ca9d6f91f87b05d842ae4fedf8a5fb74@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So David and I discussed this a bit and I suspect that the loop arises as early as typechecking. David summarized quite well above, but I thought I might try to recap to make sure I also understand. Recall that the minimized example has the following, {{{#!hs module Loop where data X class Num e => Array cs e where ... instance Num e => Array X e where ... module Main where import Loop {- some bindings requiring an Array X Word8 instance -} }}} The output from the desugarer is nothing special, containing a local dictionary binding for `Array X Word8`, {{{#!hs -- main.dump-ds $dArray_a1zv :: Array X Word8 $dArray_a1zv = Loop.$fArrayXe @Word8 GHC.Word.$fNumWord8 }}} The specialiser then takes this and sees the `Loop.$fArrayXe` DFun from the `Array X e` instance and tries to specialise it. This results in, {{{#!hs $dArray_s1BE :: Array X Word8 $dArray_s1BE = Loop.$fArrayXe @Word8 GHC.Word.$fNumWord8 $s$fArrayXe_s1BU [InlPrag=[ALWAYS] CONLIKE] :: Array X Word8 $s$fArrayXe_s1BU = Loop.C:Array @ X @ Word8 (Loop.$fArrayXe_$cp1Array @Word8 $dNum_s1BJ) (Loop.$fArrayXe_$cpromote @Word8 $dNum_s1BJ) (Loop.$fArrayXe_$cmakeImage @Word8 $dNum_s1BJ) $dNum_s1BJ :: Num Word8 $dNum_s1BJ = Loop.$p1Array @X @Word8 $dArray_s1BE -- N.B. $p1Array is a selector for Array's Num superclass {- Rules: "SPEC/Main $fArrayXe @Word8" [ALWAYS] forall ($dNum_s1BL :: Num Word8). Loop.$fArrayXe @Word8 $dNum_s1BL = $s$fArrayXe_s1BU -} }}} As David pointed out above, this introduces a rather problematic rule. It's problematic because it will rewrite `$dArray_s1BE`, which introduces the concrete `fNumWord8` dictionary into our local `Array X Word8` dictionary. It will rewrite `$dArray_s1BE` in terms of `$s$fArrayXe_s1BU`, which has no mention of any concrete `Num` dictionary, instead pulling it out of `$dArray_s1BE` via a superclass selector. This is clearly a bad situation: the specialiser has introduced a loop where there was none previously. It's not entirely obvious how to pin down what is "bad" about this rule, but the fact that it throws away a dictionary argument is certainly relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 00:37:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 00:37:34 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.628b9d570fe4bddf49b4c46e38a6386c@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | 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: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by glguy): I believe I was experiencing this same bug in code that used Foreign.Marshal.Unsafe.unsafeLocalState and par together https://github.com/glguy/kami-solver/blob/master/src/Kami.hs#L172-L181 unsafeLocalState is defined as unsafeDupablePerformIO. Switching to unsafePerformIO (which adds the noDuplicate) resolved the random segmentation faults. I'm just adding this comment here in case it becomes useful at some point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 02:33:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 02:33:04 -0000 Subject: [GHC] #13564: Why does memory usage increase so much during CoreTidy? In-Reply-To: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> References: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> Message-ID: <062.82802bf17f56613f1ecd15101b4978c3@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3516 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Merged with fc2236e8db7550287e764d90410a002b02c55180. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 02:55:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 02:55:49 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.23febb53b55b3302e78c281d99d3726f@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => dfeuer Comment: How is this going, David? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 02:58:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 02:58:36 -0000 Subject: [GHC] #13515: Unexpected failure of T11223_simple_duplicate_lib on 32-bit Windows In-Reply-To: <046.085d5d4204c467ff87c6d5281d72775d@haskell.org> References: <046.085d5d4204c467ff87c6d5281d72775d@haskell.org> Message-ID: <061.0c27f705ecd979485796f054abefb09b@haskell.org> #13515: Unexpected failure of T11223_simple_duplicate_lib on 32-bit Windows ---------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Alright, then there's no reason this needs to happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 02:59:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 02:59:35 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.7abf519585f3d40d810c4a5729b36383@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: I'm going to bump the remainder of this ticket off to 8.4 unless you object, niteria. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 03:04:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 03:04:30 -0000 Subject: [GHC] #11959: Importing doubly exported pattern synonym and associated pattern synonym panics In-Reply-To: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> References: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> Message-ID: <061.d1aff7cba48bfcf3b3b826cb18444156@haskell.org> #11959: Importing doubly exported pattern synonym and associated pattern synonym panics -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1-rc3 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:D2132, Wiki Page: | Phab:D2133 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.2.2 Comment: At this point this isn't really a regression. Bumping off to 8.2.2 since we have bigger issues to handle for the already-late 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 03:23:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 03:23:52 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.7edf1788bbc3e10dd8b2b47f68833634@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I've just confirmed that my in-flight patches fix this. I've added a regression test to that patch set. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 06:46:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 06:46:59 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.5eb6f247c23c73fd8a0263fa33948f50@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 Phab:D3523 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * differential: Phab:D3382 Phab:D3383 => Phab:D3382 Phab:D3383 Phab:D3523 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 07:01:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 07:01:52 -0000 Subject: [GHC] #13633: testwsdeque failure on POWER8 In-Reply-To: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> References: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> Message-ID: <062.38df2a388d5e7918c9387de40898c08e@haskell.org> #13633: testwsdeque failure on POWER8 -----------------------------------+--------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: SMP Operating System: Linux | Architecture: powerpc64 Type of failure: Runtime crash | Test Case: rts/testwsdeque Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------------- Comment (by simonmar): This is bad and suggests that either we're using the wrong barriers in the implementation, or the implementation of the barriers is wrong for POWER8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 09:04:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 09:04:50 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.5fb8641bafcdc4d45c24e72608a06a1d@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 Phab:D3523 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: Phyx- => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 09:06:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 09:06:38 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.ce975c873d59df83e1153c9909b80018@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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): Phab:3391 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Fair enough. Shall we close this, then? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 11:10:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 11:10:10 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.190199af297a3869a1fc1322bfc93359@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9e47dc451788cce20acb6a8208c56a7e4dbe246b/ghc" 9e47dc45/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9e47dc451788cce20acb6a8208c56a7e4dbe246b" Fix loss-of-SpecConstr bug This bug, reported in Trac #13623 has been present since commit b8b3e30a6eedf9f213b8a718573c4827cfa230ba Author: Edward Z. Yang Date: Fri Jun 24 11:03:47 2016 -0700 Axe RecFlag on TyCons. SpecConstr tries not to specialise indefinitely, and had a limit (see Note [Limit recursive specialisation]) that made use of info about whether or not a data constructor was "recursive". This info vanished in the above commit, making the limit fire much more often -- and indeed it fired in this test case, in a situation where specialisation is /highly/ desirable. I refactored the test, to look instead at the number of iterations of the loop of "and now specialise calls that arise from the specialisation". Actually less code, and more robust. I also added record field names to a couple of constructors, and renamed RuleInfo to SpecInfo. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 11:11:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 11:11:08 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.6e8c832024c93303eec404083a7b518a@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_runt/T13623 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => perf/should_runt/T13623 * status: new => merge Comment: Nice catch! This has been wrong for eight months. Now fixed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 11:20:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 11:20:39 -0000 Subject: [GHC] #13564: Why does memory usage increase so much during CoreTidy? In-Reply-To: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> References: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> Message-ID: <062.da7911d4730a0318b10cd974535500b4@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3516 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * owner: rwbarton => (none) * resolution: fixed => Comment: > I found that this spike went away with -v, so I added a seqBinds which also eliminates the spike This is ok, but it's an un-satisfying Big Hammer. It forces us to make yet another pass over the entire program, when there is probably a more refined solution to hand. You might well be able to eliminate the other change in `tidyUnfolding` when you use the Big Hammer. And maybe we should eliminate it, since we are now seq'ing the unfolding twice. But it would be nicer to find the source of the spike in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 11:32:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 11:32:02 -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.11e985c8a2e9de9b89ce0927059220df@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 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 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes... might you (or anyone else) investigate those two regressions? It's not that they are unacceptable, but sometimes they indicate some low- hanging fruit. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 12:24:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 12:24:03 -0000 Subject: [GHC] #13637: Printing type operators adds extraneous parenthesis Message-ID: <046.6ebd1e08796fca2595c91164229af3b2@haskell.org> #13637: Printing type operators adds extraneous parenthesis -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the code: {{{ {-# LANGUAGE TypeOperators #-} type name ::: a = a f :: Int ::: Int -> Int f = id }}} In GHCi-8.0.2 I get: {{{ >>> :t f f :: Int ::: Int -> Int }}} But in GHCi-8.2.0.20170427 I get: {{{ >>> :t f f :: (Int ::: Int) -> Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 12:26:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 12:26:39 -0000 Subject: [GHC] #13637: Printing type operators adds extraneous parenthesis In-Reply-To: <046.6ebd1e08796fca2595c91164229af3b2@haskell.org> References: <046.6ebd1e08796fca2595c91164229af3b2@haskell.org> Message-ID: <061.f6b91c1d18664468f1bab51cb70c5b3d@haskell.org> #13637: Printing type operators adds extraneous parenthesis -------------------------------------+------------------------------------- Reporter: darchon | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 12:47:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 12:47:20 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.88943cd0c610b50d5238d8b8edd043a9@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by baramoglo): * cc: baramoglo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 13:47:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 13:47:25 -0000 Subject: [GHC] #13638: configure error: GHC is required. Message-ID: <044.c4e2543e0d324fa37a617e40dbf250c3@haskell.org> #13638: configure error: GHC is required. -------------------------------------+------------------------------------- Reporter: QuRyu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While I was trying to download GHC source code from Github and to build it myself, I encountered the error "configure: error: GHC is required." when I was doing "./configure". The "perl boot" raised no warning or error, and the source code was directly downloaded from Github using "git clone --recursive git://github.com/ghc/ghc.git". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 13:48:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 13:48:34 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.9c26ecd6994d180391ca5e36f3ba50a8@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_runt/T13623 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 78505384d5e4c44e525dda7aa5a9ca7ff9e3ca22. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 13:52:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 13:52:42 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.6290b741896b3b87a32422f6763b6cf6@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 13:55:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 13:55:30 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.0b639825807fb068e4911b30542d05ae@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 14:13:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 14:13:36 -0000 Subject: [GHC] #13310: Cut a new array release In-Reply-To: <046.78a1c6814a975bd87284888ceb2402ce@haskell.org> References: <046.78a1c6814a975bd87284888ceb2402ce@haskell.org> Message-ID: <061.e550838ba8726a39977fae4aa3f8ad7c@haskell.org> #13310: Cut a new array release -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: (none) => hvr Comment: http://hackage.haskell.org/package/array-0.5.1.2/candidate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 14:15:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 14:15:42 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.ca6fa2c8be4583dda6eeec9024c3aa10@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 7.10.4 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 7.10.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 14:35:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 14:35:26 -0000 Subject: [GHC] #11222: Teach strictness analysis about `catch`-like operations In-Reply-To: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> References: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> Message-ID: <061.b2ced2f0ef3cc0341bc43fa65c2a73dd@haskell.org> #11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Exceptions 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: closed => new * resolution: fixed => Comment: This was semantically shady and has been partially reverted. We would like to find a way to recover some of the benefits without the downsides. One strong possibility is to add a `catchIO#` primop that only catches exceptions thrown by `raiseIO#`. Such a primop could be handled more aggressively. See https://ghc.haskell.org/trac/ghc/wiki/Exceptions/PreciseExceptions. Another direction would be to treat `catch#` forms specially in strictness analysis, somewhat like `case` expressions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 14:35:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 14:35:44 -0000 Subject: [GHC] #11222: Teach strictness analysis about `catch`-like operations In-Reply-To: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> References: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> Message-ID: <061.439398ca6551c3b1cb62718d16db7413@haskell.org> #11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Exceptions 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): * owner: (none) => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 14:36:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 14:36:05 -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.ffed03e79ab13676c9a713adcdd21907@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: 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.1 => 8.4.1 Comment: Bump off to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 14:39:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 14:39:07 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted In-Reply-To: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> References: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> Message-ID: <062.61a70f4ddd6e381c14f112b87deaaa47@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by bgamari): The code in question here is likely `DsBinds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 14:40:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 14:40:14 -0000 Subject: [GHC] #13357: Check demand signatures for catchRetry# and catchSTM# In-Reply-To: <045.79df75dc0a793c7c7426d38d34e05263@haskell.org> References: <045.79df75dc0a793c7c7426d38d34e05263@haskell.org> Message-ID: <060.229533d4b9a67490f0935a3b39ec8918@haskell.org> #13357: Check demand signatures for catchRetry# and catchSTM# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3263 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Bumping off to 8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 14:41:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 14:41:17 -0000 Subject: [GHC] #11222: Teach strictness analysis about `catch`-like operations In-Reply-To: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> References: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> Message-ID: <061.16929c8067867149b3e1445065f65f85@haskell.org> #11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Exceptions 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): * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 14:44:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 14:44:21 -0000 Subject: [GHC] #13481: T12622 fails in ghci way In-Reply-To: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> References: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> Message-ID: <061.3aafcc650e8a3d71714b97bc1e258cd7@haskell.org> #13481: T12622 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: facundo.dominguez => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 15:02:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 15:02:38 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.3ae802c8d13261774d12b11a5c6d2278@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: Reopening again, because we still have the Big Hamme {{{ | let sz = coreBindsSize binds , () <- sz `seq` () -- Force it }}} in `SimplCore`. Is this still necessary? Could we just remove it altogether? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 15:26:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 15:26:05 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.e4f379d72cea6d5a3e2fd0ce7bd3ba4e@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ben: can you put this on Phab? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 18:36:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 18:36:12 -0000 Subject: [GHC] #13635: Incorrect result at runtime with list comprehensions in that case In-Reply-To: <044.1a958e7cc7f5a3b23c2bee2563d56889@haskell.org> References: <044.1a958e7cc7f5a3b23c2bee2563d56889@haskell.org> Message-ID: <059.e0949cc342eb426187747b600ca45cf3@haskell.org> #13635: Incorrect result at runtime with list comprehensions in that case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * Attachment "concrete_example.txt" added. a similar behavior -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 18:40:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 18:40:13 -0000 Subject: [GHC] #12075: Fails to build on powerpcspe because of inline assembly In-Reply-To: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> References: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> Message-ID: <062.c17be2a4eef9deb9366aa6808250870e@haskell.org> #12075: Fails to build on powerpcspe because of inline assembly ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Comment (by glaubitz): Replying to [comment:8 bgamari]: > glaubitz, see Phab:D3519 for a sketch of such a patch. Thanks. This is pretty much what I had in my head, perfect! Since I am building unregisterised, it takes a few days to get GHC build on this embedded CPU, but I will definitely test and report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 18:43:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 18:43:50 -0000 Subject: [GHC] #13637: Printing type operators adds extraneous parenthesis In-Reply-To: <046.6ebd1e08796fca2595c91164229af3b2@haskell.org> References: <046.6ebd1e08796fca2595c91164229af3b2@haskell.org> Message-ID: <061.c37db4cef8829c380b18963fb33c35c1@haskell.org> #13637: Printing type operators adds extraneous parenthesis -------------------------------------+------------------------------------- Reporter: darchon | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): I am investigating this, and suspect I may not be the culprit, it deals directly with `Type`, and the printing process goes through `pprTypeForUser ty` which is {{{#!haskell pprTypeForUser :: Type -> SDoc -- The type is tidied pprTypeForUser ty = pprSigmaType tidy_ty where (_, tidy_ty) = tidyOpenType emptyTidyEnv ty -- Often the types/kinds we print in ghci are fully generalised -- and have no free variables, but it turns out that we sometimes -- print un-generalised kinds (eg when doing :k T), so it's -- better to use tidyOpenType here }} And in turn `tidyOpenType` ends up in `tidyOpenTypes`, which changed as a result of https://github.com/ghc/ghc/commit/e9bf7bb5cc9 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 19:28:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 19:28:09 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.bceaf0d36d21d97e782eb156e38ba227@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3525 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D3525 Comment: See Phab:D3525. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 19:38:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 19:38:06 -0000 Subject: [GHC] #13639: Skylighting package compilation is glacial Message-ID: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> #13639: Skylighting package compilation is glacial -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Compiling the `skylighting` package in profiled and non-profiled confihratiine takes nearly ten minutes. I haven't looked at the code, but I can't imagine a syntax highlighting package would need to take this long. Investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 19:41:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 19:41:10 -0000 Subject: [GHC] #10230: multiline literals doesn't work with CPP extension. In-Reply-To: <045.9376d599c752191abeb407238b734b88@haskell.org> References: <045.9376d599c752191abeb407238b734b88@haskell.org> Message-ID: <060.d24c382e79e4155ff5f299b6a2c3a52f@haskell.org> #10230: multiline literals doesn't work with CPP extension. -------------------------------------+------------------------------------- Reporter: qnikst | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: cpp Operating System: 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): Updated URL for the relevant bit of the GHC manual: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/phases.html ?#cpp-and-string-gaps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 20:07:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 20:07:46 -0000 Subject: [GHC] #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) In-Reply-To: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> References: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> Message-ID: <060.ae9bcfeafd0bfe8d034ec6021b4eb49f@haskell.org> #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) -------------------------------------+------------------------------------- Reporter: Ptival | Owner: dfeuer Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | UndecidableInstances loop 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 dfeuer): * owner: (none) => dfeuer Comment: This appears to be fixed now. I will add the test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 20:21:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 20:21:08 -0000 Subject: [GHC] #13564: Why does memory usage increase so much during CoreTidy? In-Reply-To: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> References: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> Message-ID: <062.103e0bca8f48f694b8fc8ce0f9a8b550@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3516, Wiki Page: | Phab:D3524 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D3516 => Phab:D3516, Phab:D3524 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 21:44:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 21:44:51 -0000 Subject: [GHC] #13640: Core lint error with deferred type holes Message-ID: <051.2c7223492c210d11878b7833204062aa@haskell.org> #13640: Core lint error with deferred type holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Options_GHC -dcore-lint -fdefer-typed-holes #-} import Prelude hiding ((.)) class Functor' f where map' :: (a -> b) -> f a -> f b class Bifunctor' f where map2' :: (a -> b) -> f a c -> f b c bimap' :: Bifunctor' f => (a -> b) -> (c -> d) -> (f a c -> f b d) bimap' f g = map2' f . map' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 21:45:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 21:45:15 -0000 Subject: [GHC] #13640: Core lint error with deferred type holes In-Reply-To: <051.2c7223492c210d11878b7833204062aa@haskell.org> References: <051.2c7223492c210d11878b7833204062aa@haskell.org> Message-ID: <066.7416a10c02d7e500a427478f62fed4d2@haskell.org> #13640: Core lint error with deferred type holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "tN4R.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 22:16:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 22:16:53 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.56945fc06dae85b82824090cbe4c3ece@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): No objections from me, this is a longstanding thing, and usually hard to tickle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 22:36:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 22:36:52 -0000 Subject: [GHC] #13640: Core lint error with deferred type holes In-Reply-To: <051.2c7223492c210d11878b7833204062aa@haskell.org> References: <051.2c7223492c210d11878b7833204062aa@haskell.org> Message-ID: <066.221cd86ab45ba273a713d1d94320d869@haskell.org> #13640: Core lint error with deferred type holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you update the description to explain what the problem is? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 22:55:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 22:55:14 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.17ee9af3a8b7736741063c24e93c62f8@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 8.2.1-rc2 => 7.10.3 * milestone: 7.10.4 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 2 23:03:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 May 2017 23:03:03 -0000 Subject: [GHC] #13640: Core lint error with deferred type holes In-Reply-To: <051.2c7223492c210d11878b7833204062aa@haskell.org> References: <051.2c7223492c210d11878b7833204062aa@haskell.org> Message-ID: <066.4d4c56e18a16c35c9c1245bb10931b18@haskell.org> #13640: Core lint error with deferred type holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): FWIW, I can't reproduce this error with GHC 8.0.2, 8.2.1, or HEAD: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170427: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:12:22: error: • Variable not in scope: (.) :: (f0 a c0 -> f0 b c0) -> ((a0 -> b0) -> f1 a0 -> f1 b0) -> f a c -> f b d • Perhaps you want to remove ‘.’ from the explicit hiding list in the import of ‘Prelude’ (Bug.hs:3:1-27). | 12 | bimap' f g = map2' f . map' | }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 01:21:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 01:21:31 -0000 Subject: [GHC] #13640: Core lint error with deferred type holes In-Reply-To: <051.2c7223492c210d11878b7833204062aa@haskell.org> References: <051.2c7223492c210d11878b7833204062aa@haskell.org> Message-ID: <066.c4f9b2b2e3e341d3934d32cde5b32067@haskell.org> #13640: Core lint error with deferred type holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've verified that commit b4bdbe4957ae8b82c4cda5584203b44d3c4f004f (Don't omit any evidence bindings), the fix for #12156, was what fixed this program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 01:34:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 01:34:28 -0000 Subject: [GHC] #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) In-Reply-To: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> References: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> Message-ID: <060.ced227fb0aacc622cb924a19036cd447@haskell.org> #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) -------------------------------------+------------------------------------- Reporter: Ptival | Owner: dfeuer Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | UndecidableInstances loop 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): Ah, commit 859dc65369e8a9722514046246dd32b683c8b4a9 (Yet another attempt at inferring the right quantification) was what fixed this. Hooray! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 03:07:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 03:07:47 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.fc7184bee0181f11fb8a891ecac8b6ed@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism 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:D3490 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"16b0a07e5d0c72c1171359e546d9373442ec0564/ghc" 16b0a07/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="16b0a07e5d0c72c1171359e546d9373442ec0564" Fix #13233 by checking for lev-poly primops The implementation plan is all in Note [Detecting forced eta expansion] in DsExpr. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 03:07:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 03:07:47 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.4bb7c36b94c80d56684dcecce4e6835c@haskell.org> #13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: typeable, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3424 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"09bf135ace55ce2572bf4168124d631e386c64bb/ghc" 09bf135a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="09bf135ace55ce2572bf4168124d631e386c64bb" Fix #13333 by fixing the covar's type in ctEvCoercion The change is noted in Note [Given in ctEvCoercion]. This patch also adds a bit more commentary to TcFlatten, documenting some key invariants of the flattening algorithm. While in the area, I also removed some stale commentary from TcCanonical. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 03:07:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 03:07:47 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.75a62070e24be38d30932b9c226f36b8@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism 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:D3490 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b460d6c99316deac2b8022a4fb7dddc57c052a2a/ghc" b460d6c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b460d6c99316deac2b8022a4fb7dddc57c052a2a" Fix #13233 by checking for lev-poly primops The implementation plan is all in Note [Detecting forced eta expansion] in DsExpr. Test Plan: ./validate, codeGen/should_fail/T13233 Reviewers: simonpj, austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13233 Differential Revision: https://phabricator.haskell.org/D3490 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 03:07:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 03:07:47 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.bf1755ac15d4a74bf90b8bfd44c40092@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6df8bef054db0b95bb8f9e55bb82580e27d251d6/ghc" 6df8bef/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6df8bef054db0b95bb8f9e55bb82580e27d251d6" Test #13585 in typecheck/should_compile/T13585 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 03:20:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 03:20:30 -0000 Subject: [GHC] #13641: Compile error while performing stack upgrade Message-ID: <049.0e154dd8b9d37841e334d749116666e2@haskell.org> #13641: Compile error while performing stack upgrade -------------------------------------+------------------------------------- Reporter: pisomojado | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, I'm a very green user of this ticket system, as well as GHC, so apologies if I have not given useful details. I'm complying with the request of stack/ghc, as you can see down towards the bottom of my attempt to upgrade stack on my host. Any help would be appreciated. {{{ pisomojado at host:~$ stack upgrade Fetching package index ...remote: Counting objects: 1, done. remote: Total 1 (delta 0), reused 1 (delta 0), pack-reused 0 Unpacking objects: 100% (1/1), done. Fetched package index. aeson-1.0.2.1: configure aeson-1.0.2.1: build Cabal-1.24.2.0: configure Cabal-1.24.2.0: build ed25519-0.0.5.0: configure ed25519-0.0.5.0: build cryptohash-sha256-0.11.100.1: configure cryptohash-sha256-0.11.100.1: build cryptohash-sha256-0.11.100.1: copy/register http-client-0.5.3.3: configure http-client-0.5.3.3: build ed25519-0.0.5.0: copy/register optparse-applicative-0.13.0.0: configure optparse-applicative-0.13.0.0: build optparse-applicative-0.13.0.0: copy/register optparse-simple-0.0.3: configure optparse-simple-0.0.3: build optparse-simple-0.0.3: copy/register pid1-0.1.0.0: configure pid1-0.1.0.0: build http-client-0.5.3.3: copy/register http-client-tls-0.3.4: configure pid1-0.1.0.0: copy/register http-client-tls-0.3.4: build store-core-0.3: configure store-core-0.3: build http-client-tls-0.3.4: copy/register text-metrics-0.1.0: configure store-core-0.3: copy/register text-metrics-0.1.0: build th-orphans-0.13.1: configure th-orphans-0.13.1: build text-metrics-0.1.0: copy/register th-orphans-0.13.1: copy/register th-utilities-0.2.0.1: configure th-utilities-0.2.0.1: build th-utilities-0.2.0.1: copy/register store-0.3: configure store-0.3: build store-0.3: copy/register aeson-1.0.2.1: copy/register aeson-compat-0.3.6: configure aeson-compat-0.3.6: build binary-tagged-0.1.4.1: configure binary-tagged-0.1.4.1: build http-conduit-2.2.3: configure http-conduit-2.2.3: build aeson-compat-0.3.6: copy/register path-0.5.9: configure path-0.5.9: build http-conduit-2.2.3: copy/register persistent-2.6: configure persistent-2.6: build path-0.5.9: copy/register path-io-1.1.0: configure path-io-1.1.0: build binary-tagged-0.1.4.1: copy/register yaml-0.8.20: configure yaml-0.8.20: build path-io-1.1.0: copy/register yaml-0.8.20: copy/register hpack-0.17.0: configure hpack-0.17.0: build persistent-2.6: copy/register persistent-template-2.5.1.6: configure persistent-template-2.5.1.6: build persistent-sqlite-2.6: configure persistent-sqlite-2.6: build Cabal-1.24.2.0: copy/register hpack-0.17.0: copy/register hackage-security-0.5.2.2: configure hackage-security-0.5.2.2: build persistent-template-2.5.1.6: copy/register hackage-security-0.5.2.2: copy/register persistent-sqlite-2.6: copy/register stack-1.4.0: configure [1 of 1] Compiling Main ( /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack- upgrade4706/stack-1.4.0/Setup.hs, /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack- upgrade4706/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o ) Linking /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack- upgrade4706/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ... Configuring stack-1.4.0... stack-1.4.0: build Preprocessing library stack-1.4.0... [ 1 of 124] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 124] Compiling Hackage.Security.Client.Repository.HttpLib.HttpClient ( src/Hackage/Security/Client/Repository/HttpLib/HttpClient.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Hackage/Security/Client/Repository/HttpLib/HttpClient.o ) [ 3 of 124] Compiling Stack.Options.ScriptParser ( src/Stack/Options/ScriptParser.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Options/ScriptParser.o ) [ 4 of 124] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o ) [ 5 of 124] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) [ 6 of 124] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o ) [ 7 of 124] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o ) [ 8 of 124] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o ) [ 9 of 124] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) [ 10 of 124] Compiling Path.Extra ( src/Path/Extra.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) [ 11 of 124] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/ghc7482_0/libghc_68.dylib, 5): no suitable image found. Did find: /var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/ghc7482_0/libghc_68.dylib: malformed mach-o: load commands size (49672) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 26 action(s). -- While building package stack-1.4.0 using: /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack- upgrade4706/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 03:23:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 03:23:08 -0000 Subject: [GHC] #13641: Compile error while performing stack upgrade In-Reply-To: <049.0e154dd8b9d37841e334d749116666e2@haskell.org> References: <049.0e154dd8b9d37841e334d749116666e2@haskell.org> Message-ID: <064.a9893bbb89ebe1cc2e98f61c21c40ed1@haskell.org> #13641: Compile error while performing stack upgrade -------------------------------------+------------------------------------- Reporter: pisomojado | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #12479 Comment: Please see #12479. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 03:34:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 03:34:53 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.fc9fa3c39a5064c2d453905452817880@haskell.org> #13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: typeable, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T13333 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3424 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compile/T13333 * status: patch => merge Comment: Thanks for pushing this, Ben! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 03:35:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 03:35:44 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.273c9fe5b4a094f924278a4289c837e2@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T13585 Blocked By: | Blocking: Related Tickets: #13333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => merge * testcase: => typecheck/should_compile/T13585 Comment: Thanks, Ben, for committing this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 03:38:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 03:38:43 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.35a85227a8c74bcc1dd6bbe6b12f99ab@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | codeGen/should_fail/T13233 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3490 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => codeGen/should_fail/T13233 Comment: The patch Ben just committed fixes this bug, but in a stopgap manner. We can do better. Please merge this patch, but then reopen the ticket after merging. (Below are mostly notes to self.) There are two separate problems: 1. How to ascertain whether or not a primop is saturated during desugaring (or, possibly, earlier). Simon and I once thought that we could do this in the desugarer by decomposing nested `HsApp`s, using a little stack data type to denote all the different ways a function could be applied (`HsApp`, `HsWrap` with the right wrapper, sections, tuple- sections, `HsTypeApp`, maybe more) uncovering what the function was underneath, and then checking how many parameters are supplied. But now, I think it's much better to do this in the type-checker, especially because the type-checker already decomposes nested `HsApp`s. (See `TcExpr.tcApp`.) When it discovers what the function is, it can check whether the function is a `hasNoBinding` primop. If so, it can eta-expand as necessary (but only if necessary) and use a new piece of `HsSyn` to denote a saturated primop. (It will be a new invariant that no unsaturated primop passes the type-checker.) This seems better than redoing the stack type in the desugarer. The original problem in #13233 was around levity polymorphism. If we make this change in the type checker, then the existing levity polymorphism checks should just work. We'll have to be careful to make the `HsSyn` structure printable in the way a user expects, so that the levity- polymorphism error message doesn't talk about an argument the user didn't write. 2. How to make sure that saturated primops stay that way in Core. This would be a new check in Lint as well as new checks on any code that does eta-contraction. It has been suggested that levity-polymorphic primops desugar to a family of levity-monomorphic primops. This surely would work, but there doesn't seem to be benefit over a plan simply to keep primops eta-expanded always. Then, there's no worry about eta-contracting levity- polymorphic arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 07:28:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 07:28:24 -0000 Subject: [GHC] #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) In-Reply-To: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> References: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> Message-ID: <060.e1ec4efda43ec10540da8f08f3b06d30@haskell.org> #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) -------------------------------------+------------------------------------- Reporter: Ptival | Owner: dfeuer Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | UndecidableInstances loop 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): Great! Please add the test case though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 10:34:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 10:34:00 -0000 Subject: [GHC] #13640: Core lint error with deferred type holes In-Reply-To: <051.2c7223492c210d11878b7833204062aa@haskell.org> References: <051.2c7223492c210d11878b7833204062aa@haskell.org> Message-ID: <066.71e883cf197049dc3cf0b66e449f3cd6@haskell.org> #13640: Core lint error with deferred type holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -0,0 +1,2 @@ + The following program (note the `-dcore-lint`) + @@ -15,0 +17,5 @@ + + produces a `*** Core Lint errors : in result of Desugar (after + optimization) ***`, more information in attached + [https://ghc.haskell.org/trac/ghc/attachment/ticket/13640/tN4R.log the + log]. New description: The following program (note the `-dcore-lint`) {{{#!hs {-# Options_GHC -dcore-lint -fdefer-typed-holes #-} import Prelude hiding ((.)) class Functor' f where map' :: (a -> b) -> f a -> f b class Bifunctor' f where map2' :: (a -> b) -> f a c -> f b c bimap' :: Bifunctor' f => (a -> b) -> (c -> d) -> (f a c -> f b d) bimap' f g = map2' f . map' }}} produces a `*** Core Lint errors : in result of Desugar (after optimization) ***`, more information in attached [https://ghc.haskell.org/trac/ghc/attachment/ticket/13640/tN4R.log the log]. -- Comment (by Iceland_jack): Replying to [comment:1 simonpj]: > Can you update the description to explain what the problem is? Edited. It seems to have been solved already, thanks for a swift response -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 12:16:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 12:16:14 -0000 Subject: [GHC] #13578: Incorrect Record Pattern Synonym example in users guide In-Reply-To: <051.58a626fdfaf00c9495077810b02c0150@haskell.org> References: <051.58a626fdfaf00c9495077810b02c0150@haskell.org> Message-ID: <066.625b21555d2bf8b375e8fd131656234e@haskell.org> #13578: Incorrect Record Pattern Synonym example in users guide -------------------------------------+------------------------------------- Reporter: cjholdbrooks | Owner: (none) Type: task | Status: closed Priority: highest | Milestone: 8.2.1 Component: Documentation | Version: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => closed * resolution: => fixed Comment: Indeed, this was fixed in bc7c730c613f5c35eea512955728d1e7a0d01aa9. Sadly, this is present in the [http://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts.html #record-pattern-synonyms 8.0.1] and [http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/glasgow_exts.html #record-pattern-synonyms 8.0.2] users' guides, but since this is fixed in GHC 8.2, I'm opting to close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 12:41:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 12:41:36 -0000 Subject: [GHC] #12947: Core lint error In-Reply-To: <051.c8f6f90ba6faede01ce48237dc8657bf@haskell.org> References: <051.c8f6f90ba6faede01ce48237dc8657bf@haskell.org> Message-ID: <066.c2278df9e9d658fe5bfe4ec14ca7d20b@haskell.org> #12947: Core lint error -------------------------------------+------------------------------------- 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: #13640 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13640 Comment: It looks like this is the same problem as reported in #13640, which was fixed in commit b4bdbe4957ae8b82c4cda5584203b44d3c4f004f (Don't omit any evidence bindings), the fix for #12156. I'll whip up a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 12:42:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 12:42:09 -0000 Subject: [GHC] #13640: Core lint error with deferred type holes In-Reply-To: <051.2c7223492c210d11878b7833204062aa@haskell.org> References: <051.2c7223492c210d11878b7833204062aa@haskell.org> Message-ID: <066.a0bdfcade80ba4d29f0bebbc112237a8@haskell.org> #13640: Core lint error with deferred type holes -------------------------------------+------------------------------------- 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: #12947 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12947 Comment: This ended up being the same issue as #12947. Regression test incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 12:44:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 12:44:55 -0000 Subject: [GHC] #11669: Incorrectly suggests RankNTypes for ill-formed type "forall a. Eq a. Int" In-Reply-To: <051.ef9fc6a373cf8eba53b7bf79d29ca288@haskell.org> References: <051.ef9fc6a373cf8eba53b7bf79d29ca288@haskell.org> Message-ID: <066.96f460d878e020e850520bcd76c9b4c9@haskell.org> #11669: Incorrectly suggests RankNTypes for ill-formed type "forall a. Eq a. Int" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: drobnik Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Parser) | Resolution: duplicate | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #3155, #12811 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * milestone: => 8.2.1 Comment: This was fixed in commit 488a9daa8246e0dd364dc44b8b6b8650fa6f3822 (Changed parser message for RankNTypes (#12811)), so I'll close this as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 12:58:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 12:58:13 -0000 Subject: [GHC] #12947: Core lint error In-Reply-To: <051.c8f6f90ba6faede01ce48237dc8657bf@haskell.org> References: <051.c8f6f90ba6faede01ce48237dc8657bf@haskell.org> Message-ID: <066.5f960cea62b9394679c9e93f424e1377@haskell.org> #12947: Core lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13640 | Differential Rev(s): Phab:D3528 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3528 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 12:58:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 12:58:26 -0000 Subject: [GHC] #13640: Core lint error with deferred type holes In-Reply-To: <051.2c7223492c210d11878b7833204062aa@haskell.org> References: <051.2c7223492c210d11878b7833204062aa@haskell.org> Message-ID: <066.f3f92cd9bdb0bbed9b499f40bbf1be39@haskell.org> #13640: Core lint error with deferred type holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12947 | Differential Rev(s): Phab:D3528 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3528 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 13:04:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 13:04:22 -0000 Subject: [GHC] #11616: Kinds aren't instantiated In-Reply-To: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> References: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> Message-ID: <066.c341ec8e8671167acf84ec95a53ed0dd@haskell.org> #11616: Kinds aren't instantiated -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Is this bug still present? I just tried defining this: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} module T11616 where class Whoami a where whoami :: String instance Whoami Int where whoami = "int" instance Whoami Bool where whoami = "[y/n]" instance Whoami Maybe where whoami = "call me maybe" whoisint :: String whoisint = whoami @Int }}} And compiling it works without a hitch on GHC 8.0.1, 8.0.2, 8.2.1, and HEAD. So I suspect that the invisible kind variable is no longer available for type application, which is the behavior you desire, right goldfire? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 13:13:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 13:13:33 -0000 Subject: [GHC] #11616: Kinds aren't instantiated In-Reply-To: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> References: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> Message-ID: <066.d5044ab14419ca235273d29580419bfb@haskell.org> #11616: Kinds aren't instantiated -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Agreed with the analysis in comment:3 -- this seems fixed. Is there a regression test somewhere before we close the ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 13:28:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 13:28:00 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.14d1d1b6670b6598aa34c34b70e388eb@haskell.org> #13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: typeable, Resolution: fixed | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T13333 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3424 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 51d80c3b2c4c7d8f1f5dbcee39864c2de49143c7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 13:28:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 13:28:33 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.9fdb4db246cc93a2b6b8a18d5f200c05@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | codeGen/should_fail/T13233 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3490 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: goldfire => (none) * status: merge => new Comment: Merged to `ghc-8.2` as add8e7f759e64ff3f9855073d67b1eb3c8f4d83b. Reopening due to comments above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 13:28:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 13:28:57 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.2246ed66378734076227573bef442f1a@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T13585 Blocked By: | Blocking: Related Tickets: #13333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 13:29:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 13:29:22 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.0cf0c2e7d97435a7d28e9a313d684bfa@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | codeGen/should_fail/T13233 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3490 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 19:35:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 19:35:22 -0000 Subject: [GHC] #11616: Kinds aren't instantiated In-Reply-To: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> References: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> Message-ID: <066.de07bab98e45ca24aa7723384d95271f@haskell.org> #11616: Kinds aren't instantiated -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D3531 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3531 Comment: I couldn't find a test which adequately tested all of the features that this program uses, so I added one of my own in Phab:D3531. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 19:44:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 19:44:05 -0000 Subject: [GHC] #11333: GHCi does not discharge satisfied constraints In-Reply-To: <051.3795e83a0b8f73c46509bda1b8f53594@haskell.org> References: <051.3795e83a0b8f73c46509bda1b8f53594@haskell.org> Message-ID: <066.c22d35e221034e074f590a272a25e781@haskell.org> #11333: GHCi does not discharge satisfied constraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: fixed | TypeApplications Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #11376 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * related: => #11376 Comment: This appears to be fixed, even as of GHC 8.0.1: {{{ $ /opt/ghc/8.0.1/bin/ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XTypeApplications λ> :t show show :: Show a => a -> String λ> :t show @Int show @Int :: Int -> String λ> import Data.Typeable λ> :t eqT eqT :: (Typeable b, Typeable a) => Maybe (a :~: b) λ> :t eqT @Int eqT @Int :: Typeable b => Maybe (Int :~: b) }}} This is a consequence of making `:type` deeply instantiate types (#11376). If you want the behavior that is shown in the original example, you can use `:type +v` (in GHC 8.2 or later): {{{ $ /opt/ghc/8.2.1/bin/ghci GHCi, version 8.2.0.20170427: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XTypeApplications λ> :type +v show show :: Show a => a -> String λ> :type +v show @Int show @Int :: Show Int => Int -> String λ> import Data.Typeable λ> :type +v eqT eqT :: forall k (a :: k) (b :: k). (Typeable a, Typeable b) => Maybe (a :~: b) λ> :type +v eqT @Int eqT @Int :: (Typeable Int, Typeable b) => Maybe (Int :~: b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 20:16:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 20:16:15 -0000 Subject: [GHC] #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature Message-ID: <050.233776085b104a5b6592f82d271668fa@haskell.org> #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.1-rc1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a pretty bizarre behavior I've noticed recently that only happens in GHC 8.2 or later. If you try to use a Template Haskell splice with a very particular feature (a datatype whose kind uses `forall`) in GHCi, then GHCi will flat-out ignore it! {{{ $ /opt/ghc/8.2.1/bin/ghci GHCi, version 8.2.0.20170427: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XGADTs -XTypeInType -XTemplateHaskell -XRankNTypes λ> import Language.Haskell.TH (stringE, pprint) λ> import Data.Kind (Type) λ> $([d| data Foo :: forall a. a -> Type where MkFoo :: Foo Int |] >>= stringE . pprint) λ> print (5 + length $([d| data Foo :: forall a. a -> Type where MkFoo :: Foo Int |] >>= stringE . pprint)) λ> 5 5 λ> it 5 λ> $([d| data Foo :: forall a. a -> Type where MkFoo :: Foo Int |] >>= stringE . pprint) λ> it 5 }}} Notice how none of my attempts to use the splice seemed to register with GHCi. This isn't really a regression //per se//, since GHC 8.0.1 nor 8.0.2 even allowed you to get that far: {{{ $ /opt/ghc/8.0.2/bin/ghci GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XGADTs -XTypeInType -XTemplateHaskell -XRankNTypes λ> import Language.Haskell.TH (stringE, pprint) λ> import Data.Kind (Type) λ> $([d| data Foo :: forall a. a -> Type where MkFoo :: Foo Int |] >>= stringE . pprint) :4:3: error: Exotic form of kind not (yet) handled by Template Haskell forall a. a -> Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 20:21:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 20:21:51 -0000 Subject: [GHC] #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature In-Reply-To: <050.233776085b104a5b6592f82d271668fa@haskell.org> References: <050.233776085b104a5b6592f82d271668fa@haskell.org> Message-ID: <065.c0379160894de007e30378a998c3b077@haskell.org> #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, it extends even beyond GHCi! If you put this into a module: {{{#!hs {-# LANGUAGE GADTs, TypeInType, TemplateHaskell, RankNTypes #-} module Bug where import Data.Kind (Type) import Language.Haskell.TH (stringE, pprint) main :: IO () main = putStrLn $([d| data Foo :: forall a. a -> Type where MkFoo :: Foo Int |] >>= string E . pprint) }}} Then some interesting things happen if you try to compile this. If you try to load it into GHCi, you get this: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170427: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Failed, modules loaded: none. }}} Apparently the module fails to compile, despite the fact that no errors were emitted during compilation. Something similar happens if you directly invoke `ghc` on it: {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) $ echo $? 1 }}} Again, no errors are emitted, but compilation definitely fails, since no `.hi` or `.o` files are emitted, and you get an error return code of 1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 20:38:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 20:38:23 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.b7800e3ca6222c19603309f6475c2b2b@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: I agree that something is quite fishy is going on here—or perhaps several things? The further I dug into this, the more horrified I became. One thing I tried was seeing what GHCi thinks of this engimatic `T` type: {{{ $ ghc/inplace/bin/ghc-stage2 --interactive Bug2.hs GHCi, version 8.3.20170503: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug2.hs, interpreted ) Ok, modules loaded: Main. λ> :i T type role T nominal nominal data T (b :: IsTypeLit a ~ 'True) (c :: a) where MkNat :: T ('Data.Type.Equality.C:~ ('GHC.Types.Eq# <>)) 42 MkSymbol :: T ('Data.Type.Equality.C:~ ('GHC.Types.Eq# <>)) "Don't panic!" -- Defined at Bug2.hs:14:1 }}} ...Oh. Oh my goodness. I don't even know how one is supposed to possibly interpret that (perhaps this is related to #13407?). Something that's particularly strange is that `T` is reported as having //two// type parameters, which is certainly not correct. This might help explain all of your attempts to use `T` were met with confusing errors. Another thing that perplexes me is—should the definition of `T` as it's written in the original example even be accepted? We have: {{{#!hs data T :: forall a. (IsTypeLit a ~ 'True) => a -> * where ... }}} If I'm reading this correctly, this would desugar into something like this, yes? {{{ data (IsTypeLit a ~ 'True) => T (x :: a) = ... }}} If so, shouldn't that require `DatatypeContexts`? Also if so, why on earth is something that requires `DatatypeContexts` in the users' manual? Perhaps this is my inexperience with this feature bleeding through. After all, I didn't even know "type constraints" were a thing until I stumbled upon this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 20:40:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 20:40:51 -0000 Subject: [GHC] #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors In-Reply-To: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> References: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> Message-ID: <066.510bd4118e99f2ed4eddf508b7b190a2@haskell.org> #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 21:13:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 21:13:08 -0000 Subject: [GHC] #13631: In GHCi a result is wrong when -fdefer-typed-holes is used with underscore alone In-Reply-To: <044.47be1126ba3fb980d5a576a1fcfeebf4@haskell.org> References: <044.47be1126ba3fb980d5a576a1fcfeebf4@haskell.org> Message-ID: <059.5e6690352bc101f597c849f240141f0a@haskell.org> #13631: In GHCi a result is wrong when -fdefer-typed-holes is used with underscore alone -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: new => closed * resolution: => invalid Comment: Error, here I say anything! sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 22:53:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 22:53:18 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.6e9f0b5c7dafd50a52998a6212ec264d@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -16,1 +16,2 @@ - Deriving a standalone `Show` instance *without* the constraint works fine + Deriving a standalone `Show` instance *without* the constraint `(IsTypeLit + a ~ 'True) => ` works fine New description: GHC 8.0.0.20160511. Example from the user guide: [https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts.html #constraints-in-kinds Constraints in kinds] {{{#!hs type family IsTypeLit a where IsTypeLit Nat = 'True IsTypeLit Symbol = 'True IsTypeLit a = 'False data T :: forall a. (IsTypeLit a ~ 'True) => a -> * where MkNat :: T 42 MkSymbol :: T "Don't panic!" }}} Deriving a standalone `Show` instance *without* the constraint `(IsTypeLit a ~ 'True) => ` works fine {{{#!hs deriving instance Show (T a) }}} but I couldn't define a `Show` instance given the constraints: {{{#!hs -- • Couldn't match expected kind ‘'True’ -- with actual kind ‘IsTypeLit a0’ -- The type variable ‘a0’ is ambiguous -- • In the first argument of ‘Show’, namely ‘T a’ -- In the stand-alone deriving instance for ‘Show (T a)’ deriving instance Show (T a) }}} let's add constraints {{{#!hs -- • Couldn't match expected kind ‘'True’ -- with actual kind ‘IsTypeLit lit’ -- • In the first argument of ‘Show’, namely ‘T (a :: lit)’ -- In the instance declaration for ‘Show (T (a :: lit))’ instance IsTypeLit lit ~ 'True => Show (T (a :: lit)) where }}} let's derive for a single literal {{{#!hs -- • Illegal type synonym family application in instance: -- T Nat -- ('Data.Type.Equality.C:~ -- Bool -- (IsTypeLit Nat) -- 'True -- ('GHC.Types.Eq# Bool Bool (IsTypeLit Nat) 'True <>)) -- 42 -- • In the stand-alone deriving instance for ‘Show (T (42 :: Nat))’ deriving instance Show (T (42 :: Nat)) }}} same happens with {{{#!hs instance Show (T 42) where }}} ---- The documentation > Note that explicitly quantifying with `forall a` is not necessary here. seems to be wrong since removing it results in {{{ tVDv.hs:10:17-18: error: … • Expected kind ‘a’, but ‘42’ has kind ‘Nat’ • In the first argument of ‘T’, namely ‘42’ In the type ‘T 42’ In the definition of data constructor ‘MkNat’ Compilation failed. }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 22:56:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 22:56:31 -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.82990ddff797154856a1430943aff966@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 Iceland_jack): May relate to #12102, according to Ryan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 22:57:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 22:57:57 -0000 Subject: [GHC] #13638: configure error: GHC is required. In-Reply-To: <044.c4e2543e0d324fa37a617e40dbf250c3@haskell.org> References: <044.c4e2543e0d324fa37a617e40dbf250c3@haskell.org> Message-ID: <059.8d6abe14b5462c06463ea04cbeca7181@haskell.org> #13638: configure error: GHC is required. -------------------------------------+------------------------------------- Reporter: QuRyu | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Do you have a working `ghc` in your `PATH`? Note that GHC is self-hosting and consequential requires a functional `ghc` to build. You may be interested in wiki:Building/Preparation, if you haven't yet seen it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 23:12:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 23:12:49 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.2d2f036e75a92f4a53ae37431825177f@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Yeah this is something odd Replying to [comment:1 RyanGlScott]: > Perhaps this is my inexperience with this feature bleeding through. After all, I didn't even know "type constraints" were a thing until I stumbled upon this ticket. Richard has a paper on [http://cs.brynmawr.edu/~rae/papers/2017/partiality/partiality.pdf Constrained Type Families], which as I understand it might express this with closed type classes who knows {{{#!hs class TypeLit (a :: Type) where instance TypeLit Nat instance TypeLit Symbol data T :: forall a. TypeLit a => a -> Type where MkNat :: T 42 MkSymbol :: T "Don't panic!" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 3 23:31:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 May 2017 23:31:30 -0000 Subject: [GHC] #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors In-Reply-To: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> References: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> Message-ID: <066.969bdd6df220e3ac6d9b767c01178648@haskell.org> #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors -------------------------------------+------------------------------------- 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): Good solution, it won't be possible to derive them unless added as default methods. I am getting feedback on and mulling over an approach different from my initial proposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 00:31:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 00:31:49 -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.38f922fee5c8527538fd541d3b1d64fb@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 00:41:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 00:41:43 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.723529eda2c7868421c5bac790bd4dee@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I think I found a solution for this particular case, using `TypeFamilyDependencies`, if we make a restricted code {{{#!hs data Code = NAT | SYMBOL }}} with an injective interpretation {{{#!hs type family Interp (a :: Code) = (res :: Type) | res -> a where Interp NAT = Nat Interp SYMBOL = Symbol }}} then you can write {{{#!hs data T :: forall a. Interp a -> Type where MkNat :: T 42 MkSymbol :: T "Don't panic!" deriving instance Show (T a) deriving instance Eq (T a) deriving instance Ord (T a) -- deriving instance Read (T a) }}} but using any of those methods causes the error in #13643 :) once that ticket is created -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 00:41:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 00:41:51 -0000 Subject: [GHC] #13643: Core lint error with TypeInType and TypeFamilyDependencies Message-ID: <051.99866398c3b30eccc01358213362b7d9@haskell.org> #13643: Core lint error with TypeInType and TypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple InjectiveFamilies, TypeInType | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 12102 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the code {{{#!hs {-# Language TypeFamilyDependencies #-} {-# Language RankNTypes #-} {-# Language KindSignatures #-} {-# Language DataKinds #-} {-# Language TypeInType #-} {-# Language GADTs #-} import Data.Kind (Type) data Code = I type family Interp (a :: Code) = (res :: Type) | res -> a where Interp I = Bool data T :: forall a. Interp a -> Type where MkNat :: T False instance Show (T a) where show _ = "MkNat" main = do print MkNat }}} but add `{-# Options_GHC -dcore-lint #-}` and we get the attached log from running `runghc /tmp/tPb2.hs > /tmp/tPb2.log`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 00:42:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 00:42:47 -0000 Subject: [GHC] #13643: Core lint error with TypeInType and TypeFamilyDependencies In-Reply-To: <051.99866398c3b30eccc01358213362b7d9@haskell.org> References: <051.99866398c3b30eccc01358213362b7d9@haskell.org> Message-ID: <066.e22270336bf1e1b689eab5124b90d9e1@haskell.org> #13643: Core lint error with TypeInType and TypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | InjectiveFamilies, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12102 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "tPb2.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 00:53:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 00:53:05 -0000 Subject: [GHC] #13643: Core lint error with TypeInType and TypeFamilyDependencies In-Reply-To: <051.99866398c3b30eccc01358213362b7d9@haskell.org> References: <051.99866398c3b30eccc01358213362b7d9@haskell.org> Message-ID: <066.eb755e1fcf9a27a1898c6d28af2fcf12@haskell.org> #13643: Core lint error with TypeInType and TypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | InjectiveFamilies, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12102 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: 12102 => #12102 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 01:04:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 01:04:13 -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.6dbebe68902f145adc7629f36a1d8f29@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: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: #13379 => #13379 13564 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 01:04:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 01:04:29 -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.9652b1337cfe1f6c79fc1de4da5e340e@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: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: #13379 13564 => #13379 #13564 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 01:07:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 01:07:36 -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.09117c3c8bd620dcbcae6673ef66618c@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:25 bgamari]: > Reopening to ensure we don't lose track of these. Would it be better to close this and open a new ticket for the regressions? The original bug is fixed, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 01:28:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 01:28:29 -0000 Subject: [GHC] #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature In-Reply-To: <050.233776085b104a5b6592f82d271668fa@haskell.org> References: <050.233776085b104a5b6592f82d271668fa@haskell.org> Message-ID: <065.ae6a88c66ac9e55f948afd0385866f65@haskell.org> #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Huh, the culprit is commit ae6e63aa858d663952b67cc9969fd14782d307bb (Fix #12709 by not building bad applications). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 02:19:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 02:19:33 -0000 Subject: [GHC] #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature In-Reply-To: <050.233776085b104a5b6592f82d271668fa@haskell.org> References: <050.233776085b104a5b6592f82d271668fa@haskell.org> Message-ID: <065.3f4ef54c86aafb81bc62a8b510bf5212@haskell.org> #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: After some digging, the function responsible for suppressing the error message appears to be `dsWhenNoErrs`: {{{#!hs dsWhenNoErrs :: DsM a -> (a -> CoreExpr) -> DsM CoreExpr dsWhenNoErrs thing_inside mk_expr = do { (result, no_errs) <- askNoErrsDs thing_inside ; return $ if no_errs then mk_expr result else unitExpr } }}} For whatever reason, `askNoErrsDs` does not appear to be propagating the error message correctly. There's also similar issues with splicing in any other features which Template Haskell doesn't support. For example, you could just as well use `[d| id x = x {-# SCC id #-} |]` in the example above. goldfire, do you have an idea of what's going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 02:33:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 02:33:21 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.7ece8a46f25ea110b56e57734f9c17eb@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Rev(s): Phab:D1278 Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I have had a look at this issue and I think the situation must have changed somewhat since the last time a fix was attempted. Several errors can be thrown during desugaring now, including at least - Top-level bindings for unlifted types aren't allowed: - Top-level strict pattern bindings aren't allowed: which I assume must not have previously been the case? If I add an unconditional desugaring in HscMain.finishTypecheckOnly then haddock errors on Ghc.Prim with "Top-level bindings for unlifted types aren't allowed:" This means that currently these desugaring errors are not thrown for modules compiled with -fno-code. I have pushed D3533 which includes a test for this. Let's add a special case to skip desugaring of Ghc.Prim? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 04:34:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 04:34:31 -0000 Subject: [GHC] #13638: configure error: GHC is required. In-Reply-To: <044.c4e2543e0d324fa37a617e40dbf250c3@haskell.org> References: <044.c4e2543e0d324fa37a617e40dbf250c3@haskell.org> Message-ID: <059.f0591fb30077b52d502b630cad55f0f2@haskell.org> #13638: configure error: GHC is required. -------------------------------------+------------------------------------- Reporter: QuRyu | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by QuRyu): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 07:30:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 07:30:12 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.f460fb01c2e0cabbff842de196dadee1@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I didn't even know we allowed constraints in kinds. We certainly should not allow lifted equality constraints, like `T :: forall k. (t1 ~ t2) => blah`. Because `(t1 ~ t2)` is represented by lifted, heap-allocated, possibly-bottom value, and we don't have a `case` expression in types to unpack it. Possibly we should allow unlifted equality `T :: forall k. (t1 ~# t2) => blah`. I'm not sure. But what you have is definitely wrong and should be rejected with a decent error message. (And the user manual should be fixed!) Richard what do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 08:55:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 08:55:44 -0000 Subject: [GHC] #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature In-Reply-To: <050.233776085b104a5b6592f82d271668fa@haskell.org> References: <050.233776085b104a5b6592f82d271668fa@haskell.org> Message-ID: <065.b34862d756211b90a805da29f655e8eb@haskell.org> #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 10:17:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 10:17:57 -0000 Subject: [GHC] #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc Message-ID: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In Haskell, 1. The scope of definitions can be controled. 2. The same name can be used to define both a function and a field of record. 3. The user can use that name in record pattern matching when only the function is within scope. For example {{{ FuncId{ name = nm } }}} resulting in the following bug {{{ [38 of 39] Compiling TxsUtils ( src\TxsUtils.hs, .stack- work\dist\1f7101f2\build\Txs Utils.o ) ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): translateConPatVec: lookup 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 May 4 10:18:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 10:18:36 -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.18928e2507ee91fc8b807952690293eb@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by pjljvdlaar): * Attachment "defs.zip" added. Example to reproduce the bug: use stack build -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 10:32:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 10:32:15 -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.61e9314fd7397243215feb921d3ab68e@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I bet this is a dup of #12158, which needs attention from someone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 11:17:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 11:17: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.9dac3379b15993b8f2a7db88bf851277@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pjljvdlaar): The issue occurs on line 157 of TxsUtils.hs @simonpj. I doubt it: the scoping is important, otherwise a nice warning is generated. {{{ C:\Users\pilaar\Desktop\TheMa\Experiments\Haskell\defs\src\TxsUtils.hs:157:37: error: Ambiguous occurrence `name' It could refer to either `TxsDefs.name', imported from `TxsDefs' at src\TxsUtils.hs:26:1-14 (and originally defined in `Ident') or `FuncId.name', imported from `FuncId' at src\TxsUtils.hs:28:1-13 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 12:18:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 12:18:09 -0000 Subject: [GHC] #13645: whoCreated produces an uninformative stack trace when an exception is raised in a CAF Message-ID: <045.54e4d2f019941a1dd30ba2696eddedff@haskell.org> #13645: whoCreated produces an uninformative stack trace when an exception is raised in a CAF -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} module Main where import Control.Exception import GHC.Stack {-# NOINLINE caf #-} caf :: [Int] caf = [1..500] {-# NOINLINE caf_exc #-} caf_exc :: Int caf_exc = caf !! 1000 {-# NOINLINE foo #-} foo :: Int -> Int foo 0 = caf_exc foo n = foo $ n - 1 {-# NOINLINE bar #-} bar :: Int -> Int bar n = bar' n where bar' 0 = foo n bar' m = bar' $ m - 1 main :: IO () main = print (bar 10) `catch` \(e :: SomeException) -> do stacktrace <- whoCreated e print stacktrace }}} By default, when built with profiling, `whoCreated` in the example above produces a quite uninformative stack trace: {{{#!shell $ ./caf-nostack ["GHC.List.CAF ()"] }}} However, if you run the program with `+RTS -xc`, you'll see that it prints a stack trace with much more context: {{{#!shell $ ./caf-nostack +RTS -xc *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: GHC.List.CAF --> evaluated by: Main.caf_exc, called from Main.CAF --> evaluated by: Main.foo, called from Main.bar.bar', called from Main.bar, called from Main.main, called from Main.CAF --> evaluated by: Main.main ["GHC.List.CAF ()"] }}} It'd be nice if `whoCreated` produced something closer to the `+RTS -xc` output in this case. Cabalised test project: https://github.com/23Skidoo/caf-nostack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 12:36:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 12:36:46 -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.377ec11523411ab11f8a670cca44323f@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I reduced the example to something with 4 files and no dependencies. To reproduce `ghc Repo.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 12:37:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 12:37:13 -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.e7be04ed76cc4fecfcd1fc476f7da1c8@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * Attachment "repo.zip" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 12:37:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 12:37:43 -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.d1e9582f235b0c18d1b1fc4900bea225@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed it probably would be better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 12:40:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 12:40: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.2371f95c078f22fa21076ebd79b93d18@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Triggers an assertion failure with a `DEBUG` compiler. {{{ [1 of 4] Compiling FuncId2 ( FuncId2.hs, FuncId2.o ) [2 of 4] Compiling Ident2 ( Ident2.hs, Ident2.o ) [3 of 4] Compiling TxsDefs2 ( TxsDefs2.hs, TxsDefs2.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170412 for x86_64-apple-darwin): ASSERT failed! file compiler/typecheck/TcRnExports.hs, line 604 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 May 4 13:06:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 13:06:17 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.4d35b897b8ef2f20564601cd708c0243@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Good questions. Here are my thoughts: - Satisfying kind-level equality constraints is implemented in `Inst.tcInstBinderX`, called when a type is applied to some arguments. The code there handles both unboxed equality and boxed equality. - The "no `case`" problem in Simon's comment:5 is quite true. But this is OK, because such an equality constraint can never be a Given: constraints in types can't be used within the same type, but (I believe) these constraints scope only over a type (never a term). - This last point makes these new constraints somewhat like datatype contexts, but one does not desugar into the other. - Clearly, the output from `:info` is horrible. - The "no `forall` needed" is an interaction with CUSKs. This point should be clarified in the manual. - "Constrained type families" interacts poorly with today's story for kind families: constrained type families requires the use of class constraints, but class constraints aren't currently allowed in kinds. It would seem that it's best to implement constrained type families in the context of Dependent Haskell. - Bottom line: this feature is probably a misfire. It ''is'' marginally useful, as I think the example from the manual demonstrates. (That seems useful to me, at least.) But the implementation is very ad-hoc, and the fact that these constraints never appear as Givens take much of the air out of them. It would be easy enough to remove this feature for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 13:16:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 13: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.28200186bdaeab3c5663c0c42c641320@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: (none) => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 13:21:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 13:21:57 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.bf107b7d3c23a762c75c1faeabc2248b@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm still lost. Even if they are wanteds, that still means we are going to get term-level variables appearing in types, at the occurrences of `T`. If you say we can get rid of them, let's get rid of them. Aasp! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 13:47:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 13:47:12 -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.465bd8652786d189f8d45ede1609f72a@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I put the test up on phab. https://phabricator.haskell.org/D3535 The problem is in TcPat.find_field_ty but I can't see how to cleanly fix it. In the renamer we don't care yet whether a record selector is the right one for the data constructor. When we check in the type checker, all the verify is that the `OccName` of the selector is one of the field labels of the right data constructor. We don't compare `Name`s at all like we should do because of something to do with ORF. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 13:47:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 13:47:23 -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.e96fa0c00637d50f186a631145ca4717@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: mpickering => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 14:23:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 14:23:35 -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.0a31412d8527727e92780473be52a27f@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think this is exactly #12158 as Simon suggested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 16:27:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 16:27:22 -0000 Subject: [GHC] #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature In-Reply-To: <050.233776085b104a5b6592f82d271668fa@haskell.org> References: <050.233776085b104a5b6592f82d271668fa@haskell.org> Message-ID: <065.e568e544f53a70489a6854c799ef31e3@haskell.org> #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e77019767fe5327011c6dc8fe089c64884120aab/ghc" e770197/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e77019767fe5327011c6dc8fe089c64884120aab" Deal with exceptions in dsWhenNoErrs Gracious me. Ever since this patch commit 374457809de343f409fbeea0a885877947a133a2 Author: Jan Stolarek Date: Fri Jul 11 13:54:45 2014 +0200 Injective type families TcRnMonad.askNoErrs has been wrong. It looked like this askNoErrs :: TcRn a -> TcRn (a, Bool) askNoErrs m = do { errs_var <- newTcRef emptyMessages ; res <- setErrsVar errs_var m ; (warns, errs) <- readTcRef errs_var ; addMessages (warns, errs) ; return (res, isEmptyBag errs) } The trouble comes if 'm' throws an exception in the TcRn monad. Then 'errs_var is never read, so any errors are simply lost. This mistake was then propgated into DsMonad.dsWhenNoErrs, where it gave rise to Trac #13642. Thank to Ryan for narrowing it down so sharply. I did some refactoring, as usual. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 16:28:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 16:28:30 -0000 Subject: [GHC] #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature In-Reply-To: <050.233776085b104a5b6592f82d271668fa@haskell.org> References: <050.233776085b104a5b6592f82d271668fa@haskell.org> Message-ID: <065.98457c3f5d258558c062ecf16ea6a040@haskell.org> #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T13642.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => th/T13642.hs Comment: Good stuff. Fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 17:17:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 17:17:59 -0000 Subject: [GHC] #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) In-Reply-To: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> References: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> Message-ID: <060.52d92dffaf5603ebbaa8b230299a3675@haskell.org> #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) -------------------------------------+------------------------------------- Reporter: Ptival | Owner: dfeuer Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | UndecidableInstances loop 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 David Feuer ): In [changeset:"cb850e01560adf12e83fcf85f479636be17d017c/ghc" cb850e0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cb850e01560adf12e83fcf85f479636be17d017c" Add test for #13320 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13320 Differential Revision: https://phabricator.haskell.org/D3532 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 17:18:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 17:18:28 -0000 Subject: [GHC] #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) In-Reply-To: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> References: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> Message-ID: <060.3f643ae4c55837318be6d1b4422f6dd3@haskell.org> #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) -------------------------------------+------------------------------------- Reporter: Ptival | Owner: dfeuer Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | UndecidableInstances loop 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:D3532 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * component: Compiler => Compiler (Type checker) * differential: => phab:D3532 * resolution: => fixed * milestone: => 8.2.1 Comment: Test case added as phab:D3532. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 17:40:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 17:40:39 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.06752b5671f3b665a39d3772cddf268c@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: (none) => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 19:38:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 19:38:44 -0000 Subject: [GHC] #11272: Overloaded state-monadic function is not specialised In-Reply-To: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> References: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> Message-ID: <067.53b4e3751ed718ec5ba21f81c93f741e@haskell.org> #11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): This appears to be fixed in HEAD (as long as `overloaded` has an `INLINABLE` pragma. I'm not sure how test cases for this sort of thing are supposed to be added to the test suite; should I be digging through `-ddump-rule-firings` or somethinhg? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 19:46:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 19:46:34 -0000 Subject: [GHC] #12600: Overloaded method causes insufficient specialization In-Reply-To: <043.07cdd679c81a8644725c82782d392414@haskell.org> References: <043.07cdd679c81a8644725c82782d392414@haskell.org> Message-ID: <058.65c8799d4ac80fe482a0d9d13563cf74@haskell.org> #12600: Overloaded method causes insufficient specialization -------------------------------------+------------------------------------- Reporter: akio | 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 dfeuer): This appears to be fixed in HEAD, without even using `INLINE` pragmas. I don't know the Right Way to write a test for it yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 20:40:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 20:40:40 -0000 Subject: [GHC] #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused-pattern-binds Message-ID: <044.32e35139f2ee897ece4f6184af2a605d@haskell.org> #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused- pattern-binds -------------------------------------+------------------------------------- Reporter: exphp | 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: -------------------------------------+------------------------------------- In each of the following programs, a bang pattern is used to force evaluation of a bottom, the intent being to perform fail-fast error checking. Unfortunately, however, they also generate `-Wunused-pattern- binds`. {{{#!hs {-# OPTIONS_GHC -Wall #-} {-# LANGUAGE BangPatterns #-} main :: IO () main = do let !Nothing = Just () pure () }}} {{{#!hs {-# OPTIONS_GHC -Wall #-} {-# LANGUAGE BangPatterns #-} import Control.Exception main :: IO () main = do let !() = assert False () pure () }}} {{{ src/Lib.hs:6:9: warning: [-Wunused-pattern-binds] This pattern-binding binds no variables: !Nothing = Just () Linking src/Lib ... Lib: src/Lib.hs:6:9-26: Irrefutable pattern failed for pattern Nothing -------------------- src/Lib.hs:8:9: warning: [-Wunused-pattern-binds] This pattern-binding binds no variables: !() = assert False () Linking src/Lib ... Lib: Assertion failed CallStack (from HasCallStack): assert, called at src/Lib.hs:8:15 in main:Main }}} For clarity, non-monadic `let ... in` patterns are also affected; I only gloss over them because there tends to be other equally ergonomic alternatives in such cases. I found this #9127 (ticket), where a patch was accepted to allow wildcards of the form `!_`. However, `!_` is unsatisfactory and perhaps even dangerous for such usage, as it does not constrain the type in any manner. In particular, there is nothing to prevent somebody from writing {{{#!hs main = do let !_ = assert someCondition -- (missing an argument) pure () }}} which //is// in fact useless. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 22:22:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 22:22:33 -0000 Subject: [GHC] #13632: Frontend plugin arguments are reversed In-Reply-To: <043.ec28fd3dbabc434a0844f0f3787cf432@haskell.org> References: <043.ec28fd3dbabc434a0844f0f3787cf432@haskell.org> Message-ID: <058.1c6af7ec2251f4291b135084f48193a1@haskell.org> #13632: Frontend plugin arguments are reversed -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: frontend01 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"db10b79994f7728cbaaa906c6f6eda0b6783df29/ghc" db10b79/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="db10b79994f7728cbaaa906c6f6eda0b6783df29" Pass -ffrontend-opt arguments to frontend plugin in the correct order Previously they were passed in the reverse order that they're specified on the command line. Add a haddock to frontendPluginOpts in DynFlags.hs. Modify test frontend01 to cover the case of multiple -ffrontend-opt. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13632 Differential Revision: https://phabricator.haskell.org/D3520 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 22:22:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 22:22:33 -0000 Subject: [GHC] #11616: Kinds aren't instantiated In-Reply-To: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> References: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> Message-ID: <066.776a2d939cd2b48318655276595a8327@haskell.org> #11616: Kinds aren't instantiated -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D3531 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"03ca391f14f97486fd1c66d9c9d99686ae25cc10/ghc" 03ca391f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="03ca391f14f97486fd1c66d9c9d99686ae25cc10" Add regression test for #11616 The code in #11616 has been working for a while (ever since 8.0.1), so let's add a regression test for it to put the nail in the coffin. Test Plan: make test TEST=T11616 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #11616 Differential Revision: https://phabricator.haskell.org/D3531 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 22:22:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 22:22:33 -0000 Subject: [GHC] #11799: Legend for hpc markup colors In-Reply-To: <047.314ffbb861201aff98726d88b5f478b7@haskell.org> References: <047.314ffbb861201aff98726d88b5f478b7@haskell.org> Message-ID: <062.8e20d138e26f4c92c14f3a597df73d28@haskell.org> #11799: Legend for hpc markup colors -------------------------------------+------------------------------------- Reporter: drathier | Owner: SantiM Type: feature request | Status: new Priority: normal | Milestone: Component: Code Coverage | 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: | Differential Rev(s): Phab:D3465, Wiki Page: | Phab:D3479 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8a2c2476b300969514888cb2084d083f8d18b6b0/ghc" 8a2c2476/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a2c2476b300969514888cb2084d083f8d18b6b0" hpc: Output a legend at the top of output files Updates hpc submodule. Reviewers: austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #11799 Differential Revision: https://phabricator.haskell.org/D3465 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 22:22:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 22:22:33 -0000 Subject: [GHC] #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope In-Reply-To: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> References: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> Message-ID: <065.f1ae428b6fd26275813fc41507f38d3c@haskell.org> #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: mpickering Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3515 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1829d265662ca8d052df3e5df1aa1137b19e39ce/ghc" 1829d26/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1829d265662ca8d052df3e5df1aa1137b19e39ce" Implement sequential name lookup properly Previously we would run all the monadic actions and then combine their results. This caused problems if later actions raised errors but earlier lookups suceeded. We only want to run later lookups if the earlier ones fail. Fixes #13622 Reviewers: RyanGlScott, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13622 Differential Revision: https://phabricator.haskell.org/D3515 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 4 22:22:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 May 2017 22:22:33 -0000 Subject: [GHC] #13564: Why does memory usage increase so much during CoreTidy? In-Reply-To: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> References: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> Message-ID: <062.27ce110430cedae38264ba0638a6f069@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3516, Wiki Page: | Phab:D3524 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b3da6a6c3546562d5c5e83b8af5d3fd04c07e0c1/ghc" b3da6a6c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b3da6a6c3546562d5c5e83b8af5d3fd04c07e0c1" CoreTidy: Don't seq unfoldings Previously we would force uf_is_value and friends to ensure that we didn't retain a reference to the pre-tidying template, resulting in a space leak. Instead, we now just reinitialize these fields (despite the fact that they should not have changed). This may result in a bit more computation, but most of the time we won't ever evaluate them anyways, so the damage shouldn't be so bad. See #13564. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 01:03:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 01:03:11 -0000 Subject: [GHC] #13632: Frontend plugin arguments are reversed In-Reply-To: <043.ec28fd3dbabc434a0844f0f3787cf432@haskell.org> References: <043.ec28fd3dbabc434a0844f0f3787cf432@haskell.org> Message-ID: <058.8952f03c253f5669be4b4d8889ada9b3@haskell.org> #13632: Frontend plugin arguments are reversed -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: GHC API | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: frontend01 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Thanks duog! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 01:04:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 01:04:37 -0000 Subject: [GHC] #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope In-Reply-To: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> References: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> Message-ID: <065.3f5744724ce992d108e90357d05d2a62@haskell.org> #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: mpickering Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3515 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 01:05:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 01:05:15 -0000 Subject: [GHC] #11799: Legend for hpc markup colors In-Reply-To: <047.314ffbb861201aff98726d88b5f478b7@haskell.org> References: <047.314ffbb861201aff98726d88b5f478b7@haskell.org> Message-ID: <062.29171ec68f9996accec3523c6a4553c7@haskell.org> #11799: Legend for hpc markup colors -------------------------------------+------------------------------------- Reporter: drathier | Owner: SantiM Type: feature request | Status: merge Priority: normal | Milestone: 8.2.1 Component: Code Coverage | 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: | Differential Rev(s): Phab:D3465, Wiki Page: | Phab:D3479 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 01:05:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 01:05:54 -0000 Subject: [GHC] #11616: Kinds aren't instantiated In-Reply-To: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> References: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> Message-ID: <066.d6410321b4cd4c8eb3abee1b98f79f68@haskell.org> #11616: Kinds aren't instantiated -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: merge Priority: normal | Milestone: 8.2.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: | Differential Rev(s): Phab:D3531 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 02:55:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 02:55:24 -0000 Subject: [GHC] #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature In-Reply-To: <050.233776085b104a5b6592f82d271668fa@haskell.org> References: <050.233776085b104a5b6592f82d271668fa@haskell.org> Message-ID: <065.e9e691036709aee6269346588d1278aa@haskell.org> #13642: GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.2.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T13642.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Merged with c7642debda55509d805036c28c9804f6c587d44b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 02:55:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 02:55:57 -0000 Subject: [GHC] #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) In-Reply-To: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> References: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> Message-ID: <060.5ac64595c9d36442dfd5adcef4b50399@haskell.org> #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) -------------------------------------+------------------------------------- Reporter: Ptival | Owner: dfeuer Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | UndecidableInstances loop 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:D3532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Test merged with 561553fe424e2f2e3500b635655fe6d9c294c666. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 02:56:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 02:56:31 -0000 Subject: [GHC] #13632: Frontend plugin arguments are reversed In-Reply-To: <043.ec28fd3dbabc434a0844f0f3787cf432@haskell.org> References: <043.ec28fd3dbabc434a0844f0f3787cf432@haskell.org> Message-ID: <058.6d9887d86bd2d92ad8f2520b7a88ab5b@haskell.org> #13632: Frontend plugin arguments are reversed -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: GHC API | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: frontend01 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.2` with 771e8d6838238fe87b2282696bff77fd4c474f71. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 02:57:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 02:57:23 -0000 Subject: [GHC] #11616: Kinds aren't instantiated In-Reply-To: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> References: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> Message-ID: <066.1c5ed27b9aea66b31d73afeddcd15d49@haskell.org> #11616: Kinds aren't instantiated -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3531 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with df44a60a5b98490cf02b8b91f292de935e6da1df. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 02:57:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 02:57:42 -0000 Subject: [GHC] #11799: Legend for hpc markup colors In-Reply-To: <047.314ffbb861201aff98726d88b5f478b7@haskell.org> References: <047.314ffbb861201aff98726d88b5f478b7@haskell.org> Message-ID: <062.08f79ff71a91da3025db4eb1322b426f@haskell.org> #11799: Legend for hpc markup colors -------------------------------------+------------------------------------- Reporter: drathier | Owner: SantiM Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Code Coverage | Version: 7.10.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3465, Wiki Page: | Phab:D3479 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 771e8d6838238fe87b2282696bff77fd4c474f71. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 02:58:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 02:58:06 -0000 Subject: [GHC] #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope In-Reply-To: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> References: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> Message-ID: <065.4c2cb2f62bc80a232d28257fc1bb3422@haskell.org> #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: mpickering Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3515 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 0c845697e054b5e30e76a801c7ebc78238c8268a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 07:34:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 07:34:26 -0000 Subject: [GHC] #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused-pattern-binds In-Reply-To: <044.32e35139f2ee897ece4f6184af2a605d@haskell.org> References: <044.32e35139f2ee897ece4f6184af2a605d@haskell.org> Message-ID: <059.5b11e82fa2b022abded68abbfb5d987c@haskell.org> #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused- pattern-binds -------------------------------------+------------------------------------- Reporter: exphp | 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): Yes I see the point. Perhaps we should suppress this warning if the pattern has an outmost bang. Does anyone object? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 09:29:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 09:29:47 -0000 Subject: [GHC] #13647: Tidy up TcTypeable Message-ID: <046.ce5bf479308764e177daf1d80c7aa0cd@haskell.org> #13647: Tidy up TcTypeable -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is code in `TcTypeable` that generates a `KindRep` for each `TyCon` (see `Note [Representing TyCon kinds: KindRep]`). There's nothing actually wrong with it. But it's pretty hard to understand. And it generates a staggering amount of data structure, when compiling `GHC.Types`. {{{ Result size of Tidy Core = {terms: 74,615, types: 41,335, coercions: 2, joins: 0/0} }}} Why? Well, it injects a `TyCon` binding for each unboxed tuple size. For example, here is the code for pairs `(#,#)` {{{ $tc(#,#) = TyCon 16533601304077481746## 7902994497850328874## tr$ModuleGHCPrim $tc(#,#)2 2# $tc(#,#)1 -- TYPE #0 -> TYPE #1 -> TYPE (TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)))) $tc(#,#)1 :: KindRep $tc(#,#)1 = KindRepFun $krep2115_r6ji $krep18009_rarE $krep18009_rarE = KindRepFun $krep2117_r6jk $krep18008_rarD -- TYPE (TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)))) $krep18008_rarD = KindRepTyConApp $tcTYPE $krep18007_rarC $krep18007_rarC = : @ KindRep $krep18006_rarB ([] @ KindRep) -- TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep))) $krep18006_rarB = KindRepTyConApp $tc'TupleRep $krep18005_rarA $krep18005_rarA = : @ KindRep $krep2283_r6m0 ([] @ KindRep) -- ': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)) $krep2283_r6m0 = KindRepTyConApp $tc': $krep2282_r6lZ $krep2282_r6lZ = : @ KindRep $tc'AddrRep1 $krep2281_r6lY $krep2281_r6lY = : @ KindRep $krep61_r5Ma $krep2280_r6lX $krep2280_r6lX = : @ KindRep $krep2279_r6lW ([] @ KindRep) -- ': RuntimeRep #1 ('[] RuntimeRep) $krep2279_r6lW = KindRepTyConApp $tc': $krep2278_r6lV $krep2278_r6lV = : @ KindRep $tc'AddrRep1 $krep2277_r6lU $krep2277_r6lU = : @ KindRep $krep60_r5M9 $krep2276_r6lT $krep2276_r6lT = : @ KindRep $krep2274_r6lR ([] @ KindRep) -- '[] RuntimeRep $krep2274_r6lR = KindRepTyConApp $tc'[] $krep2273_r6lQ $krep2273_r6lQ = : @ KindRep $tc'AddrRep1 ([] @ KindRep) -- RuntimeRep $tc'AddrRep1 = KindRepTyConApp $tcRuntimeRep ([] @ KindRep) -------------- TYPE #0 $krep2115_r6ji = KindRepTyConApp $tcTYPE $krep2114_r6jh $krep2114_r6jh = : @ KindRep $krep61_r5Ma ([] @ KindRep) $krep61_r5Ma = KindRepVar 0# -------------- TYPE #1 $krep2117_r6jk = KindRepTyConApp $tcTYPE $krep2116_r6jj $krep2116_r6jj = : @ KindRep $krep60_r5M9 ([] @ KindRep) $krep60_r5M9 = KindRepVar 1# }}} That's a lot, and it's only for pairs. We generate all this up to 62-tuples! Suggestions (read `Note [Representing TyCon kinds: KindRep]` first) * `KindRep` is a description of a polykind; an interpreter, called `instantiateKindRep` turns it into a kind. So we can add whatever constructors we like to `KindRep`. * One good one would be `UnboxedTupleRep n`, which `instantiateKindRep` can instantiate to the kind of an unboxed tuple. It just moves the work somewhere else, of course, but it will make the generated code dramatically smaller. * We have a few canned kind-reps, via `TcTypeable.builtInKindReps`. It'd be simpler and easier instead to make each of them into a data constructor of `KindRep`. * Once that is done, I suspect that the entire machinery of tyring to share `KindReps` (which makes my head hurt) would be unnecessary None of this is essential, but I think that matters can be improved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 09:53:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 09:53:01 -0000 Subject: [GHC] #13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns. Message-ID: <049.3862587f91a2eaa8b116ce19f5a50e51@haskell.org> #13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 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: -------------------------------------+------------------------------------- GHC 8.0.2 and 8.2.1-rc1 (rc2 not checked) have a bug where -XApplicativeDo causes "GHC.Base.Monad.return" to be used instead of the locally available "return", and a spurious "return ()" shows up. This desugaring is not adhering to the -XRebindableSyntax spec (see: #12490). Example: {{{#!hs {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE RebindableSyntax #-} -- Bug vanishes if this next line is removed: {-# LANGUAGE ApplicativeDo #-} module Main where import Prelude (String, print) class MyFunctor f where fmap :: (a -> b) -> f a -> f b class MyApplicative f where pure :: a -> f a (<*>) :: f (a -> b) -> f a -> f b class MyMonad m where return :: a -> m a (>>) :: m a -> m b -> m b (>>=) :: m a -> (a -> m b) -> m b fail :: String -> m a join :: m (m a) -> m a testCase1 m1 m2 = do m1 m2 return () testCase2 m1 m2 = do _ <- m1 _ <- m2 return () main = print "42" }}} {{{ :t testCase1 testCase1 :: (MyFunctor f, MyApplicative f, MyMonad f, Monad f) => f a2 -> f a1 -> f () :t testCase2 :: testCase2 :: (MyFunctor f, MyApplicative f) => f t -> f a -> f () }}} The desugaring for testCase1 shows the issue: {{{#!hs testCase1' m1 m2 = (<*>) (fmap (\() () -> ()) (m1 >> (GHC.Base.Monad.return ()))) (m2 >> (GHC.Base.Monad.return ())) -- or: testCase1' m1 m2 = (fmap (\() () -> () ) (m1 >> (return ()))) <*> (m2 >> (return ())) }}} I would be able to work on this if someone pointed me in the right direction. It looks like it would be in `compiler/rename/RnEnv` and `compiler/rename/RnExpr`, as with #12490? As a proposed fix, I would want to implement a limited-scope fix before the 8.2.1 release which would not address the thornier issue of #10892. The patch would: 1. Replace `GHC.Base.Monad.return` with local `pure`, removing the `Monad` constraint. 2. Replace `>>` with `*>`, removing the `MyMonad` constraint. This isn't a _complete_ fix, as this would still induce an unnecessary use of the local `fmap`, but it would reduce the desugaring bug in `testCase1` to only that local `fmap`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 09:58:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 09:58:27 -0000 Subject: [GHC] #13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns. In-Reply-To: <049.3862587f91a2eaa8b116ce19f5a50e51@haskell.org> References: <049.3862587f91a2eaa8b116ce19f5a50e51@haskell.org> Message-ID: <064.053b6ca76da2b9fb636f6bc62c71cf5a@haskell.org> #13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by AaronFriel: @@ -61,1 +61,2 @@ - (\() () -> ()) + (\ r1 r2 -> + case r1 of { () -> case r2 of { () -> () } }) @@ -65,2 +66,2 @@ - testCase1' m1 m2 = (fmap (\() () -> () ) (m1 >> (return ()))) <*> (m2 >> - (return ())) + testCase1'' m1 m2 = (fmap (\() () -> () ) (m1 >> (GHC.Base.Monad.return + ()))) <*> (m2 >> (GHC.Base.Monad.return ())) @@ -81,3 +82,8 @@ - This isn't a _complete_ fix, as this would still induce an unnecessary use - of the local `fmap`, but it would reduce the desugaring bug in `testCase1` - to only that local `fmap`. + This isn't a _complete_ fix, as this would still leave the unnecessary + pattern matches in the use of `fmap`. The resulting desugaring would be: + + + {{{#!hs + testCase1''' m1 m2 = (fmap (\() () -> () ) (m1 *> (pure ()))) <*> (m2 *> + (pure ())) + }}} New description: GHC 8.0.2 and 8.2.1-rc1 (rc2 not checked) have a bug where -XApplicativeDo causes "GHC.Base.Monad.return" to be used instead of the locally available "return", and a spurious "return ()" shows up. This desugaring is not adhering to the -XRebindableSyntax spec (see: #12490). Example: {{{#!hs {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE RebindableSyntax #-} -- Bug vanishes if this next line is removed: {-# LANGUAGE ApplicativeDo #-} module Main where import Prelude (String, print) class MyFunctor f where fmap :: (a -> b) -> f a -> f b class MyApplicative f where pure :: a -> f a (<*>) :: f (a -> b) -> f a -> f b class MyMonad m where return :: a -> m a (>>) :: m a -> m b -> m b (>>=) :: m a -> (a -> m b) -> m b fail :: String -> m a join :: m (m a) -> m a testCase1 m1 m2 = do m1 m2 return () testCase2 m1 m2 = do _ <- m1 _ <- m2 return () main = print "42" }}} {{{ :t testCase1 testCase1 :: (MyFunctor f, MyApplicative f, MyMonad f, Monad f) => f a2 -> f a1 -> f () :t testCase2 :: testCase2 :: (MyFunctor f, MyApplicative f) => f t -> f a -> f () }}} The desugaring for testCase1 shows the issue: {{{#!hs testCase1' m1 m2 = (<*>) (fmap (\ r1 r2 -> case r1 of { () -> case r2 of { () -> () } }) (m1 >> (GHC.Base.Monad.return ()))) (m2 >> (GHC.Base.Monad.return ())) -- or: testCase1'' m1 m2 = (fmap (\() () -> () ) (m1 >> (GHC.Base.Monad.return ()))) <*> (m2 >> (GHC.Base.Monad.return ())) }}} I would be able to work on this if someone pointed me in the right direction. It looks like it would be in `compiler/rename/RnEnv` and `compiler/rename/RnExpr`, as with #12490? As a proposed fix, I would want to implement a limited-scope fix before the 8.2.1 release which would not address the thornier issue of #10892. The patch would: 1. Replace `GHC.Base.Monad.return` with local `pure`, removing the `Monad` constraint. 2. Replace `>>` with `*>`, removing the `MyMonad` constraint. This isn't a _complete_ fix, as this would still leave the unnecessary pattern matches in the use of `fmap`. The resulting desugaring would be: {{{#!hs testCase1''' m1 m2 = (fmap (\() () -> () ) (m1 *> (pure ()))) <*> (m2 *> (pure ())) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 10:33:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 10:33:45 -0000 Subject: [GHC] #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. Message-ID: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Keywords: | Operating System: Unknown/Multiple RebindableSyntax | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With -XRebindableSyntax and a wildcard pattern on an action, a spurious compiler error occurs if `fail` is not in scope: {{{ Not in scope: ‘fail’ Perhaps you want to add ‘fail’ to the import list in the import of ‘Prelude’ (rebind.hs:6:1-53). | 27 | _ <- m1 | ^^^^^^^ }}} {{{#!hs {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE RebindableSyntax #-} module Main where import Prelude (String, print, Maybe (..), error, id) class MyFunctor f where fmap :: (a -> b) -> f a -> f b class MyApplicative f where pure :: a -> f a (<*>) :: f (a -> b) -> f a -> f b class MyMonad m where return :: a -> m a (>>) :: m a -> m b -> m b (>>=) :: m a -> (a -> m b) -> m b join :: m (m a) -> m a -- Uncommenting the following lines allows testCase1 to compile: -- class MyFail m where -- fail :: String -> m a -- But testCase1 will not require a 'MyFail m' constraint. testCase1 :: MyMonad m => m a -> m () testCase1 m1 = do _ <- m1 return () testCase2 :: MyMonad m => m a -> m () testCase2 m1 = do m1 return () }}} In this example, testCase1 will fail to compile until the type class `MyFail` is uncommented. As with #13648, I think this looks like an easy fix before the 8.2.1 release, and I would be happy to submit a patch next week if someone could point me the way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 10:57:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 10:57:50 -0000 Subject: [GHC] #13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns. In-Reply-To: <049.3862587f91a2eaa8b116ce19f5a50e51@haskell.org> References: <049.3862587f91a2eaa8b116ce19f5a50e51@haskell.org> Message-ID: <064.8a4220b8fd12e5fbbed4c396a0425846@haskell.org> #13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 12:32:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 12:32:43 -0000 Subject: [GHC] #12075: Fails to build on powerpcspe because of inline assembly In-Reply-To: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> References: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> Message-ID: <062.338ed267e09c9ea4ee8b19885b8dc9ae@haskell.org> #12075: Fails to build on powerpcspe because of inline assembly ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Comment (by glaubitz): Correction: My previous explanation in comment 7 contains a mistake. It's not AdjustorAsm.S which needs to be disabled but StgCRun.S as it also becomes obvious from error messages listed in the original message to this bug report. The reason why I suspected AdjustorAsm.S is because I commented out the whole block around 'ifneq "$(PORTING_HOST)" "YES"' and just read the following condition 'ifneq "$(findstring $(TargetArch_CPP), powerpc64le)" ""' as "match for powerpc64le only' but, of course, it's the other way around. It matches for all architectures except powerpc64le. Furthermore, AdjustorAsm.S doesn't even contain any code which is built on powerpc32/linux, just powerpc32 code which builds on non-Linux targets. Thus, could you move the guarding 'ifneq "$(POWERPC_NO_FPRS)" "YES" ... endif' away from AdjustorAsm.S and put it around StgCRun.S? This is also what I did for the suggested patch for the Debian package [1]. > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861806 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 13:16:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 13:16:32 -0000 Subject: [GHC] #13647: Tidy up TcTypeable In-Reply-To: <046.ce5bf479308764e177daf1d80c7aa0cd@haskell.org> References: <046.ce5bf479308764e177daf1d80c7aa0cd@haskell.org> Message-ID: <061.46ff220073563f71105688e0a5039062@haskell.org> #13647: Tidy up TcTypeable -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed I had considered giving tuple `KindRep`s special treatment, but was reluctant to implement a solution that would only target `GHC.Types`. Yes, `GHC.Types` does get larger, > Once that is done, I suspect that the entire machinery of tyring to share KindReps (which makes my head hurt) would be unnecessary I am not convinced it would be wise to drop the sharing. Afterall, the problem that you describe above above does not affect only `GHC.Types`. There were some programs in `nofib` whose compiler allocations increased drastically due to `TTypeable` as well. The patches introducing sharing (a694cee77b64235b42029fea248453ddf6b17d17) and "canned" KindReps (c1dacb8a9c18677495bbe7e41391f8ca7a573070) both helped immensely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 14:04:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 14:04:25 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.3d06c33de53e2140357a709fa9cd3126@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12919 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Much simpler case of what I believe is the same underlying error: #13643. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 14:04:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 14:04:42 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.ac3130166e43fb0d0a9ee045c38e818f@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12919 Blocked By: | Blocking: Related Tickets: #13643 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #13643 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 14:06:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 14:06:17 -0000 Subject: [GHC] #13643: Core lint error with TypeInType and TypeFamilyDependencies In-Reply-To: <051.99866398c3b30eccc01358213362b7d9@haskell.org> References: <051.99866398c3b30eccc01358213362b7d9@haskell.org> Message-ID: <066.e1dd493d5c4b6ee6fead04f569190669@haskell.org> #13643: Core lint error with TypeInType and TypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | InjectiveFamilies, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12102 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I believe this is the same as #12919, although the symptoms are markedly different. The problem is that (because flattened types have flattened kinds), flattening `T I (False |> co)` (where `co :: Bool ~ Interp I`) yields the ill-kinded `T I False`. Instead, we should change the kind invariant on flattening to say that flattening does not change a type's kind. Then this problem (and #12919) are fixed. I hope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 14:06:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 14:06:29 -0000 Subject: [GHC] #13643: Core lint error with TypeInType and TypeFamilyDependencies In-Reply-To: <051.99866398c3b30eccc01358213362b7d9@haskell.org> References: <051.99866398c3b30eccc01358213362b7d9@haskell.org> Message-ID: <066.9738676089d7c0b51f898ed0429dd545@haskell.org> #13643: Core lint error with TypeInType and TypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | InjectiveFamilies, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12102 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): With HEAD I get {{{ : warning: In the expression: $fShowT @ 'I @ 'False Kinds don't match in type application: Type variable: a2_a18K :: Interp 'I Arg type: 'False :: Bool Linted Arg kind: Bool : warning: In the type ‘Show (T 'I 'False)’ Kind application error in type ‘T 'I 'False’ Function kind = forall (a :: Code). Interp a -> * Arg kinds = [('I, Code), ('False, Bool)] : warning: [RHS of $dShow_a18r :: Show (T 'I ('False |> Sym (D:R:Interp[0])))] Kind application error in coercion ‘(T <'I>_N (Sym (Coh (Sym (Coh <'False>_N (Trans (Sym (D:R:Interp[0])) (D:R:Interp[0])))) (Sym (D:R:Interp[0])))))_N’ Function kind = forall (a :: Code). Interp a -> * Arg kinds = [('I, Code), ('False, Bool)] }}} Look at at the type in the second error: {{{ In the type ‘Show (T 'I 'False)’ }}} It's ill-kinded! I discussed with Richard and this is just another example of #12919. Consider what happens if we flatten {{{ T 'I ('False |> g) }}} we'll get the flattened type {{{ T 'I 'False }}} (plus a coercion), which is ill-kinded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 14:07:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 14:07:26 -0000 Subject: [GHC] #13643: Core lint error with TypeInType and TypeFamilyDependencies In-Reply-To: <051.99866398c3b30eccc01358213362b7d9@haskell.org> References: <051.99866398c3b30eccc01358213362b7d9@haskell.org> Message-ID: <066.b1bae75e4cb866f5973e61c1dbc70aa4@haskell.org> #13643: Core lint error with TypeInType and TypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | InjectiveFamilies, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * related: #12102 => Comment: #12102 is unrelated, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 14:09:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 14:09:16 -0000 Subject: [GHC] #11272: Overloaded state-monadic function is not specialised In-Reply-To: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> References: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> Message-ID: <067.ab7fef407ad4170562ad719770664669@haskell.org> #11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > should I be digging through -ddump-rule-firings or somethinhg? Either that or test `-ddump-simpl`. Both are sadly rather fragile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 14:11:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 14:11:52 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.78f5a67ff10076254bc3d222dc4902c2@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > If you say we can get rid of them, let's get rid of them. Aasp! Richard agrees. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 14:51:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 14:51:22 -0000 Subject: [GHC] #13650: Implement KPush in types Message-ID: <047.e26721ad30e2e3d90c01c9e924788439@haskell.org> #13650: Implement KPush in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A recent commit contributed a [https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/Type.hs;a483e711da7834bc952367f554ac4e877b4e157a$1191 Note] that explains why we need the dreaded KPush rule to be implemented in `splitTyConApp`. Without KPush there, it's possible that we can have two types t1 and t2 such that {{{t1 `eqType` t2}}} and yet they respond differently to `splitTyConApp`: t1 = `(T |> co1) (a |> co2)` and t2 = `T a`. Both t1 and t2 are well-kinded and can have the same kind. But one is a `TyConApp` and one is an `AppTy`. (Actually, looking at this, perhaps the magic will be in `mkAppTy`, not `splitTyConApp`.) But I have to look closer. This ticket serves as a reminder to do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 14:51:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 14:51:31 -0000 Subject: [GHC] #13650: Implement KPush in types In-Reply-To: <047.e26721ad30e2e3d90c01c9e924788439@haskell.org> References: <047.e26721ad30e2e3d90c01c9e924788439@haskell.org> Message-ID: <062.9e47e34a8eea6a183bbad3f11c2c8f73@haskell.org> #13650: Implement KPush in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: (none) => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 15:29:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 15:29:29 -0000 Subject: [GHC] #12075: Fails to build on powerpcspe because of inline assembly In-Reply-To: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> References: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> Message-ID: <062.9450871c655802cf5dda73102afafcc8@haskell.org> #12075: Fails to build on powerpcspe because of inline assembly ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Changes (by trommler): * component: Compiler (NCG) => Build System Comment: Replying to [comment:5 glaubitz]: > > That's exactly the problem. The inline assembly is there and used even when "--enable-unregisterised" was passed to "configure". Apparently, it just checks for "powerpc" and ignores the "--enable-unregistrised". I wonder why the assembly code in `StgCRun.c` causes a problem here. In an unregisterised compiler `USE_MINIINTERPRETER` is defined in `includes/ghc.mk` and ordinary C code should be used for `StgRun()` and `StgReturn()`. I don't see that define in the command lines in the ticket. To be sure we have an issue with the build system, could you clean your source tree and configure the compiler with `--enable-unregisterised` and then compile again. BTW `StgCRunAsm.S` should not matter in your case at all. It has code only for AIX and PowerPC 64-bit Little Endian. It does not, however, handle `USE_MINIINTERPRETER` which is incorrect on AIX and 64-bit LE. I will post a patch for `StgCRunAsm.S` on Phab shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 16:55:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 16:55:11 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.39dcba97a36b8984bed9e52bfa0e25ca@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving-perf 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 nelhage): * cc: nelhage (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 17:27:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 17:27:06 -0000 Subject: [GHC] #13643: Core lint error with TypeInType and TypeFamilyDependencies In-Reply-To: <051.99866398c3b30eccc01358213362b7d9@haskell.org> References: <051.99866398c3b30eccc01358213362b7d9@haskell.org> Message-ID: <066.ecc7731a2794a44c6f02fe2aa88856be@haskell.org> #13643: Core lint error with TypeInType and TypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | InjectiveFamilies, 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 int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 18:04:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 18:04:29 -0000 Subject: [GHC] #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies Message-ID: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple InjectiveFamilies | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code triggers a warning about a redundant pattern match for `foo`: {{{ {-# LANGUAGE TypeFamilies, TypeFamilyDependencies #-} type family F r s = f | f -> r s type instance F (Bar h (Foo r)) (Bar h (Foo s)) = Bar h (Bar r s) data Bar s b data Foo a foo :: (F cr cu ~ Bar h (Bar r u), F cu cs ~ Bar (Foo h) (Bar u s)) => Bar h (Bar r u) -> Bar (Foo h) (Bar u s) -> Foo (cr -> cs) foo = undefined }}} {{{ warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘foo’: foo = .. }}} This warning seems invalid to me: I'm not sure how a single definition could constitute a redundant pattern match. Moreover, if I try to address the warning by removing the "redundant" pattern, the code (of course) fails to compile because there is no accompanying binding for the signature of `foo`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 18:11:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 18:11:36 -0000 Subject: [GHC] #12075: Fails to build on powerpcspe because of inline assembly In-Reply-To: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> References: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> Message-ID: <062.1492142e41314ea04ef8d029d1435d36@haskell.org> #12075: Fails to build on powerpcspe because of inline assembly ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Comment (by trommler): Replying to [comment:11 trommler]: > BTW `StgCRunAsm.S` should not matter in your case at all. It has code only for AIX and PowerPC 64-bit Little Endian. It does not, however, handle `USE_MINIINTERPRETER` which is incorrect on AIX and 64-bit LE. I will post a patch for `StgCRunAsm.S` on Phab shortly. The patch is Phab:D3540. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 18:14:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 18:14:37 -0000 Subject: [GHC] #12075: Fails to build on powerpcspe because of inline assembly In-Reply-To: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> References: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> Message-ID: <062.5429a519e8b9c271d59f3d801c5358c7@haskell.org> #12075: Fails to build on powerpcspe because of inline assembly ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Comment (by glaubitz): Replying to [comment:11 trommler]: > That's exactly the problem. The inline assembly is there and used even when "--enable-unregisterised" > BTW `StgCRunAsm.S` should not matter in your case at all. It has code only for AIX and PowerPC 64-bit Little Endian. It does not, however, handle `USE_MINIINTERPRETER` which is incorrect on AIX and 64-bit LE. I will post a patch for `StgCRunAsm.S` on Phab shortly. Hmm, you're right. I was pretty though I was building with --enable- unregisterised. I will recheck the issue and report back. But, please bear with me as building on the embedded system takes some time with an unregisterised build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 18:33:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 18:33:41 -0000 Subject: [GHC] #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies In-Reply-To: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> References: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> Message-ID: <062.55afe69c50edaa2b2b2dfda8347d3b56@haskell.org> #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This appears to be fixed in GHC 8.2.1, although I don't recall what commit fixed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 19:46:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 19:46:13 -0000 Subject: [GHC] #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies In-Reply-To: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> References: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> Message-ID: <062.e784928ef9b60b0af432717d125f69e3@haskell.org> #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 20:22:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 20:22:16 -0000 Subject: [GHC] #5546: Documentation errors in Control.Exception.Base In-Reply-To: <042.33225420f65051ba735e603b0f60e843@haskell.org> References: <042.33225420f65051ba735e603b0f60e843@haskell.org> Message-ID: <057.1c49aa6f831570ae6bc4750942798819@haskell.org> #5546: Documentation errors in Control.Exception.Base -------------------------------------+------------------------------------- Reporter: bit | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.4.1 Component: libraries/base | Version: 7.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bezirg): In the documentation of [https://hackage.haskell.org/package/base-4.9.1.0/docs/Control- Exception.html Control.Exception] of base 4.9.10 there is still a link to non-existing ''forkIOUnmasked'' function: > To create a a new thread in an unmasked state use forkIOUnmasked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 20:23:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 20:23:24 -0000 Subject: [GHC] #5546: Documentation errors in Control.Exception.Base In-Reply-To: <042.33225420f65051ba735e603b0f60e843@haskell.org> References: <042.33225420f65051ba735e603b0f60e843@haskell.org> Message-ID: <057.e40a355765a2d064d4110e20c31c1875@haskell.org> #5546: Documentation errors in Control.Exception.Base -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: high | 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: | -------------------------------------+------------------------------------- Changes (by bezirg): * owner: simonmar => (none) * status: closed => new * version: 7.2.1 => 8.0.1 * resolution: fixed => * milestone: 7.4.1 => ⊥ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 20:32:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 20:32:55 -0000 Subject: [GHC] #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies In-Reply-To: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> References: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> Message-ID: <062.2137575ae7aa7e4795c8041cde27a316@haskell.org> #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Terrific -- worth a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 20:34:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 20:34:47 -0000 Subject: [GHC] #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused-pattern-binds In-Reply-To: <044.32e35139f2ee897ece4f6184af2a605d@haskell.org> References: <044.32e35139f2ee897ece4f6184af2a605d@haskell.org> Message-ID: <059.87a4b7636c169cc567f3199058c95ba0@haskell.org> #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused- pattern-binds -------------------------------------+------------------------------------- Reporter: exphp | 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 dfeuer): No objection here. I think exphp's point about the assertion with a missing function is quite interesting in itself. Simon, do you think it would be possible to implement a warning when someone applies a bang pattern, `seq`, or `seq#` to something known to have a function type? That seems almost always the wrong thing. It's also bad to force something that will take a dictionary argument, but that seems potentially harder to detect conservatively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 20:59:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 20:59:51 -0000 Subject: [GHC] #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused-pattern-binds In-Reply-To: <044.32e35139f2ee897ece4f6184af2a605d@haskell.org> References: <044.32e35139f2ee897ece4f6184af2a605d@haskell.org> Message-ID: <059.113821696d757f93a759d9d70eabc467@haskell.org> #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused- pattern-binds -------------------------------------+------------------------------------- Reporter: exphp | 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 exphp): I am conflicted on dfeuer's suggestion, since functions too can be bottom: {{{#!hs bottomsUp :: a -> a bottomsUp = error "oops" ... let !_ = bottomsUp -- error: Lib: oops }}} So generating warnings on this would be a somewhat opinionated change. Yet at the same time, it is an opinion I perhaps agree with; such code is playing with fire! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 21:31:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 21:31:27 -0000 Subject: [GHC] #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies In-Reply-To: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> References: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> Message-ID: <062.61789c9cfce3869162fa444a52578e97@haskell.org> #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think it was this commit that changed this behaviour. https://phabricator.haskell.org/rGHCadb565aa74582969bbcc3b411d6d518b1c76c3cf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 22:02:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 22:02:23 -0000 Subject: [GHC] #13652: Add integer division to GHC.TypeLits Message-ID: <048.b9612e3f8a829526a91743f198cf1ed8@haskell.org> #13652: Add integer division to GHC.TypeLits -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC.TypeLits currently lacks integer division type families and I can't see why. What is the reason for not having these methods of the `Integral` class at type level: {{{#!hs quot rem div mod quotRem divMod }}} ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 23:29:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 23:29:54 -0000 Subject: [GHC] #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies In-Reply-To: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> References: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> Message-ID: <062.00438a42bf1aeb0fb81de45fc292aff1@haskell.org> #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): As it turns out, that's not the full story. The first commit in which the program in this ticket compiled without warnings was eb55ec2941239dee05afc6be818b129efe51660e (Refactor functional dependencies a bit). Commit adb565aa74582969bbcc3b411d6d518b1c76c3cf, on the other hand, did squash needless pattern-match warnings in some other, similar programs, such as this one: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug2 where foo :: Int ~ Bool => a -> a foo x = x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 5 23:35:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 May 2017 23:35:28 -0000 Subject: [GHC] #13590: Update Cabal submodule to whatever the final Cabal 2.0 release is In-Reply-To: <045.ce3771e6f817c088d0ef6be30bfa4c03@haskell.org> References: <045.ce3771e6f817c088d0ef6be30bfa4c03@haskell.org> Message-ID: <060.d3570dfead16f3fea95a496a945f0038@haskell.org> #13590: Update Cabal submodule to whatever the final Cabal 2.0 release is -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: libraries | Version: 8.2.1-rc2 (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 refold): `Cabal-v2.0.0.0` tag has been created. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 03:04:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 03:04:56 -0000 Subject: [GHC] #13653: Re-allocate byteArray lead internal error: evacuate: strange closure type 241 Message-ID: <045.b63b09d911d99fa3a9d58416434a0758@haskell.org> #13653: Re-allocate byteArray lead internal error: evacuate: strange closure type 241 -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Compile and run following code lead to {{{evacuate: strange closure type XXX}}} on GHC 7.10.3/8.0.2/head, which is unreasonable. But running in GHCi is fine. {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} import qualified Data.List as List import GHC.Prim import Data.Primitive.ByteArray import GHC.Types import GHC.ST data Bytes = Bytes {-# UNPACK #-} !ByteArray -- payload {-# UNPACK #-} !Int -- s {-# UNPACK #-} !Int -- length packN :: Int -> [Word8] -> Bytes packN n0 ws0 = runST (newByteArray n0 >>= go 0 n0 ws0) where go :: Int -> Int -> [Word8] -> MutableByteArray s -> ST s Bytes go !i !n [] !mba = do ba <- unsafeFreezeByteArray mba return (Bytes ba 0 i) go !i !n (w:ws) !mba | i <= n = do writeByteArray mba i w go (i+1) n ws mba | otherwise = do let n' = (n + 1) `shiftL` 1 -- mba' <- newByteArray n' -- these dosen't work either -- copyMutableByteArray mba' 0 mba 0 i mba' <- resizeMutableByteArray mba n' writeByteArray mba' i w go (i+1) n' ws mba' resizeMutableByteArray :: MutableByteArray s -> Int -> ST s (MutableByteArray s) resizeMutableByteArray (MutableByteArray mba#) (I# i#) = ST (\ s# -> let (# s'#, mba'# #) = resizeMutableByteArray# mba# i# s# in (# s'#, MutableByteArray mba'# #) ) main = print $ packN 64 (List.replicate 8192 128) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 03:08:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 03:08:53 -0000 Subject: [GHC] #13653: Re-allocate byteArray lead internal error: evacuate: strange closure type 241 In-Reply-To: <045.b63b09d911d99fa3a9d58416434a0758@haskell.org> References: <045.b63b09d911d99fa3a9d58416434a0758@haskell.org> Message-ID: <060.b0f27b17acfb33de37c7ffe81a2ad4c9@haskell.org> #13653: Re-allocate byteArray lead internal error: evacuate: strange closure type 241 -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 winter: @@ -15,0 +15,1 @@ + import Data.Word @@ -29,1 +30,1 @@ - | otherwise = do let n' = (n + 1) `shiftL` 1 + | otherwise = do let n' = n * 2 @@ -45,1 +46,1 @@ - main = print $ packN 64 (List.replicate 8192 128) + main = packN 64 (List.replicate 100000 128) `seq` return () New description: Compile and run following code lead to {{{evacuate: strange closure type XXX}}} on GHC 7.10.3/8.0.2/head, which is unreasonable. But running in GHCi is fine. {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} import qualified Data.List as List import GHC.Prim import Data.Primitive.ByteArray import GHC.Types import GHC.ST import Data.Word data Bytes = Bytes {-# UNPACK #-} !ByteArray -- payload {-# UNPACK #-} !Int -- s {-# UNPACK #-} !Int -- length packN :: Int -> [Word8] -> Bytes packN n0 ws0 = runST (newByteArray n0 >>= go 0 n0 ws0) where go :: Int -> Int -> [Word8] -> MutableByteArray s -> ST s Bytes go !i !n [] !mba = do ba <- unsafeFreezeByteArray mba return (Bytes ba 0 i) go !i !n (w:ws) !mba | i <= n = do writeByteArray mba i w go (i+1) n ws mba | otherwise = do let n' = n * 2 -- mba' <- newByteArray n' -- these dosen't work either -- copyMutableByteArray mba' 0 mba 0 i mba' <- resizeMutableByteArray mba n' writeByteArray mba' i w go (i+1) n' ws mba' resizeMutableByteArray :: MutableByteArray s -> Int -> ST s (MutableByteArray s) resizeMutableByteArray (MutableByteArray mba#) (I# i#) = ST (\ s# -> let (# s'#, mba'# #) = resizeMutableByteArray# mba# i# s# in (# s'#, MutableByteArray mba'# #) ) main = packN 64 (List.replicate 100000 128) `seq` return () }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 03:58:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 03:58:17 -0000 Subject: [GHC] #13653: Re-allocate byteArray lead internal error: evacuate: strange closure type 241 In-Reply-To: <045.b63b09d911d99fa3a9d58416434a0758@haskell.org> References: <045.b63b09d911d99fa3a9d58416434a0758@haskell.org> Message-ID: <060.5781dc214921afc199fc2ffbedb98696@haskell.org> #13653: Re-allocate byteArray lead internal error: evacuate: strange closure type 241 -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by winter): * status: new => closed * resolution: => invalid Comment: Sorry about the mis-report, the error is simple: in the loop `i <= n` should be `i < n` . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 08:40:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 08:40:38 -0000 Subject: [GHC] #12075: Fails to build on powerpcspe because of inline assembly In-Reply-To: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> References: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> Message-ID: <062.9dfd61061faabe6e6c4b19de938875e1@haskell.org> #12075: Fails to build on powerpcspe because of inline assembly ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Comment (by trommler): Replying to [comment:13 glaubitz]: > Hmm, you're right. I was pretty though I was building with --enable- unregisterised. I will recheck the issue and report back. But, please bear with me as building on the embedded system takes some time with an unregisterised build. Building on a 14 years old PowerMac G5 is also pretty slow :-) If you see a failure again could you compile `StgCRun.c` and `HeapStackCheck.cmm` with an additional `-v3` flag added to the command line so we can check ghc is passing the correct set of options to gcc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 10:54:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 10:54:39 -0000 Subject: [GHC] #13654: Optimize casMutVar# for single-threaded runtime Message-ID: <045.de130c37edb1393ac27afa1cebe7df28@haskell.org> #13654: Optimize casMutVar# for single-threaded runtime -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Runtime | Version: 8.2.1-rc1 System | 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: -------------------------------------+------------------------------------- When using the non-threaded RTS, `stg_casMutVarzh`, `stg_atomicModifyMutVarzh`, etc., shouldn't need to actually use atomic instructions, but they seem to do so. I believe this makes them substantially slower than necessary in that context. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 10:55:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 10:55:40 -0000 Subject: [GHC] #13654: Optimize casMutVar# for single-threaded runtime In-Reply-To: <045.de130c37edb1393ac27afa1cebe7df28@haskell.org> References: <045.de130c37edb1393ac27afa1cebe7df28@haskell.org> Message-ID: <060.dbafd5c921761937536b5cd65abec589@haskell.org> #13654: Optimize casMutVar# for single-threaded runtime -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: @@ -1,4 +1,4 @@ - When using the non-threaded RTS, `stg_casMutVarzh`, - `stg_atomicModifyMutVarzh`, etc., shouldn't need to actually use atomic - instructions, but they seem to do so. I believe this makes them - substantially slower than necessary in that context. + In the non-threaded RTS, `stg_casMutVarzh`, `stg_atomicModifyMutVarzh`, + etc., shouldn't need to actually use atomic instructions, but they seem to + do so. I believe this makes them substantially slower than necessary in + that context. New description: In the non-threaded RTS, `stg_casMutVarzh`, `stg_atomicModifyMutVarzh`, etc., shouldn't need to actually use atomic instructions, but they seem to do so. I believe this makes them substantially slower than necessary in that context. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 14:40:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 14:40:08 -0000 Subject: [GHC] #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope In-Reply-To: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> References: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> Message-ID: <065.419a8f35a62a36587b950a0f09c9a1c3@haskell.org> #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: mpickering Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3515 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Using `ghc-8.2.0.20170505` my problems are gone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 15:26:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 15:26:19 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.95f6fb3331ea315a75ba6ff5c6121bb1@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8731 #10858 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 15:40:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 15:40:52 -0000 Subject: [GHC] #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. In-Reply-To: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> References: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> Message-ID: <064.8ce923c83b51fcfd2601e41d7bea523f@haskell.org> #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | RebindableSyntax 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 nomeata): This is not really a bug, but rather how `do` notation is specified. If you look at https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-470003.14 you will see {{{ do {p <- e; stmts} = let ok p = do {stmts} ok _ = fail "..." in e >>= ok }}} One could argue that if the pattern is `_`, the second line should be omitted, but where to stop? What about `do () <- …`, an obviously complete pattern, should the `fail` line be omitted as well? But that information might only be available after type-checking, whereas this happens before… I don’t have an opinion of my own here, just pointing out that the current behaviour is as specified, and that a change is not as trivial as it looks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 15:44:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 15:44:57 -0000 Subject: [GHC] #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. In-Reply-To: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> References: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> Message-ID: <064.dd3a3bac760faa7efff8e5eee8e4a8fa@haskell.org> #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | RebindableSyntax 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 AaronFriel): Interesting, I thought that the lack of the constraint meant that GHC here was not following that spec. How does the `fail` get removed such that it doesn't entail a constraint? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 16:38:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 16:38:57 -0000 Subject: [GHC] #13640: Core lint error with deferred type holes In-Reply-To: <051.2c7223492c210d11878b7833204062aa@haskell.org> References: <051.2c7223492c210d11878b7833204062aa@haskell.org> Message-ID: <066.599a57280d2ccceef230285c612fd664@haskell.org> #13640: Core lint error with deferred type holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12947 | Differential Rev(s): Phab:D3528 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"38a381912f67c0f6f3fba8de1026d7464826b851/ghc" 38a38191/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="38a381912f67c0f6f3fba8de1026d7464826b851" Add regression tests for #12947, #13640 Summary: Commit b4bdbe4957ae8b82c4cda5584203b44d3c4f004f (the fix for #12156) wound up being the fix for #12947 and #13640 as well. This adds regression tests for the latter two tickets to keep them fixed. Test Plan: make test TEST="T12947 T13640" Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #12947, #13640 Differential Revision: https://phabricator.haskell.org/D3528 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 16:38:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 16:38:57 -0000 Subject: [GHC] #12947: Core lint error In-Reply-To: <051.c8f6f90ba6faede01ce48237dc8657bf@haskell.org> References: <051.c8f6f90ba6faede01ce48237dc8657bf@haskell.org> Message-ID: <066.342afc6231ce1de250bd6c5004332b6f@haskell.org> #12947: Core lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13640 | Differential Rev(s): Phab:D3528 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"38a381912f67c0f6f3fba8de1026d7464826b851/ghc" 38a38191/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="38a381912f67c0f6f3fba8de1026d7464826b851" Add regression tests for #12947, #13640 Summary: Commit b4bdbe4957ae8b82c4cda5584203b44d3c4f004f (the fix for #12156) wound up being the fix for #12947 and #13640 as well. This adds regression tests for the latter two tickets to keep them fixed. Test Plan: make test TEST="T12947 T13640" Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #12947, #13640 Differential Revision: https://phabricator.haskell.org/D3528 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 16:38:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 16:38:57 -0000 Subject: [GHC] #12156: -fdefer-typed-holes causes panic on unbound variable In-Reply-To: <043.3614ae54ff3ca0baba5007f775728ec4@haskell.org> References: <043.3614ae54ff3ca0baba5007f775728ec4@haskell.org> Message-ID: <058.3be9609c6e8f1478e4456b153ccd22d6@haskell.org> #12156: -fdefer-typed-holes causes panic on unbound variable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: partial- | sigs/should_compile/T12156 Blocked By: | Blocking: Related Tickets: #10569 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"38a381912f67c0f6f3fba8de1026d7464826b851/ghc" 38a38191/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="38a381912f67c0f6f3fba8de1026d7464826b851" Add regression tests for #12947, #13640 Summary: Commit b4bdbe4957ae8b82c4cda5584203b44d3c4f004f (the fix for #12156) wound up being the fix for #12947 and #13640 as well. This adds regression tests for the latter two tickets to keep them fixed. Test Plan: make test TEST="T12947 T13640" Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #12947, #13640 Differential Revision: https://phabricator.haskell.org/D3528 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 16:38:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 16:38:57 -0000 Subject: [GHC] #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies In-Reply-To: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> References: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> Message-ID: <062.bc9c63cac9b8500b2ac91ce8783cc5c8@haskell.org> #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | InjectiveFamilies 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 Ryan Scott ): In [changeset:"ed0c7f8b1f91651203db4a0ee5931d47e1e6ab51/ghc" ed0c7f8b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ed0c7f8b1f91651203db4a0ee5931d47e1e6ab51" Add regression test for #13651 Commit eb55ec2941239dee05afc6be818b129efe51660e ended up fixing #13651, so let's add a regression test for it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 16:40:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 16:40:56 -0000 Subject: [GHC] #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies In-Reply-To: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> References: <047.0d915c488efca3d4790ceedf0932a32b@haskell.org> Message-ID: <062.92c2b86b6682c03e79433dfd52755c24@haskell.org> #13651: Invalid redundant pattern matches with -XTypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | typecheck/should_compile/T13651 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => typecheck/should_compile/T13651 * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 16:42:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 16:42:37 -0000 Subject: [GHC] #13640: Core lint error with deferred type holes In-Reply-To: <051.2c7223492c210d11878b7833204062aa@haskell.org> References: <051.2c7223492c210d11878b7833204062aa@haskell.org> Message-ID: <066.b39afec531c008403416b657f5bbe3d4@haskell.org> #13640: Core lint error with deferred type holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13640 Blocked By: | Blocking: Related Tickets: #12947 | Differential Rev(s): Phab:D3528 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_fail/T13640 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 16:42:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 16:42:39 -0000 Subject: [GHC] #12947: Core lint error In-Reply-To: <051.c8f6f90ba6faede01ce48237dc8657bf@haskell.org> References: <051.c8f6f90ba6faede01ce48237dc8657bf@haskell.org> Message-ID: <066.fe6997fd1b5c0091326df2240dae275d@haskell.org> #12947: Core lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12947 Blocked By: | Blocking: Related Tickets: #13640 | Differential Rev(s): Phab:D3528 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_fail/T12947 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 16:44:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 16:44:05 -0000 Subject: [GHC] #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. In-Reply-To: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> References: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> Message-ID: <064.d61e7a05a1dae7ffdfd10778e64d0104@haskell.org> #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | RebindableSyntax 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 nomeata): That is indeed a good question. It seems that the type signature of `fail` is ignored completely. This might indicate that the renamer requires `fail` to be present, but that the type-checker does not see it. And `compiler/deSugar/DsExpr.hs` definitely does not emit a call to `fail` if the match can fail. In function `tcMonadFailOp` the `fail` part of a bind is only type-checked if the pattern can fail, using `isIrrefutableHsPat`. Potentially, the local function `getFailFunction` in {{{ rnStmt ctxt rnBody (L loc (BindStmt pat body _ _ _)) thing_inside }}} could do the same. Is that enough pointing-the-way for you to try to fix this? If you do, make a good note somewhere explaining the interplay of how the renamer, the type checker and the desugarer decide whether to assume a call to the `fail` function or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 17:12:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 17:12:57 -0000 Subject: [GHC] #13654: Optimize casMutVar# for single-threaded runtime In-Reply-To: <045.de130c37edb1393ac27afa1cebe7df28@haskell.org> References: <045.de130c37edb1393ac27afa1cebe7df28@haskell.org> Message-ID: <060.43a8702d4dcde2212d5092d4d12e577f@haskell.org> #13654: Optimize casMutVar# for single-threaded runtime -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: @@ -1,4 +1,3 @@ - In the non-threaded RTS, `stg_casMutVarzh`, `stg_atomicModifyMutVarzh`, - etc., shouldn't need to actually use atomic instructions, but they seem to - do so. I believe this makes them substantially slower than necessary in - that context. + In the non-threaded RTS, `stg_casMutVarzh`, etc., shouldn't need to + actually use atomic instructions, but they seem to do so. I believe this + makes them substantially slower than necessary in that context. New description: In the non-threaded RTS, `stg_casMutVarzh`, etc., shouldn't need to actually use atomic instructions, but they seem to do so. I believe this makes them substantially slower than necessary in that context. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 22:44:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 22:44:34 -0000 Subject: [GHC] #13655: Spurious untouchable type variable in connection with rank-2 type and constraint family Message-ID: <046.fa7a964aa5cdaeab62013eaa1b08a1df@haskell.org> #13655: Spurious untouchable type variable in connection with rank-2 type and constraint family -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code cannot be compiled: {{{#!hs {-# LANGUAGE ConstraintKinds, Rank2Types, TypeFamilies #-} import GHC.Exts (Constraint) type family F a b :: Constraint data T b c = T f :: (forall b . F a b => T b c) -> a f _ = undefined }}} GHC outputs the following error message: {{{ Untouchable.hs:9:6: error: • Couldn't match type ‘c0’ with ‘c’ ‘c0’ is untouchable inside the constraints: F a b bound by the type signature for: f :: F a b => T b c0 at Untouchable.hs:9:6-37 ‘c’ is a rigid type variable bound by the type signature for: f :: forall a c. (forall b. F a b => T b c) -> a at Untouchable.hs:9:6 Expected type: T b c0 Actual type: T b c • In the ambiguity check for ‘f’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: f :: (forall b. F a b => T b c) -> a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 22:45:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 22:45:38 -0000 Subject: [GHC] #13656: Consider implementing atomicModifyMutVar# in Haskell Message-ID: <045.a3a79a390ff5c3e65f265136aa8f8b7f@haskell.org> #13656: Consider implementing atomicModifyMutVar# in Haskell -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: low | Milestone: 8.4.1 Component: Runtime | Version: 8.2.1-rc2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I believe we could implement `atomicModifyMutVar#` in Haskell, rather than making it a primop. This seems like a simpler/cleaner approach (among other things, it gets a perfectly legitimate type signature!), but we'd have to see how it affects performance. I think something like this should work: {{{#!hs atomicModifyMutVar# :: MutVar# s a -> (a -> (a,b)) -> State# s -> (# State# s, b #) atomicModifyMutVar# mv f s = case readMutVar# mv s of { (# s', old #) -> let f_old = f old in case casMutVar# mv old (fst $ f_old) s of { (# s', unchanged, new #) -> case unchanged of 0# -> (# s', snd f_old #) _ -> atomicModifyMutVar# mv f s' }} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 22:57:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 22:57:26 -0000 Subject: [GHC] #13656: Consider implementing atomicModifyMutVar# in Haskell In-Reply-To: <045.a3a79a390ff5c3e65f265136aa8f8b7f@haskell.org> References: <045.a3a79a390ff5c3e65f265136aa8f8b7f@haskell.org> Message-ID: <060.e2a353746540429405a7ccba25a2b045@haskell.org> #13656: Consider implementing atomicModifyMutVar# in Haskell -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: low | Milestone: 8.4.1 Component: Runtime System | 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): * owner: (none) => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 23:11:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 23:11:03 -0000 Subject: [GHC] #12075: Fails to build on powerpcspe because of inline assembly In-Reply-To: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> References: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> Message-ID: <062.fc7cc228235f71fca48483b94eb9617f@haskell.org> #12075: Fails to build on powerpcspe because of inline assembly ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3540 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by bgamari): * status: infoneeded => patch * differential: => Phab:D3540 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 6 23:50:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 May 2017 23:50:23 -0000 Subject: [GHC] #10431: EqualityConstraints extension? In-Reply-To: <049.f083101907b8bce0e20c55864639c7df@haskell.org> References: <049.f083101907b8bce0e20c55864639c7df@haskell.org> Message-ID: <064.b15428c6b941d405ece75876d8189895@haskell.org> #10431: EqualityConstraints extension? -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): However this gets resolved, please doco which extensions enable the `(~)` syntax. Currently at 8.0.1: * Section 10.14.1 'Equality Constraints' tells how to use `(~)`, but not how to enable it. * Section 10.8.3.3 'Relaxed rules for instance contexts' mentions -XGADTs or -XTypeFamilies, as an aside.\\I'd call that a less than obvious place to look. It's not too bad: if you use `(~)` without either of those switched on, GHC's error message is very clear. (See this post https://mail.haskell.org/pipermail/glasgow-haskell- users/2017-April/026521.html.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 01:16:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 01:16:52 -0000 Subject: [GHC] #13656: Consider implementing atomicModifyMutVar# in Haskell In-Reply-To: <045.a3a79a390ff5c3e65f265136aa8f8b7f@haskell.org> References: <045.a3a79a390ff5c3e65f265136aa8f8b7f@haskell.org> Message-ID: <060.989e723190497b66e0ff58491d2a9a3d@haskell.org> #13656: Consider implementing atomicModifyMutVar# in Haskell -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: low | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1-rc2 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 dfeuer): * status: new => closed * resolution: => invalid Comment: fryguybob first explained that the implementation above will allocate like mad. I countered with {{{#!hs atomicModifyMutVar# :: s ~ RealWorld => MutVar# s a -> (a -> (a,b)) -> State# s -> (# State# s, b #) atomicModifyMutVar# mv f s = case readMutVar# mv s of { (# s', old #) -> case newMutVar# old s' of { (# s'', tempy #) -> let thunk = case runRW# $ \ss -> readMutVar# tempy ss of (# _, now #) -> f now in go# tempy mv (fst thunk) (snd thunk) s''}} go# :: s ~ RealWorld => MutVar# s a -> MutVar# s a -> a -> b -> State# s -> (# State# s, b #) go# tempy mv thunka thunkb s = case readMutVar# mv s of { (# s', old #) -> case writeMutVar# tempy old s of { s'' -> case casMutVar# mv old thunka s'' of { (# s''', unchanged, new #) -> case unchanged of 0# -> (# s''', thunkb #) _ -> go# tempy mv thunka thunkb s''' }}} }}} fryguybob then explained that the cmm implementation is able to avoid write barrier inefficiencies that we can't in Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 01:42:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 01:42:40 -0000 Subject: [GHC] #13390: Strict literal float-out during desugaring regresses T1969 at -O0 In-Reply-To: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> References: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> Message-ID: <061.09a792f118d5f200f8f7cee73cf951a9@haskell.org> #13390: Strict literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): [[Commentary/Compiler/Core2CorePipeline]] indicates that in desugaring we only inline "non-recursive bindings that are used only once or where the RHS is trivial". I don't see how to understand what Ben showed based on that. But if a little more inlining is happening for some reason, here's one potential story. Without floating, imagine that the (default-derived) method definitions are somehow inlined into the dictionary, and then `$dme` and `$dmd` are inlined. Then everything squashes down nicely. With floating, something else inexplicable seems to be happening: the default definitions inline into `$ce_a1ik` and `$cd_a1ib`, and somehow `$cc_a1i7` (which is now really small, but surprisingly non-trivial) inlines into them. Glancing at the notes and code for the gentle simplification, I do not understand why any of these inlinings are happening, but maybe someone else does. Or maybe I'm completely misinterpreting. I need to build both commits and dump inlinings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 02:01:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 02:01:08 -0000 Subject: [GHC] #13657: Documentation: Functional dependencies by other means Message-ID: <043.e6a2276b874588c5228bad3b9ffdb642@haskell.org> #13657: Documentation: Functional dependencies by other means -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: 10431 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There's an idiom that's briefly mentioned under Equality constraints [section 10.14.1], but is more general and more powerful. The trouble: is where to document it? Because you get the power from a combination of extensions: * -XMultiParamTypeClasses [10.8.1.1] * Superclass constraints, which can also be MultiParam [10.8.1.2] * -XFunctionalDependencies [10.8.2] * and/or superclass Equality constraints with Type families, having the effect of FunDeps [10.14.1] * The overall effect can satisfy the FunDep Coverage conditions, which means you might not need -XUndecidableInstances [10.8.3.5] 10.14.1 says: > Equality constraints can also appear in class and instance contexts. The former enable a simple translation of programs using functional dependencies into programs using family synonyms instead. That's not wrong; but by talking about "class and instance contexts" in the same breath does fail to emphasise that: * whereas Instance constraints don't apply until after the instance has been selected\\(And it's a common newbie mistake to think they restrict the selection.) * superclass constraints apply during type improvement __before__ selecting instances\\as described here http://stackoverflow.com/questions/35252562/find-an-element-in-an- hlist/35260970#35260970 "superclass context is critical ..." [thanks @DFeuer] * This behaviour means that even if you don't explicitly put a FunDep `| ... -> ...` on a class: * If you put a superclass equality constraint on a class, that induces a FunDep as explained in 10.14.1; but just as much * If you put a superclass __class__ constraint on a class, and that superclass has a FunDep, that also induces a FunDep. * and so on for a superclass constraint of a superclass constraint of a superclass constraint .... I suggest the bulk of the write-up goes under a new sub-section for FunDeps: ---- == 10.8.2.3 Functional dependency-like behaviour through superclass constraints Constraints in the class context can achieve the effect of Functional dependencies even without the explicit vertical bar and dependency arrow syntax in the class declaration. Either: * Using an Equality constraint to a Type family [10.14.1]; or * A superclass constraint that does have an explicit Functional dependency. * Or a superclass constraint which is itself constrained in one of those ways. A class declaration of the form {{{ class C a b | a -> b }}} can equivalently be given as {{{ class (F a ~ b) => C a b where type F a }}} That is, we represent every functional dependency (FD) `a1 .. an -> b` by an FD type family `F a1 .. an` and a superclass context equality `F a1 .. an ~ b`, essentially giving a name to the functional dependency. [See 10.14.1; using `(~)` needs -XTypeFamilies or -XGADTs.] In class instances, we define the type instances of FD families in accordance with the class head. Or class `C` can equivalently be given as {{{ class (D a b) => C a b ... class D a b | a -> b -- or class (G a ~ b) => D a b where type G a }}} The class instances for `D` will closely follow those for `C`. So there is not much gain in expressivity. Consider also: {{{ class (D a c) => E a b c ... -- class D as above }}} for which the `D` instances will be more compact than `E`. Note that `D` might not declare any methods, but merely be used for type improvement. Method signatures for class `C` are not affected by either of these ways for achieving dependencies. ---- Reference this thread: https://mail.haskell.org/pipermail/glasgow-haskell- users/2017-April/026515.html, with some fancier examples of pseudo- FunDeps. See also #10431. Is this power made clear in the theoretical literature? It's kinda implicit in the TypeFamilies2008 paper; but note that was written concurrently with Type Families development; and published before the work was completed. Specifically, supporting Type Families and `(~)` in superclass constraints was delivered a long time after the rest of the work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 02:12:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 02:12:59 -0000 Subject: [GHC] #13658: Assertion failure on HEAD: "optCoercion changed types!" Message-ID: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> #13658: Assertion failure on HEAD: "optCoercion changed types!" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.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: -------------------------------------+------------------------------------- I am seeing the following assertion failure on my `wip/libdw-prof` branch, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170507 for x86_64-unknown-linux): ASSERT failed! optCoercion changed types! in_co: (base:Data.Typeable.Internal.TypeRep{tc 35W} (UnsafeCo nominal ghc-prim:GHC.Types.Any{(w) tc 35K} (ghc- prim:GHC.Types.Any{(w) tc 35K} -> ghc- prim:GHC.Types.Any{(w) tc 35K})) (UnsafeCo nominal (ghc-prim:GHC.Types.Any{(w) tc 35K} ghc-prim:GHC.Types.Any{(w) tc 35K}) ghc- prim:GHC.Types.Any{(w) tc 35K}))_R in_ty1: base:Data.Typeable.Internal.TypeRep{tc 35W} (ghc-prim:GHC.Types.Any{(w) tc 35K} ghc-prim:GHC.Types.Any{(w) tc 35K}) in_ty2: base:Data.Typeable.Internal.TypeRep{tc 35W} ghc-prim:GHC.Types.Any{(w) tc 35K} out_co: (base:Data.Typeable.Internal.TypeRep{tc 35W} (UnsafeCo nominal ghc-prim:GHC.Types.Any{(w) tc 35K} (ghc- prim:GHC.Types.Any{(w) tc 35K} -> ghc- prim:GHC.Types.Any{(w) tc 35K})) _N)_R out_ty1: base:Data.Typeable.Internal.TypeRep{tc 35W} ghc-prim:GHC.Types.Any{(w) tc 35K} out_ty2: base:Data.Typeable.Internal.TypeRep{tc 35W} ghc-prim:GHC.Types.Any{(w) tc 35K} subst: [TCvSubst In scope: InScope {wild_00{v} base:Data.Typeable.Internal.mkTrCon{v 088} base:Data.Typeable.Internal.mkTrApp{v 089} base:Data.Typeable.Internal.typeNatTypeRep{v 08a} base:Data.Typeable.Internal.typeSymbolTypeRep{v 08b} base:Data.Typeable.Internal.mkTrFun{v 08d} wild_X3j{v} wild_X7E{v} wild_X83{v} wild_Xf1{v} dt_X2TF{v} a{v X2UX} kind_vars{v X2V3} kind_vars{v X32p} n{v a2Oo} a{v a2OX} b{v a2OY} tc{v a2Pw} args{v a2Px} tc{v a2PH} args{v a2PI} kind_args{v a2PK} ty_args{v a2PL} ty'{v a2PQ} dt_a2TG{v} dt_a2TH{v} k{tv a402} a{tv a403} k{tv a43q} k{tv a43r} k{tv a43s} a{tv a43t} $cshowsPrec{v a46O} $cshow{v a46Z} $cshowList{v a477} $cshowsPrec{v a47h} $cshow{v a47n} $cshowList{v a47t} $ccompare{v a47F} $c<{v a47X} $c<={v a485} $c>{v a48d} $c>={v a48l} $cmax{v a48t} $cmin{v a48B} $c=={v a48J} $c/={v a48Z} $ccompare{v a49d} $c<{v a49o} $c<={v a49u} $c>{v a49A} $c>={v a49G} $cmax{v a49M} $cmin{v a49S} $ctestEquality{v a4a1} $c=={v a4as} $c/={v a4aw} $krep_a4cI{v} $krep_a4cJ{v} $krep_a4cK{v} $krep_a4cL{v} $krep_a4cM{v} $krep_a4cN{v} $krep_a4cO{v} $krep_a4cP{v} $krep_a4cQ{v} $krep_a4cR{v} $krep_a4cS{v} $krep_a4cT{v} $krep_a4cU{v} $krep_a4cV{v} $krep_a4cW{v} $krep_a4cX{v} $krep_a4cY{v} $krep_a4cZ{v} $krep_a4d0{v} $krep_a4d1{v} $krep_a4d2{v} $krep_a4d3{v} $krep_a4d4{v} $krep_a4d5{v} $krep_a4d6{v} $krep_a4d7{v} $krep_a4d8{v} $krep_a4d9{v} $krep_a4da{v} $krep_a4db{v} $krep_a4dc{v} $krep_a4dd{v} $krep_a4de{v} $krep_a4df{v} $krep_a4dg{v} $krep_a4dh{v} $krep_a4di{v} $krep_a4dj{v} $krep_a4dk{v} $krep_a4dl{v} $krep_a4dm{v} $krep_a4dn{v} $krep_a4do{v} $krep_a4dp{v} $krep_a4dq{v} $krep_a4dr{v} $krep_a4ds{v} go{v a54a} wild{v a54c} y{v a54g} ys{v a54h} ds_d4tk{v} ds_d4tl{v} ds_d4tm{v} ds_d4tn{v} ds_d4to{v} ds_d4tS{v} ds_d4vc{v} dt_d52H{v} dt_d52I{v} base:Data.Typeable.Internal.modulePackage{v r2LC} base:Data.Typeable.Internal.moduleName{v r2LD} base:Data.Typeable.Internal.tyConPackage{v r2LE} base:Data.Typeable.Internal.tyConModule{v r2LF} base:Data.Typeable.Internal.tyConName{v r2LG} base:Data.Typeable.Internal.trNameString{v r2LH} base:Data.Typeable.Internal.tyConFingerprint{v r2LI} base:Data.Typeable.Internal.tyConKindArgs{v r2LJ} base:Data.Typeable.Internal.tyConKindRep{v r2LK} base:Data.Typeable.Internal.rnfModule{v r2LL} base:Data.Typeable.Internal.rnfTrName{v r2LM} base:Data.Typeable.Internal.rnfKindRep{v r2LN} base:Data.Typeable.Internal.rnfList{v r2LP} base:Data.Typeable.Internal.rnfTyCon{v r2LR} base:Data.Typeable.Internal.typeRepFingerprint{v r2LT} base:Data.Typeable.Internal.withTypeable{v r2LU} base:Data.Typeable.Internal.someTypeRepTyCon{v r2LV} base:Data.Typeable.Internal.typeRepTyCon{v r2LW} base:Data.Typeable.Internal.eqTypeRep{v r2LX} base:Data.Typeable.Internal.typeRepKind{v r2LY} base:Data.Typeable.Internal.runtimeRepTypeRep{v r2M6} base:Data.Typeable.Internal.typeRep{v r2M9} base:Data.Typeable.Internal.typeOf{v r2Ma} base:Data.Typeable.Internal.someTypeRep{v r2Mb} base:Data.Typeable.Internal.someTypeRepFingerprint{v r2Mc} base:Data.Typeable.Internal.splitApps{v r2Me} base:Data.Typeable.Internal.funTyCon{v r2Mf} base:Data.Typeable.Internal.rnfTypeRep{v r2Mj} base:Data.Typeable.Internal.rnfSomeTypeRep{v r2Mk} base:Data.Typeable.Internal.mkTyCon#{v r2Mm} base:Data.Typeable.Internal.mkTyCon{v r2Mn} base:Data.Typeable.Internal.mkTyConFingerprint{v r2Mo} base:Data.Typeable.Internal.mkTypeLitFromString{v r2Mq} base:Data.Typeable.Internal.tcSymbol{v r2Mr} base:Data.Typeable.Internal.tcNat{v r2Ms} base:Data.Typeable.Internal.$tc'SomeTypeRep{v r2RW} base:Data.Typeable.Internal.$tcSomeTypeRep{v r2Sy} base:Data.Typeable.Internal.$tc'TrTyCon{v r2SA} base:Data.Typeable.Internal.$tc'TrApp{v r2SO} base:Data.Typeable.Internal.$tc'TrFun{v r2T2} base:Data.Typeable.Internal.$tcTypeRep{v r2Tg} base:Data.Typeable.Internal.$fShowSomeTypeRep{v r2Ug} base:Data.Typeable.Internal.$fShowTypeRep{v r2Ul} base:Data.Typeable.Internal.$fOrdSomeTypeRep{v r2UJ} base:Data.Typeable.Internal.$fEqSomeTypeRep{v r2US} base:Data.Typeable.Internal.$fOrdTypeRep{v r2UX} base:Data.Typeable.Internal.$fTestEqualitykTypeRep{v r2Vf} base:Data.Typeable.Internal.$fEqTypeRep{v r2Vp} base:Data.Typeable.Internal.$tc'SomeKindedTypeRep{v r2VB} base:Data.Typeable.Internal.$tcSomeKindedTypeRep{v r2VW} base:Data.Typeable.Internal.$tcTypeable{v r2Wg} base:Data.Typeable.Internal.$tc'C:Typeable{v r2Wh} base:Data.Typeable.Internal.$tc'Gift{v r2Wm} base:Data.Typeable.Internal.$tcGift{v r2WP} base:Data.Typeable.Internal.$mKindRepTypeLit{v r3DI} base:Data.Typeable.Internal.$bKindRepTypeLit{v r3IP} base:Data.Typeable.Internal.$mCon'{v r3LL} base:Data.Typeable.Internal.$mCon{v r3Ns} base:Data.Typeable.Internal.$mApp{v r3NA} base:Data.Typeable.Internal.$bApp{v r3Oi} base:Data.Typeable.Internal.$mFun{v r3Om} base:Data.Typeable.Internal.$bFun{v r3Sq} base:Data.Typeable.Internal.$trModule{v r43m} rnfString_s573{v} typeOf_s5bk{v} $trModule_s5bF{v} $trModule_s5bH{v} $krep_s5bP{v} $krep_s5bQ{v} $tcTypeRep_s5bR{v} $tcTypeRep_s5bS{v} $krep_s5bT{v} $krep_s5bU{v} $krep_s5bV{v} $krep_s5bW{v} $krep_s5bX{v} $krep_s5bY{v} $krep_s5bZ{v} $krep_s5c0{v} $tc'TrApp_s5c1{v} $tc'TrApp_s5c2{v} $krep_s5c3{v} $krep_s5c4{v} $krep_s5c5{v} $krep_s5c6{v} $krep_s5c7{v} $krep_s5c8{v} $tc'TrFun_s5c9{v} $tc'TrFun_s5ca{v} $tcSomeTypeRep_s5cb{v} $tcSomeTypeRep_s5cc{v} $tc'SomeTypeRep_s5cd{v} $tc'SomeTypeRep_s5ce{v} $krep_s5cg{v} $tc'TrTyCon_s5ch{v} $tc'TrTyCon_s5ci{v} $tcSomeKindedTypeRep_s5cj{v} $tcSomeKindedTypeRep_s5ck{v} $krep_s5cl{v} $tc'SomeKindedTypeRep_s5cm{v} $tc'SomeKindedTypeRep_s5cn{v} $tcTypeable_s5co{v} $tcTypeable_s5cp{v} $tc'C:Typeable_s5cs{v} $tc'C:Typeable_s5ct{v} $tcGift_s5cu{v} $tcGift_s5cv{v} $krep_s5cw{v} $krep_s5cx{v} $krep_s5cy{v} $tc'Gift_s5cz{v} $tc'Gift_s5cA{v} $dTypeable_s5cC{v} $dTypeable_s5cE{v} $dTypeable_s5cG{v} $dTypeable_s5cI{v} $dTypeable_s5cK{v} $dTypeable_s5cM{v} $dTypeable_s5cO{v} $dTypeable_s5cQ{v} $dTypeable_s5cS{v} $dTypeable_s5cU{v} $dTypeable_s5cW{v} $dTypeable_s5cY{v} $dTypeable_s5d0{v} $dTypeable_s5d1{v} $dTypeable_s5gz{v} $dTypeable_s5gB{v} $dTypeable_s5gD{v} $dTypeable_s5gF{v} $dTypeable_s5gH{v} $dTypeable_s5gJ{v} $dTypeable_s5gL{v} $dTypeable_s5gN{v} $dTypeable_s5gP{v} $dTypeable_s5gR{v} $dTypeable_s5gT{v} $dTypeable_s5gV{v} $dTypeable_s5gX{v} $dTypeable_s5gZ{v} $dTypeable_s5h1{v} $dTypeable_s5h3{v} go{v s5pU} vars{v s5pY} lvl_s5rC{v} lvl_s5rD{v} lvl_s5rG{v} lvl_s5rJ{v} lvl_s5rM{v} lvl_s5rP{v} lvl_s5rR{v} lvl_s5rS{v} lvl_s5rT{v} lvl_s5rU{v} lvl_s5rV{v} lvl_s5rY{v} $dTypeable_s5s2{v} lvl_s5s3{v} lvl_s5s6{v} lvl_s5s7{v} lvl_s5sa{v} lvl_s5sb{v} lvl_s5sv{v} f_s5sz{v} lvl_s5sC{v} lvl_s5sH{v} f_s5sL{v} lvl_s5sM{v} lvl_s5sN{v} g_s5sP{v} lvl_s5sQ{v} f_s5sS{v} g_s5sU{v} lvl_s5sV{v} lvl_s5sW{v} lvl_s5sZ{v} lvl_s5t9{v} modl{v s5tj} lvl_s5tk{v} lvl_s5tl{v} lvl_s5tm{v} lvl_s5tv{v} lvl_s5tw{v} lvl_s5tx{v} lvl_s5tR{v} lvl_s5tS{v} lvl_s5tT{v} lvl_s5u6{v} lvl_s5un{v} lvl_s5uo{v} lvl_s5up{v} lvl_s5uq{v} lvl_s5ur{v} lvl_s5us{v} lvl_s5ut{v} lvl_s5uu{v} lvl_s5uv{v} $dTypeable_s5uK{v} lvl_s5uU{v} lvl_s5v8{v} lvl_s5v9{v} lvl_s5va{v} lvl_s5vb{v} lvl_s5vc{v} lvl_s5vg{v} lvl_s5wZ{v} kind_vars_s5x2{v} lvl_s5xf{v} $j_s5Da{v} lvl_s5Mo{v} lvl_s5Mp{v} lvl_s5Mq{v} lvl_s5Mr{v} lvl_s5Ms{v} kind_vars_s5MF{v} kind_vars_s5MG{v} lvl_s5MI{v} modl_s5Nw{v} lvl_s5OE{v} $wrnfModule{v s6s3} $wrnfTyCon{v s6sj} $wgo{v s6tn} $wtypeSymbolTypeRep{v s6uf} lvl_s6Qv{v} lvl_s6Qw{v} lvl_s6Qx{v} lvl_s6Qy{v} lvl_s6Qz{v} lvl_s6QA{v} lvl_s6QB{v} lvl_s6QC{v} lvl_s6QD{v} lvl_s6QF{v} lvl_s6QG{v} lvl_s6QI{v} lvl_s6QJ{v} lvl_s6QK{v} lvl_s6QL{v} lvl_s6QM{v} lvl_s6QN{v} lvl_s6QO{v} lvl_s6QP{v} lvl_s6QQ{v} lvl_s6QR{v} lvl_s6QS{v} lvl_s6QT{v} lvl_s6QU{v} lvl_s6QV{v} lvl_s6QW{v} lvl_s6QY{v} lvl_s6QZ{v} lvl_s6R0{v} lvl_s6R1{v} lvl_s6R2{v} lvl_s6Rb{v} lvl_s6Rd{v} lvl_s6Re{v} lvl_s6Rf{v} lvl_s6Rg{v} lvl_s6Rh{v} lvl_s6Ri{v} lvl_s6Rj{v} lvl_s6Rk{v} lvl_s6Rl{v} lvl_s6Rm{v} lvl_s6Rn{v} lvl_s6Ro{v} lvl_s6Rp{v} lvl_s6Rq{v} lvl_s6Rr{v} lvl_s6Rs{v} lvl_s6Rt{v} lvl_s6Ru{v} lvl_s6Rv{v} lvl_s6Rw{v} lvl_s6Rx{v} lvl_s6Ry{v} lvl_s6Rz{v} lvl_s6RA{v} lvl_s6RC{v} lvl_s6RD{v} lvl_s6RE{v} lvl_s6RG{v} lvl_s6RL{v} lvl_s6RM{v} lvl_s6RN{v} lvl_s6RO{v} lvl_s6RP{v} lvl_s6RQ{v} lvl_s6RR{v} lvl_s6RS{v} lvl_s6RT{v} lvl_s6RU{v} lvl_s6RV{v} lvl_s6RW{v} lvl_s6RX{v} lvl_s6RY{v} lvl_s6RZ{v} lvl_s6S0{v} lvl_s6S1{v} lvl_s6S2{v} lvl_s6S3{v} lvl_s6S4{v} lvl_s6S5{v} lvl_s6S6{v} lvl_s6S7{v} lvl_s6S8{v} lvl_s6S9{v} lvl_s6Sa{v} lvl_s6Sb{v} lvl_s6Sc{v} lvl_s6Sd{v} lvl_s6Se{v} lvl_s6Sf{v} lvl_s6Sg{v} lvl_s6Sh{v} lvl_s6Si{v} lvl_s6Sj{v} lvl_s6Sl{v} lvl_s6Sm{v} lvl_s6So{v} lvl_s6Sp{v} lvl_s6Sr{v} lvl_s6Ss{v} lvl_s6Su{v} lvl_s6Sv{v} lvl_s6Sx{v} lvl_s6Sy{v} lvl_s6SA{v} lvl_s6SB{v} lvl_s6SD{v} lvl_s6SE{v} lvl_s6SG{v} lvl_s6SH{v} lvl_s6SJ{v} lvl_s6SK{v} go{v s6SM} go{v s6SO} lvl_s6SR{v} wild_s6ST{v} ds_s6SU{v} ds_s6SV{v} ds_s6SW{v} ds_s6SX{v} nKindVars#{v s6SY} kindRep{v s6SZ} lvl_s6T8{v} lvl_s6Ta{v} $sgo{v s7lX} sc_s7lY{v} sc_s7lZ{v} sc_s7m0{v} sc_s7m1{v} sc_s7m3{v} sc_s7m5{v} $sgo{v s7m6} $s$wgo{v s7sR} $s$wgo{v s7sV} $stypeRepTyCon{v s7th} $stypeRepTyCon{v s7ti} $stypeRepTyCon{v s7tj} $srnfList{v s7tW}} Type env: [a403 :-> (a{tv a403} [tv] :: (k{tv a402} [tv] :: *)), a43r :-> (k1{tv a43r} [tv] :: (k{tv a43q} [tv] :: *)), a43t :-> (a{tv a43t} [tv] :: (k{tv a43s} [tv] :: *))] Co env: []] }}} This is with the following `build.mk`, {{{#!makefile BuildFlavour = dwarf ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif GhcStage2HcOpts += -eventlog STRIP_CMD = : }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 02:26:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 02:26:46 -0000 Subject: [GHC] #13390: Strict literal float-out during desugaring regresses T1969 at -O0 In-Reply-To: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> References: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> Message-ID: <061.b6996571854f3ec4c1028bd3ac53e93f@haskell.org> #13390: Strict literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Oh, I got mixed up. There ''is'' inlining in the "Non-opt simplification". So I'm pretty confident the inliner is the main player here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 02:36:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 02:36:37 -0000 Subject: [GHC] #13659: Bug report: "AThing evaluated unexpectedly tcTyVar a_alF" Message-ID: <049.d62cb96a1aca162d6e090009156f882b@haskell.org> #13659: Bug report: "AThing evaluated unexpectedly tcTyVar a_alF" -------------------------------------+------------------------------------- Reporter: costaparas | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code: {{{#!hs {-# LANGUAGE GADTs, EmptyDataDecls, TypeFamilies, TypeOperators, DataKinds, FlexibleInstances #-} {- Defines a C-like printf function using DataKinds extensions. -} module Printf where -- format string parameterized by a list of types data Format (fmt :: [*]) where X :: Format '[] -- empty string, i.e. "" L :: a -> String -> Format '[] -- string literal, e.g. "hello" S :: a -> Format '[String] -- "%s" I :: Format a -> Format '[Int, a] -- "%d" }}} produces the following error: GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Printf ( Printf.hs, interpreted ) a.hs:12:27:ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): AThing evaluated unexpectedly tcTyVar a_alF Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug when run using **ghci Printf.hs** on Liunx Ubuntu 16.04 LTS 64-bit with Intel® Core™ i7-7500U CPU @ 2.70GHz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 02:40:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 02:40:03 -0000 Subject: [GHC] #13659: Bug report: "AThing evaluated unexpectedly tcTyVar a_alF" In-Reply-To: <049.d62cb96a1aca162d6e090009156f882b@haskell.org> References: <049.d62cb96a1aca162d6e090009156f882b@haskell.org> Message-ID: <064.0ff20b16c9da2a895610afb936e988d9@haskell.org> #13659: Bug report: "AThing evaluated unexpectedly tcTyVar a_alF" -------------------------------------+------------------------------------- Reporter: costaparas | Owner: (none) Type: bug | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by costaparas: @@ -24,1 +24,1 @@ - a.hs:12:27:ghc: panic! (the 'impossible' happened) + Printf.hs:12:27:ghc: panic! (the 'impossible' happened) New description: The following code: {{{#!hs {-# LANGUAGE GADTs, EmptyDataDecls, TypeFamilies, TypeOperators, DataKinds, FlexibleInstances #-} {- Defines a C-like printf function using DataKinds extensions. -} module Printf where -- format string parameterized by a list of types data Format (fmt :: [*]) where X :: Format '[] -- empty string, i.e. "" L :: a -> String -> Format '[] -- string literal, e.g. "hello" S :: a -> Format '[String] -- "%s" I :: Format a -> Format '[Int, a] -- "%d" }}} produces the following error: GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Printf ( Printf.hs, interpreted ) Printf.hs:12:27:ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): AThing evaluated unexpectedly tcTyVar a_alF Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug when run using **ghci Printf.hs** on Liunx Ubuntu 16.04 LTS 64-bit with Intel® Core™ i7-7500U CPU @ 2.70GHz -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 02:52:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 02:52:56 -0000 Subject: [GHC] #13390: Strict literal float-out during desugaring regresses T1969 at -O0 In-Reply-To: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> References: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> Message-ID: <061.2b9b60e91593b6d36cf894035ca7cca3@haskell.org> #13390: Strict literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): OK, so I guess the reason for this is pretty clear: with floating, `$cc_a1i7` looks small enough to inline (even at `-O0`), and it inlines, and so we then lose the "phantom CSE" that we got from inlining the defaults instead. It's not clear to me that there's much we could do that would obviously improve matters in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 03:06:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 03:06:28 -0000 Subject: [GHC] #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function In-Reply-To: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> References: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> Message-ID: <061.b1855dbf40ca81c6647ce391e9350edd@haskell.org> #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13014 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) Comment: This doesn't ''sound'' very complicated, but I can't seem to find the code where it's handled. Anyone have a hint? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 03:07:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 03:07:10 -0000 Subject: [GHC] #13390: Strict literal float-out during desugaring regresses T1969 at -O0 In-Reply-To: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> References: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> Message-ID: <061.dac723850c36f67be28ab2e1a6ec172f@haskell.org> #13390: Strict literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | 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 Sun May 7 10:25:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 10:25:10 -0000 Subject: [GHC] #13658: Assertion failure on HEAD: "optCoercion changed types!" In-Reply-To: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> References: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> Message-ID: <061.a686486f3716d14f886f8975bbb7942a@haskell.org> #13658: Assertion failure on HEAD: "optCoercion changed types!" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): I've added a bit of debug into ASSERT. The complain is about type mismatch between in_ty1, out_ty1: {{{ in_ty1: base:Data.Typeable.Internal.TypeRep{tc 35W} (ghc-prim:GHC.Types.Any{(w) tc 35K} ghc-prim:GHC.Types.Any{(w) tc 35K}) out_ty1: base:Data.Typeable.Internal.TypeRep{tc 35W} ghc-prim:GHC.Types.Any{(w) tc 35K} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 12:00:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 12:00:27 -0000 Subject: [GHC] #13658: Assertion failure on HEAD: "optCoercion changed types!" In-Reply-To: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> References: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> Message-ID: <061.9f13e84e16984c4a5466fb6f2d1eb404@haskell.org> #13658: Assertion failure on HEAD: "optCoercion changed types!" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): The same error is also reproducible on a ghc-HEAD with this tiny '''mk/build.mk''': {{{ SRC_HC_OPTS += -g -dcore-lint -DDEBUG }}} I'll try to extract something smaller. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 13:59:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 13:59:04 -0000 Subject: [GHC] #13660: Tail after and including `NUL` character in `FilePath`s silently truncated Message-ID: <042.1a56f9b6f2bed8ae15859e412c16d6dd@haskell.org> #13660: Tail after and including `NUL` character in `FilePath`s silently truncated -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.2 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: -------------------------------------+------------------------------------- The current behaviour is imho not ideal as it masks invalid input arguments; consider e.g. {{{#!hs Prelude> readFile "foo" *** Exception: foo: openFile: does not exist (No such file or directory) Prelude> readFile "foo\NULbar" *** Exception: foobar: openFile: does not exist (No such file or directory) Prelude> writeFile "foo\NULbar" "contents" Prelude> readFile "foo\NULbar" "contents" Prelude> readFile "foo" "contents" }}} The reason for the surprising behaviour above is most likely (I haven't yet looked at the code), that `"foo\NULbar"` gets converted into a zero- terminated `CString` which is then passed to C functions such as `fopen(3)`, but to those C function, the C strings `"foo\0bar"` and `"foo"` are equivalent, as both are interpreted as `"foo"`. What I'd expect to happen on POSIX systems is that operations taking a `FilePath` such as `writeFile` or `readFile` should throw an exception when the `FilePath` gets encoded in such a way into a zero-terminated CString in such a way that a zero octet occurs (except for the intended zero-termination zero octet at the end). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 15:27:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 15:27:23 -0000 Subject: [GHC] #13590: Update Cabal submodule to whatever the final Cabal 2.0 release is In-Reply-To: <045.ce3771e6f817c088d0ef6be30bfa4c03@haskell.org> References: <045.ce3771e6f817c088d0ef6be30bfa4c03@haskell.org> Message-ID: <060.ca01adb2ef2442bb095329c5599d053f@haskell.org> #13590: Update Cabal submodule to whatever the final Cabal 2.0 release is -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: libraries | Version: 8.2.1-rc2 (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: new => closed * resolution: => fixed Comment: Bumped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 16:19:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 16:19:09 -0000 Subject: [GHC] #13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns. In-Reply-To: <049.3862587f91a2eaa8b116ce19f5a50e51@haskell.org> References: <049.3862587f91a2eaa8b116ce19f5a50e51@haskell.org> Message-ID: <064.ce7b80f9e5bb6f358edf4b7e596e68b6@haskell.org> #13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): As you point out, the relevant bit of code is in `RnExpr`. In particular, I believe that `stmtTreeToStmts` is relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 16:29:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 16:29:26 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.ddc3ef0f48a3e504ee5edb2768c298a5@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Rev(s): Phab:D1278 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"baa18def0da17f11497fecc6fe440cf125b50878/ghc" baa18de/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="baa18def0da17f11497fecc6fe440cf125b50878" testsuite: add new test for desugar warnings/errors with -fno-code Add a new (expect_broken) test T10600 that checks that the error: Top-level bindings for unlifted types aren't allowed: is thrown when compiling with -fno-code. This test currently fails because modules compiled with -fno-code aren't desugared. There are several other errors which can be thrown during desugaring that aren't tested for, discoverable by grepping for "errDs". Update .stderr files T8101 and T8101b. Presumably the compilation output has changed slightly since they were written. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #10600, #8101 Differential Revision: https://phabricator.haskell.org/D3533 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 16:29:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 16:29:26 -0000 Subject: [GHC] #4858: Add Control.Concurrent.forkIOWithUnmask, deprecate forkIOUnmasked In-Reply-To: <047.fe6b15a27cdda6a079f41c50712995a3@haskell.org> References: <047.fe6b15a27cdda6a079f41c50712995a3@haskell.org> Message-ID: <062.362273c816234c52e7a8cff0498767a7@haskell.org> #4858: Add Control.Concurrent.forkIOWithUnmask, deprecate forkIOUnmasked -------------------------------------+--------------------------------- Reporter: simonmar | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 7.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: -------------------------------------+--------------------------------- Comment (by Ben Gamari ): In [changeset:"1840121078718fb2a2fe5a7895501100517f627c/ghc" 1840121/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1840121078718fb2a2fe5a7895501100517f627c" base: Fix documentation for forkIOWithUnmask forkIOUnmasked has been deprecated for several years now. Update reference to it. See #4858 and #5546. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 16:29:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 16:29:26 -0000 Subject: [GHC] #8101: No pattern match non-exhaustiveness warnings when compiling with -fno-code In-Reply-To: <044.dfa43534fecae23d8d03f05e2e6d901b@haskell.org> References: <044.dfa43534fecae23d8d03f05e2e6d901b@haskell.org> Message-ID: <059.13af15658d5dd093cc25cf5d73d54ae6@haskell.org> #8101: No pattern match non-exhaustiveness warnings when compiling with -fno-code -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: T8101 Blocked By: | Blocking: Related Tickets: #10600 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"baa18def0da17f11497fecc6fe440cf125b50878/ghc" baa18de/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="baa18def0da17f11497fecc6fe440cf125b50878" testsuite: add new test for desugar warnings/errors with -fno-code Add a new (expect_broken) test T10600 that checks that the error: Top-level bindings for unlifted types aren't allowed: is thrown when compiling with -fno-code. This test currently fails because modules compiled with -fno-code aren't desugared. There are several other errors which can be thrown during desugaring that aren't tested for, discoverable by grepping for "errDs". Update .stderr files T8101 and T8101b. Presumably the compilation output has changed slightly since they were written. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #10600, #8101 Differential Revision: https://phabricator.haskell.org/D3533 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 16:29:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 16:29:26 -0000 Subject: [GHC] #5546: Documentation errors in Control.Exception.Base In-Reply-To: <042.33225420f65051ba735e603b0f60e843@haskell.org> References: <042.33225420f65051ba735e603b0f60e843@haskell.org> Message-ID: <057.a545c04296a6dce6fbfab377717b9501@haskell.org> #5546: Documentation errors in Control.Exception.Base -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: high | 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 Ben Gamari ): In [changeset:"1840121078718fb2a2fe5a7895501100517f627c/ghc" 1840121/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1840121078718fb2a2fe5a7895501100517f627c" base: Fix documentation for forkIOWithUnmask forkIOUnmasked has been deprecated for several years now. Update reference to it. See #4858 and #5546. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 16:30:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 16:30:43 -0000 Subject: [GHC] #5546: Documentation errors in Control.Exception.Base In-Reply-To: <042.33225420f65051ba735e603b0f60e843@haskell.org> References: <042.33225420f65051ba735e603b0f60e843@haskell.org> Message-ID: <057.670dd0f28b6efce9e96c863a2bab2249@haskell.org> #5546: Documentation errors in Control.Exception.Base -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: ⊥ => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 16:46:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 16:46:05 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.16f44be539e6daee3d6b10e44108fecb@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Rev(s): Phab:D1278 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > * Top-level bindings for unlifted types aren't allowed: > * Top-level strict pattern bindings aren't allowed: While these were never really "allowed", Richard Eisenberg did tighten the checks to ensure that they are caught between 8.0 and 8.2. > Let's always desugar with -fno-code, except for Ghc.Prim? Sounds like a reasonable first approximation to me. Let me know if you get stuck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 17:25:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 17:25:20 -0000 Subject: [GHC] #13658: Assertion failure on HEAD: "optCoercion changed types!" In-Reply-To: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> References: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> Message-ID: <061.10b2a969969e9ae52213f027dd32c5e2@haskell.org> #13658: Assertion failure on HEAD: "optCoercion changed types!" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): This should be self-contained example. You'll need a debugging compiler to build it. I'm not sure I've preserved kind structure of original module as core-lint detects all sorts of problems in this program. But the error is still the same. I was not able to remove foldl/foldr: the error goes away. {{{#!hs -- Bug.hs: {-# LANGUAGE TypeInType #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE RankNTypes #-} {- # OPTIONS_GHC -Werror #-} {-# OPTIONS_GHC -g -O2 #-} module Bug (bug) where import Unsafe.Coerce (unsafeCoerce) undefined :: a undefined = undefined prelude_id :: a -> a prelude_id x = x prelude_foldl :: forall a b. (b -> a -> b) -> b -> [a] -> b prelude_foldl k z0 xs = prelude_foldr (\v fn -> (\z -> fn (k z v))) prelude_id xs z0 prelude_foldr :: (a -> b -> b) -> b -> [a] -> b prelude_foldr f z = go where go [] = z go (y:ys) = y `f` go ys data TypeRep (a :: k) where TrTyCon :: TypeRep (a :: k) TrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). TypeRep (a b) data SomeTypeRep where SomeTypeRep :: forall k (a :: k). TypeRep a -> SomeTypeRep mkTrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). TypeRep (a :: k1 -> k2) -> TypeRep (a b) mkTrApp TrTyCon = undefined mkTrApp TrApp = undefined bug :: [a] -> SomeTypeRep bug args = prelude_foldl applyTy tycon_app args where tycon_app = SomeTypeRep TrTyCon applyTy :: SomeTypeRep -> a -> SomeTypeRep applyTy (SomeTypeRep acc) _unused = SomeTypeRep (mkTrApp (unsafeCoerce acc)) }}} {{{ $ ../"inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -g -dcore-lint -DDEBUG -Wall -this-unit-id base-4.10.0.0 -hide- all-packages -i.. -i../libraries/base/. -i../libraries/base/dist- install/build -I../libraries/base/dist-install/build -i../libraries/base /dist-install/build/./autogen -I../libraries/base/dist- install/build/./autogen -Ilibraries/base/include -optP- DOPTIMISE_INTEGER_GCD_LCM -optP-include -optP../libraries/base/dist- install/build/./autogen/cabal_macros.h -package-id rts -package-id ghc- prim-0.5.0.0 -package-id integer-gmp-1.0.0.1 -this-unit-id base -XHaskell2010 -O2 -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -split-sections -dynamic-too -c Bug.hs -fforce-recomp ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170506 for x86_64-unknown-linux): ASSERT failed! optCoercion changed types! in_co: (TypeRep (UnsafeCo nominal Any (Any -> Any)) (UnsafeCo nominal (Any Any) Any))_R in_ty1: TypeRep (Any Any) in_ty2: TypeRep Any out_co: (TypeRep (UnsafeCo nominal Any (Any -> Any)) _N)_R out_ty1: TypeRep Any out_ty2: TypeRep Any subst: [TCvSubst In scope: InScope {wild_00 wild_Xu y_a1t ys_a1u a_ayL $krep_aAd $krep_aAe $krep_aAf $krep_aAg $krep_aAh $krep_aAi $krep_aAj $krep_aAk $krep_aAl $krep_aAm undefined $tcTypeRep $tcSomeTypeRep $tc'TrTyCon $tc'TrApp $trModule $tc'SomeTypeRep bug $trModule_sB4 $trModule_sB5 $trModule_sB6 $trModule_sB7 $tcTypeRep_sB8 $tcTypeRep_sB9 $krep_sBa $krep_sBb $tc'TrTyCon_sBc $tc'TrTyCon_sBd $krep_sBe $krep_sBf $tc'TrApp_sBg $tc'TrApp_sBh $tcSomeTypeRep_sBi $tcSomeTypeRep_sBj $tc'SomeTypeRep_sBk $tc'SomeTypeRep_sBl poly_go_sBz lvl_sBA $spoly_go_sCu sc_sCv sc_sCw $spoly_go_sCx} Type env: [] Co env: []] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1189:22 in ghc:Outputable assertPprPanic, called at compiler/types/OptCoercion.hs:96:188 in ghc:OptCoercion Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1187:5 in ghc:Outputable assertPprPanic, called at compiler/types/OptCoercion.hs:96:188 in ghc:OptCoercion }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 17:39:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 17:39:26 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.8ead526f7f31743336134ef55bfb0484@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Rev(s): Phab:D1278 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Is there a conceptual problem of moving the pattern match checker to the end of typechecking? There is the additional fiddlyness to make sure all pattern occurrences are checked but this seems preferable than making `-fno-code` slower for everyone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 17:54:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 17:54:30 -0000 Subject: [GHC] #13659: Bug report: "AThing evaluated unexpectedly tcTyVar a_alF" In-Reply-To: <049.d62cb96a1aca162d6e090009156f882b@haskell.org> References: <049.d62cb96a1aca162d6e090009156f882b@haskell.org> Message-ID: <064.abd93b451e7875e65d08d70e40c4654c@haskell.org> #13659: Bug report: "AThing evaluated unexpectedly tcTyVar a_alF" -------------------------------------+------------------------------------- Reporter: costaparas | Owner: (none) Type: bug | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I can't reproduce this bug on GHC 8.0.1 or later: {{{ $ /opt/ghc/8.0.1/bin/ghci Bug.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Printf ( Bug.hs, interpreted ) Bug.hs:12:27: error: • Expected a type, but ‘a’ has kind ‘[*]’ • In the first argument of ‘Format’, namely ‘'[Int, a]’ In the type ‘Format '[Int, a]’ In the definition of data constructor ‘I’ Failed, modules loaded: none. }}} Commit 5955510e5f57464b1f4f42b510e3558d6e691380 was what fixed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 18:31:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 18:31:54 -0000 Subject: [GHC] #13658: Assertion failure on HEAD: "optCoercion changed types!" In-Reply-To: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> References: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> Message-ID: <061.cae8e234d0a7d2d165098f96ce3cf52f@haskell.org> #13658: Assertion failure on HEAD: "optCoercion changed types!" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The problem here appears to be that the `TyConAppCo` case of `OptCoercion.opt_univ` fires, {{{#!hs opt_univ env sym prov role oty1 oty2 | Just (tc1, tys1) <- splitTyConApp_maybe oty1 , Just (tc2, tys2) <- splitTyConApp_maybe oty2 , tc1 == tc2 = pprTrace "opt_univ(tyconapp)" (ppr tc1 <+> ppr tys1 $$ ppr tc2 <+> ppr tys2) $ let roles = tyConRolesX role tc1 arg_cos = zipWith3 (mkUnivCo prov) roles tys1 tys2 arg_cos' = zipWith (opt_co4 env sym False) roles arg_cos in mkTyConAppCo role tc1 arg_cos' }}} This emits, {{{ opt_univ(tyconapp) Any [Any -> Any, Any] Any [Any -> Any] }}} for the problematic coercion. The issue here is that we end up dropping the second argument from `tys1` due to the `zipWith`. I suspect we want to add a guard to this equation asserting that `tys1` and `tys2` are of equal lengths. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 18:45:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 18:45:04 -0000 Subject: [GHC] #13658: Assertion failure on HEAD: "optCoercion changed types!" In-Reply-To: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> References: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> Message-ID: <061.e0ea66e1359acf3178ce3b46ccc65f20@haskell.org> #13658: Assertion failure on HEAD: "optCoercion changed types!" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Slightly shorter example without foldl: {{{#!hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE BangPatterns #-} {- # OPTIONS_GHC -Werror #-} {-# OPTIONS_GHC -g -O2 #-} module Bug (bug) where -- import GHC.Base (seq) import Unsafe.Coerce (unsafeCoerce) undefined :: a undefined = undefined data TypeRep (a :: k) where TrTyCon :: TypeRep (a :: k) TrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). TypeRep (a b) data SomeTypeRep where SomeTypeRep :: forall k (a :: k). TypeRep a -> SomeTypeRep mkTrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). TypeRep (a :: k1 -> k2) -> TypeRep (a b) mkTrApp TrTyCon = undefined mkTrApp TrApp = undefined bug :: SomeTypeRep -- bug = f x -- this works bug = f (f x) where x = SomeTypeRep TrTyCon f :: SomeTypeRep -> SomeTypeRep f (SomeTypeRep acc) = SomeTypeRep (mkTrApp (unsafeCoerce acc)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 18:50:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 18:50:01 -0000 Subject: [GHC] #13658: Assertion failure on HEAD: "optCoercion changed types!" In-Reply-To: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> References: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> Message-ID: <061.0d94b6ac31164367a0ee16f3d12ba60d@haskell.org> #13658: Assertion failure on HEAD: "optCoercion changed types!" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed this appears to resolve the issue, {{{#!patch diff --git a/compiler/types/OptCoercion.hs b/compiler/types/OptCoercion.hs index b1aa646a97..03e1d6cb5f 100644 --- a/compiler/types/OptCoercion.hs +++ b/compiler/types/OptCoercion.hs @@ -378,6 +378,7 @@ opt_univ env sym prov role oty1 oty2 | Just (tc1, tys1) <- splitTyConApp_maybe oty1 , Just (tc2, tys2) <- splitTyConApp_maybe oty2 , tc1 == tc2 + , equalLength tys1 tys2 -- NB: prov must not be the two interesting ones (ProofIrrel & Phantom); -- Phantom is already taken care of, and ProofIrrel doesn't relate tyconapps = let roles = tyConRolesX role tc1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 19:10:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 19:10:02 -0000 Subject: [GHC] #13390: Strict literal float-out during desugaring regresses T1969 at -O0 In-Reply-To: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> References: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> Message-ID: <061.373a92cfc03fad1f0fdf1af17fee1760@haskell.org> #13390: Strict literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It wasn't entirely clear to me what "phantom CSE" meant in comment:5. dfeuer clarifies: > there's no actual collapse. Those bindings are just *inlined*, and so they aren't needed anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 19:55:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 19:55:03 -0000 Subject: [GHC] #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function In-Reply-To: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> References: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> Message-ID: <061.2e0e555a4c50b91ff75495664001d16a@haskell.org> #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13014 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Just for the heck of it, I decided to try translating this into class style: {{{#!hs class BangColon e where (!:) :: Arr e -> Int -> e instance BangColon Int where {-# SPECIALISE INLINE (!:) :: Arr Int -> Int -> Int #-} ArrInt ba !: i = ba * i instance (BangColon a, BangColon b) => BangColon (a, b) where {-# SPECIALISE INLINE (!:) :: (BangColon a, BangColon b) => Arr (a, b) -> Int -> (a, b) #-} ArrPair a1 a2 !: i = (a1 !: i, a2 !: i) }}} Written this way, the specializations inline as requested, producing {{{#!hs Dp.example2 :: Int [GblId, Caf=NoCafRefs, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Dp.example2 = GHC.Types.I# 10# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} Dp.example1 :: Int [GblId, Caf=NoCafRefs, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Dp.example1 = GHC.Types.I# 15# -- RHS size: {terms: 3, types: 2, coercions: 0, joins: 0/0} example :: (Int, Int) [GblId, Caf=NoCafRefs, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] example = (Dp.example2, Dp.example1) }}} So the problem seems confined to the GADT function case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 20:38:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 20:38:35 -0000 Subject: [GHC] #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function In-Reply-To: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> References: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> Message-ID: <061.bb633fbc828e1001ead9b7ccc57e17eb@haskell.org> #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13014 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): FYI, it looks like the GADT thing was actually mentioned in the original commit that implemented `SPECIALISE INLINE`: 958924a2b338aebbcc8a88ba2cab511517762a19. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 21:21:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 21:21:58 -0000 Subject: [GHC] #13114: UniqSet definition seems shady In-Reply-To: <045.b5ecdb7a698ef5b3e0fe6cbfbbe5606e@haskell.org> References: <045.b5ecdb7a698ef5b3e0fe6cbfbbe5606e@haskell.org> Message-ID: <060.32819c18efe5b9c07b0a29cfb003be9d@haskell.org> #13114: UniqSet definition seems shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3146 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed * milestone: 8.4.1 => 8.2.1 Comment: Fixed in cbe569a56e2a82bb93a008beb56869d9a6a1d047 {{{ Upgrade UniqSet to a newtype The fundamental problem with type UniqSet = UniqFM is that UniqSet has a key invariant UniqFM does not. For example, fmap over UniqSet will generally produce nonsense. Upgrade UniqSet from a type synonym to a newtype. Remove unused and shady extendVarSet_C and addOneToUniqSet_C. Use cached unique in tyConsOfType by replacing unitNameEnv (tyConName tc) tc with unitUniqSet tc. Reviewers: austin, hvr, goldfire, simonmar, niteria, bgamari Reviewed By: niteria Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3146 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 22:36:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 22:36:19 -0000 Subject: [GHC] #13658: Assertion failure on HEAD: "optCoercion changed types!" In-Reply-To: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> References: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> Message-ID: <061.362ae1a4a83de7fc289cb3d347a34c24@haskell.org> #13658: Assertion failure on HEAD: "optCoercion changed types!" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.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:D3545 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3545 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 7 23:22:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 May 2017 23:22:45 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.f83892ceb0f3b2902c15706699d6d266@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 07:19:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 07:19:07 -0000 Subject: [GHC] #12075: Fails to build on powerpcspe because of inline assembly In-Reply-To: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> References: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> Message-ID: <062.8bbd1989640bc20deaa858361e8faec4@haskell.org> #12075: Fails to build on powerpcspe because of inline assembly ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3540 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by trommler): * status: patch => infoneeded Comment: Replying to [comment:15 bgamari]: > Note: Phab:D3540 does not fix @glaubitz' issue in this ticket but fixes a bug that I discovered while I investigated the bug on powerpc64le Linux. AIX is also affected by the same bug, I think. As I said in comment:11 no inline assembly from `StgCRun.c` nor any code from `StgCRunAsm.S` should be passed to the assembler on a powerpc (32-bit) configured with `--enable-unregsisterised`. I also don't understand why `HeapStackCheck.cmm` fails. It does not contain any inline assembly. I wonder whether ghc does not pass the options required for @glaubitz' system (soft float implementation) to gcc. I set status `infoneeded` again while we are waiting for the input requested in comment:11 and comment:14. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 10:37:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 10:37:01 -0000 Subject: [GHC] #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function In-Reply-To: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> References: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> Message-ID: <061.78c6de6705c1f39214b12baf0602bfb4@haskell.org> #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13014 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): It still isn't clear what is going on here but there seems to be some kind of interaction with `SpecConstr`. If you turn it off with `-fno-spec- constr` then the same module example doesn't get super compiled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 11:44:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 11:44:06 -0000 Subject: [GHC] #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. In-Reply-To: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> References: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> Message-ID: <064.d40ec911ba1c7f47479084642627ce0e@haskell.org> #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | RebindableSyntax Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes I agree... if the pattern returns true to `isIrrefutableHsPat` we should not look up the fail function. It'd be great if someone could fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 12:35:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 12:35:46 -0000 Subject: [GHC] #13659: Bug report: "AThing evaluated unexpectedly tcTyVar a_alF" In-Reply-To: <049.d62cb96a1aca162d6e090009156f882b@haskell.org> References: <049.d62cb96a1aca162d6e090009156f882b@haskell.org> Message-ID: <064.fd5f12f6decaa101d662e53daa7e0ab6@haskell.org> #13659: Bug report: "AThing evaluated unexpectedly tcTyVar a_alF" -------------------------------------+------------------------------------- Reporter: costaparas | Owner: (none) Type: bug | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'll add a regression test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 13:56:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 13:56:36 -0000 Subject: [GHC] #13633: testwsdeque failure on POWER8 In-Reply-To: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> References: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> Message-ID: <062.f2a216b2a9cefc5e7e152b16d81f7152@haskell.org> #13633: testwsdeque failure on POWER8 -----------------------------------+--------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: SMP Operating System: Linux | Architecture: powerpc64 Type of failure: Runtime crash | Test Case: rts/testwsdeque Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------------- Comment (by trommler): Replying to [comment:1 simonmar]: > This is bad and suggests that either we're using the wrong barriers in the implementation, or the implementation of the barriers is wrong for POWER8. I looked at the implementation of the barriers and `cas()` in `SMP.h`again and they are correct for POWER and PowerPC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 14:03:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 14:03:16 -0000 Subject: [GHC] #13661: User manual warnings Message-ID: <046.a508cf314fe89c8eac2361ee70eaeaa8@haskell.org> #13661: User manual warnings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm seeing these warnings when typesetting the user manual: {{{ /5playpen/simonpj/HEAD-4/docs/users_guide/8.2.1-notes.rst:422: WARNING: Bullet list ends without a blank line; unexpected unindent. /5playpen/simonpj/HEAD-4/docs/users_guide/using-warnings.rst:4: SEVERE: Duplicate ID: "ghc-flag--Werror". /5playpen/simonpj/HEAD-4/docs/users_guide/using-warnings.rst:4: SEVERE: Duplicate ID: "ghc-flag--Wwarn". /5playpen/simonpj/HEAD-4/docs/users_guide/8.2.1-notes.rst:422: WARNING: Bullet list ends without a blank line; unexpected unindent. /5playpen/simonpj/HEAD-4/docs/users_guide/using-warnings.rst:4: SEVERE: Duplicate ID: "ghc-flag--Werror". /5playpen/simonpj/HEAD-4/docs/users_guide/using-warnings.rst:4: SEVERE: Duplicate ID: "ghc-flag--Wwarn". /5playpen/simonpj/HEAD-4/docs/users_guide/profiling.rst:507: WARNING: Pygments lexer name u'json' is not known docs/users_guide/flags-warnings.gen.rst:166: WARNING: undefined label: deferred until runtime. see :ghc-flag: (if the link has no caption the label must precede a section header) docs/users_guide/all-flags.gen.rst:1644: WARNING: undefined label: deferred until runtime. see :ghc-flag: (if the link has no caption the label must precede a section header) /5playpen/simonpj/HEAD-4/docs/users_guide/glasgow_exts.rst:9373: WARNING: undefined label: implicit-quantification (if the link has no caption the label must precede a section header) }}} Could someone fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 14:13:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 14:13:19 -0000 Subject: [GHC] #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... Message-ID: <046.97ac1572178bf3067f644135fab3a749@haskell.org> #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 (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: -------------------------------------+------------------------------------- The following example is a pretty involved use of type equality. It was accepted by GHC-8.0 and before, but GHC-8.2.0.20170505 cannot infer a type. {{{ $ cat MonomorphismEquality.hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} module MonomorphismEquality (run) where newtype Value a = Value a type family Repr (f :: * -> *) a :: * type instance Repr f Int = f Int class (Repr Value i ~ Value ir) => Native i ir where instance Native Int Int where fromInt :: (Native i ir) => i -> a fromInt = undefined apply :: (Int -> a -> a) -> a -> a apply weight = id run :: Float -> Float run = let weight = \clip v -> fromInt clip * v in apply weight $ ghc-8.0.2 -Wall MonomorphismEquality.hs [1 of 1] Compiling MonomorphismEquality ( MonomorphismEquality.hs, MonomorphismEquality.o ) MonomorphismEquality.hs:6:19: warning: [-Wunused-top-binds] Defined but not used: data constructor ‘Value’ MonomorphismEquality.hs:20:7: warning: [-Wunused-matches] Defined but not used: ‘weight’ $ ghc-8.2.0.20170505 -Wall MonomorphismEquality.hs [1 of 1] Compiling MonomorphismEquality ( MonomorphismEquality.hs, MonomorphismEquality.o ) MonomorphismEquality.hs:24:28: error: • Ambiguous type variable ‘ir0’ arising from a use of ‘fromInt’ prevents the constraint ‘(Native Int ir0)’ from being solved. Probable fix: use a type annotation to specify what ‘ir0’ should be. These potential instance exist: instance Native Int Int -- Defined at MonomorphismEquality.hs:13:10 • In the first argument of ‘(*)’, namely ‘fromInt clip’ In the expression: fromInt clip * v In the expression: \ clip v -> fromInt clip * v | 24 | let weight = \clip v -> fromInt clip * v | ^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 14:16:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 14:16:00 -0000 Subject: [GHC] #13663: Option to disable turning recursive let-bindings to recursive functions Message-ID: <046.2a207aae524e85e0c4e85fe4625d0622@haskell.org> #13663: Option to disable turning recursive let-bindings to recursive functions -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First some context: I'm using the GHC API to convert Haskell to digital circuit descriptions (clash compiler). When viewed as a structural description of a circuit, recursive let- bindings can be turned into feedback loops. In general, when viewed as a structural description of a circuit, recursive functions describe infinite hierarchy, i.e. they are not realisable as circuit. So now my problem: the simplifier turns recursive let-bindings to recursive functions; i.e. it is turning something which I can translate to a circuit to something which I cannot translate to a circuit. Next follows a reduced test case which exemplifies this behaviour: {{{#!haskell module Test where import Control.Applicative topEntity :: [((),())] topEntity = (,) <$> outport1 <*> outport2 where (outport1, outResp1) = gpio (decodeReq 1 req) (outport2, outResp2) = gpio (decodeReq 2 req) ramResp = ram (decodeReq 0 req) req = core $ (<|>) <$> ramResp <*> ((<|>) <$> outResp1 <*> outResp2) core :: [Maybe ()] -> [()] core = fmap (maybe () id) {-# NOINLINE core #-} ram :: [()] -> [Maybe ()] ram = fmap pure {-# NOINLINE ram #-} decodeReq :: Integer -> [()] -> [()] decodeReq 0 = fmap (const ()) decodeReq 1 = id decodeReq _ = fmap id {-# NOINLINE decodeReq #-} gpio :: [()] -> ([()],[Maybe ()]) gpio i = (i,pure <$> i) {-# NOINLINE gpio #-} }}} Now, when we look at the output of the desugarer (-ddump-ds), we can see that the core-level binder of `topEntity` basically follows the Haskell code. {{{#!haskell topEntity :: [((), ())] [LclIdX] topEntity = letrec { ds_d2rI :: ([()], [Maybe ()]) [LclId] ds_d2rI = gpio (decodeReq 1 req_a2pF); ds_d2rS :: ([()], [Maybe ()]) [LclId] ds_d2rS = gpio (decodeReq 2 req_a2pF); req_a2pF [Occ=LoopBreaker] :: [()] [LclId] req_a2pF = $ @ 'GHC.Types.LiftedRep @ [Maybe ()] @ [()] core (<*> @ [] GHC.Base.$fApplicative[] @ (Maybe ()) @ (Maybe ()) (<$> @ [] @ (Maybe ()) @ (Maybe () -> Maybe ()) GHC.Base.$fFunctor[] (<|> @ Maybe GHC.Base.$fAlternativeMaybe @ ()) (ram (decodeReq 0 req_a2pF))) (<*> @ [] GHC.Base.$fApplicative[] @ (Maybe ()) @ (Maybe ()) (<$> @ [] @ (Maybe ()) @ (Maybe () -> Maybe ()) GHC.Base.$fFunctor[] (<|> @ Maybe GHC.Base.$fAlternativeMaybe @ ()) (case ds_d2rI of { (_ [Occ=Dead], outResp1_X2pQ) -> outResp1_X2pQ })) (case ds_d2rS of { (_ [Occ=Dead], outResp2_X2q2) -> outResp2_X2q2 }))); } in <*> @ [] GHC.Base.$fApplicative[] @ () @ ((), ()) (<$> @ [] @ () @ (() -> ((), ())) GHC.Base.$fFunctor[] (GHC.Tuple.(,) @ () @ ()) (case ds_d2rI of { (outport1_a2pA, _ [Occ=Dead]) -> outport1_a2pA })) (case ds_d2rS of { (outport2_a2pM, _ [Occ=Dead]) -> outport2_a2pM }) }}} However, when we look at the simplifier output, with nearly all transformations disabled (-O0 -ddump-ds), you will see that parts of `topEntity` are split into 3 different top-level, mutually recursive, functions. {{{#!haskell Rec { ds_r2so :: ([()], [Maybe ()]) ds_r2so = gpio (decodeReq 1 req_r2sq) -- RHS size: {terms: 4, types: 0, coercions: 0, joins: 0/0} ds1_r2sp :: ([()], [Maybe ()]) ds1_r2sp = gpio (decodeReq 2 req_r2sq) req_r2sq :: [()] req_r2sq = core (<*> @ [] GHC.Base.$fApplicative[] @ (Maybe ()) @ (Maybe ()) (<$> @ [] @ (Maybe ()) @ (Maybe () -> Maybe ()) GHC.Base.$fFunctor[] (<|> @ Maybe GHC.Base.$fAlternativeMaybe @ ()) (ram (decodeReq 0 req_r2sq))) (<*> @ [] GHC.Base.$fApplicative[] @ (Maybe ()) @ (Maybe ()) (<$> @ [] @ (Maybe ()) @ (Maybe () -> Maybe ()) GHC.Base.$fFunctor[] (<|> @ Maybe GHC.Base.$fAlternativeMaybe @ ()) (case ds_r2so of { (outport1_a2pA, outResp1_X2pQ) -> outResp1_X2pQ })) (case ds1_r2sp of { (outport2_a2pM, outResp2_X2q2) -> outResp2_X2q2 }))) end Rec } topEntity :: [((), ())] topEntity = <*> @ [] GHC.Base.$fApplicative[] @ () @ ((), ()) (<$> @ [] @ () @ (() -> ((), ())) GHC.Base.$fFunctor[] (GHC.Tuple.(,) @ () @ ()) (case ds_r2so of { (outport1_a2pA, outResp1_X2pQ) -> outport1_a2pA })) (case ds1_r2sp of { (outport2_a2pM, outResp2_X2q2) -> outport2_a2pM }) }}} So my question are: - Which part of the simplifier is turning these local recursive let- binders into global recursive functions? - Is there some way to disable this transformation? - If not, how much effort do you think it would be to put this behaviour behind a dynflag? So that I, as a GHC API user, can disable it for my use- case. I'm willing to implements this dynflag myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 14:21:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 14:21:06 -0000 Subject: [GHC] #13664: Ill formatted warning about tabulators Message-ID: <046.b26a1d2020e1e5fb1578aa510b2685ff@haskell.org> #13664: Ill formatted warning about tabulators -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC-8.2.0.20170505 does not format warnings about tabulators very well. It seems to use the tab character for formatting, which yields too few spaces when formatted, and in turn too many characters are colored. (It is hard to present the problem in this ticket, though.) {{{ $ cat Tabulator.hs module Tabulator where x :: Int x = 1*2*3*4*5*6*7*8*9 -- we use a tab for indentation here $ ghc-8.2.0.20170505 -Wall Tabulator.hs [1 of 1] Compiling Tabulator ( Tabulator.hs, Tabulator.o ) Tabulator.hs:5:1: warning: [-Wtabs] Tab character found here. Please use spaces instead. | 5 | 1*2*3*4*5*6*7*8*9 | ^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 14:22:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 14:22:28 -0000 Subject: [GHC] #13663: Option to disable turning recursive let-bindings to recursive functions In-Reply-To: <046.2a207aae524e85e0c4e85fe4625d0622@haskell.org> References: <046.2a207aae524e85e0c4e85fe4625d0622@haskell.org> Message-ID: <061.c6bfd678f06a5fefc7bba56aebed6aa2@haskell.org> #13663: Option to disable turning recursive let-bindings to recursive functions -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by darchon: @@ -49,3 +49,3 @@ - Now, when we look at the output of the desugarer (-ddump-ds), we can see - that the core-level binder of `topEntity` basically follows the Haskell - code. + Now, when we look at the output of the desugarer (-ddump-ds -dsuppress- + all), we can see that the core-level binder of `topEntity` basically + follows the Haskell code. @@ -55,1 +55,0 @@ - [LclIdX] @@ -59,2 +58,1 @@ - [LclId] - ds_d2rI = gpio (decodeReq 1 req_a2pF); + ds_d2rI = gpio (decodeReq 1 req_a2pG); @@ -62,9 +60,4 @@ - [LclId] - ds_d2rS = gpio (decodeReq 2 req_a2pF); - req_a2pF [Occ=LoopBreaker] :: [()] - [LclId] - req_a2pF - = $ @ 'GHC.Types.LiftedRep - @ [Maybe ()] - @ [()] - core + ds_d2rS = gpio (decodeReq 2 req_a2pG); + req_a2pG :: [()] + req_a2pG + = $ core @@ -72,4 +65,1 @@ - @ [] - GHC.Base.$fApplicative[] - @ (Maybe ()) - @ (Maybe ()) + $fApplicative[] @@ -77,6 +67,2 @@ - @ [] - @ (Maybe ()) - @ (Maybe () -> Maybe ()) - GHC.Base.$fFunctor[] - (<|> @ Maybe GHC.Base.$fAlternativeMaybe @ ()) - (ram (decodeReq 0 req_a2pF))) + $fFunctor[] (<|> $fAlternativeMaybe) (ram (decodeReq 0 + req_a2pG))) @@ -84,4 +70,1 @@ - @ [] - GHC.Base.$fApplicative[] - @ (Maybe ()) - @ (Maybe ()) + $fApplicative[] @@ -89,11 +72,6 @@ - @ [] - @ (Maybe ()) - @ (Maybe () -> Maybe ()) - GHC.Base.$fFunctor[] - (<|> @ Maybe GHC.Base.$fAlternativeMaybe @ ()) - (case ds_d2rI of { (_ [Occ=Dead], outResp1_X2pQ) -> - outResp1_X2pQ - })) - (case ds_d2rS of { (_ [Occ=Dead], outResp2_X2q2) -> - outResp2_X2q2 - }))); } in + $fFunctor[] + (<|> $fAlternativeMaybe) + (case ds_d2rI of { (_, outResp1_X2pR) -> + outResp1_X2pR })) + (case ds_d2rS of { (_, outResp2_X2q3) -> outResp2_X2q3 + }))); } in @@ -101,4 +79,1 @@ - @ [] - GHC.Base.$fApplicative[] - @ () - @ ((), ()) + $fApplicative[] @@ -106,11 +81,4 @@ - @ [] - @ () - @ (() -> ((), ())) - GHC.Base.$fFunctor[] - (GHC.Tuple.(,) @ () @ ()) - (case ds_d2rI of { (outport1_a2pA, _ [Occ=Dead]) -> - outport1_a2pA - })) - (case ds_d2rS of { (outport2_a2pM, _ [Occ=Dead]) -> - outport2_a2pM - }) + $fFunctor[] + (,) + (case ds_d2rI of { (outport1_a2pB, _) -> outport1_a2pB })) + (case ds_d2rS of { (outport2_a2pN, _) -> outport2_a2pN }) @@ -120,3 +88,3 @@ - transformations disabled (-O0 -ddump-ds), you will see that parts of - `topEntity` are split into 3 different top-level, mutually recursive, - functions. + transformations disabled (-O0 -ddump-simpl -dsuppress-all), you will see + that parts of `topEntity` are split into 3 different top-level, mutually + recursive, functions. @@ -126,0 +94,1 @@ + -- RHS size: {terms: 4, types: 0, coercions: 0, joins: 0/0} @@ -133,0 +102,1 @@ + -- RHS size: {terms: 25, types: 50, coercions: 0, joins: 0/0} @@ -137,4 +107,1 @@ - @ [] - GHC.Base.$fApplicative[] - @ (Maybe ()) - @ (Maybe ()) + $fApplicative[] @@ -142,6 +109,2 @@ - @ [] - @ (Maybe ()) - @ (Maybe () -> Maybe ()) - GHC.Base.$fFunctor[] - (<|> @ Maybe GHC.Base.$fAlternativeMaybe @ ()) - (ram (decodeReq 0 req_r2sq))) + $fFunctor[] (<|> $fAlternativeMaybe) (ram (decodeReq 0 + req_r2sq))) @@ -149,4 +112,1 @@ - @ [] - GHC.Base.$fApplicative[] - @ (Maybe ()) - @ (Maybe ()) + $fApplicative[] @@ -154,7 +114,4 @@ - @ [] - @ (Maybe ()) - @ (Maybe () -> Maybe ()) - GHC.Base.$fFunctor[] - (<|> @ Maybe GHC.Base.$fAlternativeMaybe @ ()) - (case ds_r2so of { (outport1_a2pA, outResp1_X2pQ) -> - outResp1_X2pQ + $fFunctor[] + (<|> $fAlternativeMaybe) + (case ds_r2so of { (outport1_a2pB, outResp1_X2pR) -> + outResp1_X2pR @@ -162,2 +119,2 @@ - (case ds1_r2sp of { (outport2_a2pM, outResp2_X2q2) -> - outResp2_X2q2 + (case ds1_r2sp of { (outport2_a2pN, outResp2_X2q3) -> + outResp2_X2q3 @@ -167,0 +124,1 @@ + -- RHS size: {terms: 13, types: 35, coercions: 0, joins: 0/0} @@ -170,4 +128,1 @@ - @ [] - GHC.Base.$fApplicative[] - @ () - @ ((), ()) + $fApplicative[] @@ -175,7 +130,4 @@ - @ [] - @ () - @ (() -> ((), ())) - GHC.Base.$fFunctor[] - (GHC.Tuple.(,) @ () @ ()) - (case ds_r2so of { (outport1_a2pA, outResp1_X2pQ) -> - outport1_a2pA + $fFunctor[] + (,) + (case ds_r2so of { (outport1_a2pB, outResp1_X2pR) -> + outport1_a2pB @@ -183,2 +135,2 @@ - (case ds1_r2sp of { (outport2_a2pM, outResp2_X2q2) -> - outport2_a2pM + (case ds1_r2sp of { (outport2_a2pN, outResp2_X2q3) -> + outport2_a2pN New description: First some context: I'm using the GHC API to convert Haskell to digital circuit descriptions (clash compiler). When viewed as a structural description of a circuit, recursive let- bindings can be turned into feedback loops. In general, when viewed as a structural description of a circuit, recursive functions describe infinite hierarchy, i.e. they are not realisable as circuit. So now my problem: the simplifier turns recursive let-bindings to recursive functions; i.e. it is turning something which I can translate to a circuit to something which I cannot translate to a circuit. Next follows a reduced test case which exemplifies this behaviour: {{{#!haskell module Test where import Control.Applicative topEntity :: [((),())] topEntity = (,) <$> outport1 <*> outport2 where (outport1, outResp1) = gpio (decodeReq 1 req) (outport2, outResp2) = gpio (decodeReq 2 req) ramResp = ram (decodeReq 0 req) req = core $ (<|>) <$> ramResp <*> ((<|>) <$> outResp1 <*> outResp2) core :: [Maybe ()] -> [()] core = fmap (maybe () id) {-# NOINLINE core #-} ram :: [()] -> [Maybe ()] ram = fmap pure {-# NOINLINE ram #-} decodeReq :: Integer -> [()] -> [()] decodeReq 0 = fmap (const ()) decodeReq 1 = id decodeReq _ = fmap id {-# NOINLINE decodeReq #-} gpio :: [()] -> ([()],[Maybe ()]) gpio i = (i,pure <$> i) {-# NOINLINE gpio #-} }}} Now, when we look at the output of the desugarer (-ddump-ds -dsuppress- all), we can see that the core-level binder of `topEntity` basically follows the Haskell code. {{{#!haskell topEntity :: [((), ())] topEntity = letrec { ds_d2rI :: ([()], [Maybe ()]) ds_d2rI = gpio (decodeReq 1 req_a2pG); ds_d2rS :: ([()], [Maybe ()]) ds_d2rS = gpio (decodeReq 2 req_a2pG); req_a2pG :: [()] req_a2pG = $ core (<*> $fApplicative[] (<$> $fFunctor[] (<|> $fAlternativeMaybe) (ram (decodeReq 0 req_a2pG))) (<*> $fApplicative[] (<$> $fFunctor[] (<|> $fAlternativeMaybe) (case ds_d2rI of { (_, outResp1_X2pR) -> outResp1_X2pR })) (case ds_d2rS of { (_, outResp2_X2q3) -> outResp2_X2q3 }))); } in <*> $fApplicative[] (<$> $fFunctor[] (,) (case ds_d2rI of { (outport1_a2pB, _) -> outport1_a2pB })) (case ds_d2rS of { (outport2_a2pN, _) -> outport2_a2pN }) }}} However, when we look at the simplifier output, with nearly all transformations disabled (-O0 -ddump-simpl -dsuppress-all), you will see that parts of `topEntity` are split into 3 different top-level, mutually recursive, functions. {{{#!haskell Rec { -- RHS size: {terms: 4, types: 0, coercions: 0, joins: 0/0} ds_r2so :: ([()], [Maybe ()]) ds_r2so = gpio (decodeReq 1 req_r2sq) -- RHS size: {terms: 4, types: 0, coercions: 0, joins: 0/0} ds1_r2sp :: ([()], [Maybe ()]) ds1_r2sp = gpio (decodeReq 2 req_r2sq) -- RHS size: {terms: 25, types: 50, coercions: 0, joins: 0/0} req_r2sq :: [()] req_r2sq = core (<*> $fApplicative[] (<$> $fFunctor[] (<|> $fAlternativeMaybe) (ram (decodeReq 0 req_r2sq))) (<*> $fApplicative[] (<$> $fFunctor[] (<|> $fAlternativeMaybe) (case ds_r2so of { (outport1_a2pB, outResp1_X2pR) -> outResp1_X2pR })) (case ds1_r2sp of { (outport2_a2pN, outResp2_X2q3) -> outResp2_X2q3 }))) end Rec } -- RHS size: {terms: 13, types: 35, coercions: 0, joins: 0/0} topEntity :: [((), ())] topEntity = <*> $fApplicative[] (<$> $fFunctor[] (,) (case ds_r2so of { (outport1_a2pB, outResp1_X2pR) -> outport1_a2pB })) (case ds1_r2sp of { (outport2_a2pN, outResp2_X2q3) -> outport2_a2pN }) }}} So my question are: - Which part of the simplifier is turning these local recursive let- binders into global recursive functions? - Is there some way to disable this transformation? - If not, how much effort do you think it would be to put this behaviour behind a dynflag? So that I, as a GHC API user, can disable it for my use- case. I'm willing to implements this dynflag myself. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 14:29:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 14:29:12 -0000 Subject: [GHC] #13663: Option to disable turning recursive let-bindings to recursive functions In-Reply-To: <046.2a207aae524e85e0c4e85fe4625d0622@haskell.org> References: <046.2a207aae524e85e0c4e85fe4625d0622@haskell.org> Message-ID: <061.4939e66d927d14bc185d01c353e3f53e@haskell.org> #13663: Option to disable turning recursive let-bindings to recursive functions -------------------------------------+------------------------------------- Reporter: darchon | 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 simonpj): As Ben says, it's `doFloatFromRhs` in the simplifier. But maybe you should just not run the simplifier ''at all''? What's wrong with that? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 14:35:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 14:35:26 -0000 Subject: [GHC] #13663: Option to disable turning recursive let-bindings to recursive functions In-Reply-To: <046.2a207aae524e85e0c4e85fe4625d0622@haskell.org> References: <046.2a207aae524e85e0c4e85fe4625d0622@haskell.org> Message-ID: <061.6499efbb59b5e84a78bd3f41b89c5780@haskell.org> #13663: Option to disable turning recursive let-bindings to recursive functions -------------------------------------+------------------------------------- Reporter: darchon | 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 darchon): Experience has shown that, across the board, turning on the simplifier: - reduces compile times (going from Haskell description to circuit) - results in circuits are smaller - results circuits are faster I would hence rather not disable the simplifier. Do note that I actually run with a very specific set of transformations: https://github.com/clash- lang/clash-compiler/blob/bd9f7df892ad90f6147fae0854e38c547d1d4ff4/clash- ghc/src-ghc/CLaSH/GHC/LoadModules.hs#L283 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 15:37:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 15:37:49 -0000 Subject: [GHC] #13664: Ill formatted warning about tabulators In-Reply-To: <046.b26a1d2020e1e5fb1578aa510b2685ff@haskell.org> References: <046.b26a1d2020e1e5fb1578aa510b2685ff@haskell.org> Message-ID: <061.73171e4f536b60801b2139e5ec465e07@haskell.org> #13664: Ill formatted warning about tabulators -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: Rufflewind (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 16:17:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 16:17:07 -0000 Subject: [GHC] #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... In-Reply-To: <046.97ac1572178bf3067f644135fab3a749@haskell.org> References: <046.97ac1572178bf3067f644135fab3a749@haskell.org> Message-ID: <061.9e1f9b80c1cda18eda81e059e8fe7a73@haskell.org> #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah good. I know what is going on here. Fix coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 16:17:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 16:17:41 -0000 Subject: [GHC] #13663: Option to disable turning recursive let-bindings to recursive functions In-Reply-To: <046.2a207aae524e85e0c4e85fe4625d0622@haskell.org> References: <046.2a207aae524e85e0c4e85fe4625d0622@haskell.org> Message-ID: <061.63d711959c64f951d93bb0531d4d4b38@haskell.org> #13663: Option to disable turning recursive let-bindings to recursive functions -------------------------------------+------------------------------------- Reporter: darchon | 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 simonpj): OK, well by all means add a flag to disable `doFloatFromRhs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 16:21:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 16:21:32 -0000 Subject: [GHC] #13657: Documentation: Functional dependencies by other means In-Reply-To: <043.e6a2276b874588c5228bad3b9ffdb642@haskell.org> References: <043.e6a2276b874588c5228bad3b9ffdb642@haskell.org> Message-ID: <058.dbc64744f9aed010e08fcff23d194b97@haskell.org> #13657: Documentation: Functional dependencies by other means -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: 10431 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): We could add it to the user manual. But alternatively, and perhaps better, we have [https://wiki.haskell.org/GHC GHC's collaborative documentation pages]. These are on the Haskell wiki, writable by anyone. The user manual is meant to specify what GHC does; these pages give advice about how to get the job done, examples, etc. The notes you give above would be rather good there. (The contents page itself could do with some editing work too!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 16:25:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 16:25:42 -0000 Subject: [GHC] #13575: GHC downloads do not work In-Reply-To: <044.170356ad5872efe897d21eaa1885b4f7@haskell.org> References: <044.170356ad5872efe897d21eaa1885b4f7@haskell.org> Message-ID: <059.0e5d42b3315baa0cce88b623a00470ae@haskell.org> #13575: GHC downloads do not work -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This is now resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 17:14:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 17:14:26 -0000 Subject: [GHC] #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function In-Reply-To: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> References: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> Message-ID: <061.27eacba1839025d7c1a28a521ee636bf@haskell.org> #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13014, #10346 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: #13014 => #13014, #10346 Comment: And of course, the reason that it doesn't work across modules is that `SpecConstr` doesn't work across modules (see #10346). After this analysis, I understand operationally how the program is optimised but I don't understand how the pragma is meant to achieve the unrolling if it relies on `SpecConstr` to inline a loop breaker using a RULE. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 17:15:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 17:15:34 -0000 Subject: [GHC] #13568: Name is reported as ambiguous and not in scope In-Reply-To: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> References: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> Message-ID: <064.d7bb0fb20f4d229577cae37b921c7609@haskell.org> #13568: Name is reported as ambiguous and not in scope -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3457 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mrkgnao): * differential: => D3457 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 17:16:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 17:16:06 -0000 Subject: [GHC] #13568: Name is reported as ambiguous and not in scope In-Reply-To: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> References: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> Message-ID: <064.82f143b2c70afa00cf01def8cbce6acd@haskell.org> #13568: Name is reported as ambiguous and not in scope -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3547 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mrkgnao): * differential: D3457 => D3547 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 18:17:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 18:17:39 -0000 Subject: [GHC] #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function In-Reply-To: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> References: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> Message-ID: <061.737e4519a5df0727cb60c403541230e2@haskell.org> #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13014 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: #13014, #10346 => #13014 Comment: In fact, removing the `SPECIALISE INLINE` pragmas then `SpecConstr` still super compiles the example (in the same module) so really this is a duplicate of #10346 ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 18:20:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 18:20:03 -0000 Subject: [GHC] #13665: Broken Link in GHC Docs for Custom compile-time errors Message-ID: <047.03e65d42181d19b2ed8a0f8936a8437c@haskell.org> #13665: Broken Link in GHC Docs for Custom compile-time errors -------------------------------------+------------------------------------- Reporter: atwupack | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1-rc1 Keywords: | Operating System: Other Architecture: Other | Type of failure: Documentation | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, in the GHC documentation for custom compile-time errors is a link to the GHC.TypeLits module which is broken. It points to GHC.TypeList instead of GHC.TypeLits. This is the case for 8.0.1, 8.0.2 and 8.2.1-rc1 as far as I have checked. URL: https://downloads.haskell.org/~ghc/8.2.1-rc1/docs/html/users_guide/glasgow_exts.html #custom-compile-time-errors André -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 18:53:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 18:53:55 -0000 Subject: [GHC] #2168: ghci should show haddock comments for identifier In-Reply-To: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> References: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> Message-ID: <064.ae9a445acd9a33d692fbd5e364ff81f2@haskell.org> #2168: ghci should show haddock comments for identifier -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.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 ntc2): * cc: ntc2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 19:13:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 19:13:28 -0000 Subject: [GHC] #13666: The fake gcc can't handle trailing backslashes Message-ID: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> #13666: The fake gcc can't handle trailing backslashes ----------------------------------------+--------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Driver | Version: 8.0.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: ----------------------------------------+--------------------------------- The fake gcc will choke on trailing backslashes in arguments, like -Iinclude\ or -Llibs\. `realgcc` handles them fine. It seems to insert as spurious quote or terminating a quote too early. Error message: {{{ .\test-ghc.c:1:20: fatal error: test-inc"/header.h: Invalid argument compilation terminated. }}} Found here: [https://github.com/idris-lang/Idris-dev/issues/3801] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 19:14:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 19:14:16 -0000 Subject: [GHC] #13666: The fake gcc can't handle trailing backslashes In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <061.98f920f6dacd1e6fc7a6471f350c3a40@haskell.org> #13666: The fake gcc can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Description changed by niklasl: @@ -2,2 +2,2 @@ - -Iinclude\ or -Llibs\. `realgcc` handles them fine. It seems to insert as - spurious quote or terminating a quote too early. + `-Iinclude\` or `-Llibs\`. `realgcc` handles them fine. It seems to insert + as spurious quote or terminating a quote too early. New description: The fake gcc will choke on trailing backslashes in arguments, like `-Iinclude\` or `-Llibs\`. `realgcc` handles them fine. It seems to insert as spurious quote or terminating a quote too early. Error message: {{{ .\test-ghc.c:1:20: fatal error: test-inc"/header.h: Invalid argument compilation terminated. }}} Found here: [https://github.com/idris-lang/Idris-dev/issues/3801] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 19:49:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 19:49:34 -0000 Subject: [GHC] #13666: The fake gcc can't handle trailing backslashes In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <061.236d3edcfffe8995b7be8e9289d8421b@haskell.org> #13666: The fake gcc can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): "Fake gcc" here means ghc invoked on a C source file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 21:15:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 21:15:58 -0000 Subject: [GHC] #13664: Ill formatted warning about tabulators In-Reply-To: <046.b26a1d2020e1e5fb1578aa510b2685ff@haskell.org> References: <046.b26a1d2020e1e5fb1578aa510b2685ff@haskell.org> Message-ID: <061.20cb26839296598f78403dd1a7dac4b1@haskell.org> #13664: Ill formatted warning about tabulators -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3549 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Rufflewind): * status: new => patch * differential: => D3549 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 21:32:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 21:32:47 -0000 Subject: [GHC] #13664: Ill formatted warning about tabulators In-Reply-To: <046.b26a1d2020e1e5fb1578aa510b2685ff@haskell.org> References: <046.b26a1d2020e1e5fb1578aa510b2685ff@haskell.org> Message-ID: <061.4ce8236608e599427a4927756744ae53@haskell.org> #13664: Ill formatted warning about tabulators -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3549 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: D3549 => Phab:D3549 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 21:37:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 21:37:22 -0000 Subject: [GHC] #13665: Broken Link in GHC Docs for Custom compile-time errors In-Reply-To: <047.03e65d42181d19b2ed8a0f8936a8437c@haskell.org> References: <047.03e65d42181d19b2ed8a0f8936a8437c@haskell.org> Message-ID: <062.875c2cc48f45b4ddeadc358c50cd8c61@haskell.org> #13665: Broken Link in GHC Docs for Custom compile-time errors --------------------------------------+--------------------------------- Reporter: atwupack | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Other | Architecture: Other Type of failure: Documentation bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+--------------------------------- Comment (by Ben Gamari ): In [changeset:"476307cee7ff142b0eff91d45fddf17775417814/ghc" 476307c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="476307cee7ff142b0eff91d45fddf17775417814" users-guide: Fix a variety of warnings Including #13665. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 21:39:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 21:39:17 -0000 Subject: [GHC] #13665: Broken Link in GHC Docs for Custom compile-time errors In-Reply-To: <047.03e65d42181d19b2ed8a0f8936a8437c@haskell.org> References: <047.03e65d42181d19b2ed8a0f8936a8437c@haskell.org> Message-ID: <062.b2499993054b1e981d0056df1b643b6e@haskell.org> #13665: Broken Link in GHC Docs for Custom compile-time errors --------------------------------------+--------------------------------- Reporter: atwupack | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Documentation | Version: 8.2.1-rc1 Resolution: fixed | Keywords: Operating System: Other | Architecture: Other Type of failure: Documentation bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+--------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Thanks for reporting this! This will be fixed in 8.2.1 (merged to `ghc-8.2` as cead1b7043bbc594a1e569f2bf3cbda39c514b95, which won't be present in rc2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 22:46:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 22:46:52 -0000 Subject: [GHC] #13667: Error while running stack upgrade Message-ID: <048.3e7cd90e3544b4ff4c770685970d14ce@haskell.org> #13667: Error while running stack upgrade ----------------------------------------+--------------------------------- Reporter: diego.saa | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: stack ghc | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- $ stack upgrade Fetching package index ...remote: Counting objects: 11, done. remote: Compressing objects: 100% (8/8), done. remote: Total 11 (delta 3), reused 11 (delta 3), pack-reused 0 Unpacking objects: 100% (11/11), done. From https://github.com/commercialhaskell/all-cabal-hashes t [tag update] current-hackage -> current-hackage Fetched package index. Populated index cache. aeson-1.0.2.1: configure aeson-1.0.2.1: build ed25519-0.0.5.0: configure ed25519-0.0.5.0: build optparse-applicative-0.13.0.0: configure optparse-applicative-0.13.0.0: build pid1-0.1.0.0: configure pid1-0.1.0.0: build cryptohash-sha256-0.11.100.1: configure cryptohash-sha256-0.11.100.1: build store-core-0.3: configure pid1-0.1.0.0: copy/register store-core-0.3: build http-client-0.5.3.3: configure cryptohash-sha256-0.11.100.1: copy/register http-client-0.5.3.3: build Cabal-1.24.2.0: configure ed25519-0.0.5.0: copy/register Cabal-1.24.2.0: build text-metrics-0.1.0: configure store-core-0.3: copy/register text-metrics-0.1.0: build th-orphans-0.13.1: configure th-orphans-0.13.1: build text-metrics-0.1.0: copy/register optparse-applicative-0.13.0.0: copy/register th-orphans-0.13.1: copy/register optparse-simple-0.0.3: configure optparse-simple-0.0.3: build th-utilities-0.2.0.1: configure th-utilities-0.2.0.1: build optparse-simple-0.0.3: copy/register http-client-0.5.3.3: copy/register http-client-tls-0.3.4: configure th-utilities-0.2.0.1: copy/register http-client-tls-0.3.4: build store-0.3: configure store-0.3: build http-client-tls-0.3.4: copy/register store-0.3: copy/register aeson-1.0.2.1: copy/register http-conduit-2.2.3: configure http-conduit-2.2.3: build aeson-compat-0.3.6: configure aeson-compat-0.3.6: build persistent-2.6: configure persistent-2.6: build yaml-0.8.20: configure yaml-0.8.20: build binary-tagged-0.1.4.1: configure http-conduit-2.2.3: copy/register aeson-compat-0.3.6: copy/register binary-tagged-0.1.4.1: build path-0.5.9: configure path-0.5.9: build path-0.5.9: copy/register path-io-1.1.0: configure path-io-1.1.0: build binary-tagged-0.1.4.1: copy/register path-io-1.1.0: copy/register yaml-0.8.20: copy/register hpack-0.17.0: configure hpack-0.17.0: build persistent-2.6: copy/register persistent-template-2.5.1.6: configure persistent-template-2.5.1.6: build persistent-sqlite-2.6: configure persistent-sqlite-2.6: build hpack-0.17.0: copy/register Cabal-1.24.2.0: copy/register hackage-security-0.5.2.2: configure hackage-security-0.5.2.2: build persistent-template-2.5.1.6: copy/register hackage-security-0.5.2.2: copy/register persistent-sqlite-2.6: copy/register stack-1.4.0: configure [1 of 1] Compiling Main ( /private/var/folders/6w/t3g51rsj29xc0gdw5fd9j_4h0000gn/T/stack- upgrade4642/stack-1.4.0/Setup.hs, /private/var/folders/6w/t3g51rsj29xc0gdw5fd9j_4h0000gn/T/stack- upgrade4642/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o ) Linking /private/var/folders/6w/t3g51rsj29xc0gdw5fd9j_4h0000gn/T/stack- upgrade4642/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ... Configuring stack-1.4.0... stack-1.4.0: build Preprocessing library stack-1.4.0... [ 1 of 124] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 124] Compiling Hackage.Security.Client.Repository.HttpLib.HttpClient ( src/Hackage/Security/Client/Repository/HttpLib/HttpClient.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Hackage/Security/Client/Repository/HttpLib/HttpClient.o ) [ 3 of 124] Compiling Stack.Options.ScriptParser ( src/Stack/Options/ScriptParser.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Options/ScriptParser.o ) [ 4 of 124] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o ) [ 5 of 124] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) [ 6 of 124] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o ) [ 7 of 124] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o ) [ 8 of 124] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o ) [ 9 of 124] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) [ 10 of 124] Compiling Path.Extra ( src/Path/Extra.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) [ 11 of 124] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/6w/t3g51rsj29xc0gdw5fd9j_4h0000gn/T/ghc7414_0/libghc_68.dylib, 5): no suitable image found. Did find: /var/folders/6w/t3g51rsj29xc0gdw5fd9j_4h0000gn/T/ghc7414_0/libghc_68.dylib: malformed mach-o: load commands size (49000) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 26 action(s). -- While building package stack-1.4.0 using: /private/var/folders/6w/t3g51rsj29xc0gdw5fd9j_4h0000gn/T/stack- upgrade4642/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 MBPs-MacBook-Pro:~ mbp$ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 22:47:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 22:47:30 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.ddbaba3fa66fcc509335d3d1d8ac8622@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Rev(s): Phab:D1278 Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): Replying to [comment:23 mpickering]: > Is there a conceptual problem of moving the pattern match checker to the end of typechecking? There is the additional fiddlyness to make sure all pattern occurrences are checked but this seems preferable than making `-fno-code` slower for everyone. I'm not qualified to answer that, but it's a bigger problem than just pattern match checking(Maybe we should change the ticket name?). The whole point of -fno-code is to check code for errors and warnings, and many errors and warnings are currently thrown by the desugarer. I would expect that correctness is the most important concern, and that a slower, more correct -fno-code is preferable. I also expect that desugaring is in general a much less expensive operation than typechecking. Please correct me if I'm wrong! Below I give a rough enumeration of the warnings and errors that the desugarer can currently throw, and some ideas about how to proceed. The warnings listed in D1278 (comment 12, 20 months ago) as throwable by the desugarer are: * Opt_WarnIncompletePatterns (-W) * Opt_WarnIncompleteUniPatterns * Opt_WarnIncompletePatternsRecUpd * Opt_WarnIdentities * Opt_WarnOverflowedLiterals (def) * Opt_WarnEmptyEnumerations (def) * Opt_WarnInlineRuleShadowing (def) * Opt_WarnOverlappingPatterns (def) * Opt_WarnUnusedDoBind (-Wall) * Opt_WarnWrongDoBind (def) I haven't verified that this list is up to date. I have noted in brackets default warnings (def), -W warnings and -Wall warnings. The errors throwable by desugaring are a bit hard to find. Grepping and chasing errDs, I can see at least: * "A levity-polymorphic type is not allowed here:" : DsMonad.dsNoLevPoly * "Malformed constructor signature" : updateGadtResult called by DsMeta.repC * "Top level bindings for unlifted types" : DsBinds.dsTopLevelBinds * "Top level strict pattern bindings" : DsBinds.dsTopLevelBinds * "You can't mix polymorphic and unlifted bindings:" : DsExpr.ds_val_bind * "Recursive bindings for unlifted types aren't allowed:" : DsExpr.ds_val_bind * "Cannot use primitive with levity-polymorphic arguments:" : DsExpr.levPolyPrimopErr * "A lazy (~) pattern cannot bind variables of unlifted type." : Match.tidy1 Perhaps there is a list of extensions, where if none were enabled then some or all of these errors could be excluded? Say * TypeInType * MagicHash * UnboxedTuples * UnboxedSums * GADTs * BangPatterns One would have to think carefully and understand this better than I do. Then the first, easiest, solution is to unconditionally desugar with -fno- code. This has no maintenance burden and is easy to verify for correctness. D3542 implements this. Then next improvement could be reducing the work done by the desugarer in -fno-code, I intend to look at this. Finally one could implement a predicate to determine whether desugaring could produce warnings and errors, for example by checking enabled warnings and extensions, and desugar only when necessary. One could potentially move warnings/errors from desugaring to typechecking to facilitate this. This seems like a bit of a maintenance nightmare, but maybe it's not even so difficult to get them all out? Or at least everything except the TypeInType stuff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 22:47:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 22:47:47 -0000 Subject: [GHC] #13666: The fake gcc can't handle trailing backslashes In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <061.41d0c299ef753a11dd87112157d7f468@haskell.org> #13666: The fake gcc can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by niklasl): I meant the gcc wrapper in `driver/gcc`. I just didn't find a good word for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 22:48:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 22:48:32 -0000 Subject: [GHC] #13666: The gcc wrapper can't handle trailing backslashes (was: The fake gcc can't handle trailing backslashes) In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <061.81730abf8180ebc21ff97318dbf70a73@haskell.org> #13666: The gcc wrapper can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Description changed by niklasl: @@ -1,1 +1,1 @@ - The fake gcc will choke on trailing backslashes in arguments, like + The gcc wrapper will choke on trailing backslashes in arguments, like New description: The gcc wrapper will choke on trailing backslashes in arguments, like `-Iinclude\` or `-Llibs\`. `realgcc` handles them fine. It seems to insert as spurious quote or terminating a quote too early. Error message: {{{ .\test-ghc.c:1:20: fatal error: test-inc"/header.h: Invalid argument compilation terminated. }}} Found here: [https://github.com/idris-lang/Idris-dev/issues/3801] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 23:02:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 23:02:13 -0000 Subject: [GHC] #13667: Error while running stack upgrade In-Reply-To: <048.3e7cd90e3544b4ff4c770685970d14ce@haskell.org> References: <048.3e7cd90e3544b4ff4c770685970d14ce@haskell.org> Message-ID: <063.1f537bf64ede620f83f190860fb8d498@haskell.org> #13667: Error while running stack upgrade ---------------------------------+---------------------------------------- Reporter: diego.saa | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: stack ghc Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * milestone: => 8.0.2 Comment: This is a duplicate of #12479 which is fixed in 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 8 23:31:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 May 2017 23:31:51 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.78537216eb8cd3885cc4881db6c703e7@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Rev(s): Phab:D1278 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Thanks Doug, that's a useful summary. My main concern is a code hygiene. It is a fundamental design principle that we typecheck the code before desugaring so that error messages are better. By checking these things in the desugarer we might be trading good error messages for an easier implementation which I think is in general undesirable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 01:31:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 01:31:58 -0000 Subject: [GHC] #12056: Too aggressive `-w` option In-Reply-To: <042.615977cbd760a0223c1133d5e2a0fac1@haskell.org> References: <042.615977cbd760a0223c1133d5e2a0fac1@haskell.org> Message-ID: <057.f296d86ee34abd06b9201c27c04e59f5@haskell.org> #12056: Too aggressive `-w` option -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11429, #11789 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgillespie): I hacked on this a bit over the weekend. The first thing I found was this: {{{ $ ghc Main.hs -Wfoo -w -Wunrecognised-warning-flags -Wbar }}} Does not print warnings, as was noted in the ticket originally. Now if I add {{{-Wdeprecated-flags}}}, I now see all unrecognised warnings: {{{ $ ghc Main.hs -Wfoo -w -Wunrecognised-warning-flags -Wdeprecated-flags -Wbar on the commandline: warning: unrecognised warning flag: -Wfoo on the commandline: warning: unrecognised warning flag: -Wbar }}} This is most likely due to the logic to show flag warnings {{{ handleFlagWarnings :: DynFlags -> [Located String] -> IO () handleFlagWarnings dflags warns = when (wopt Opt_WarnDeprecatedFlags dflags) $ do -- It would be nicer if warns :: [Located MsgDoc], but that -- has circular import problems. let bag = listToBag [ mkPlainWarnMsg dflags loc (text warn) | L loc warn <- warns ] printOrThrowWarnings dflags bag }}} So it would seem that Option 2 above is already implemented, albeit with some restrictions. The most straightforward way to fix this would be to add `Opt_UnrecognisedWarningFlags` to `handleFlagWarnings` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 02:04:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 02:04:16 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.14cc59def08d44d9bebc9bb64b62b6a3@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Phab:D3550 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * differential: => Phab:D3550 Comment: I can't seem to figure out how to accept the new profiler output. `make accept` doesn't seem to get the job done. I get a bad exit code instead of a diff, and I can't seem to figure out how to run the test by hand (weird messages about `System.IO` not being imported). Unless Harbormaster gives something more useful, I may need some help fixing the test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 02:26:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 02:26:55 -0000 Subject: [GHC] #13658: Assertion failure on HEAD: "optCoercion changed types!" In-Reply-To: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> References: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> Message-ID: <061.858ef83e98a75b605c756effd2a660ad@haskell.org> #13658: Assertion failure on HEAD: "optCoercion changed types!" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.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:D3545 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"87ff5d4f0f812bad118600df0156f980b91191c5/ghc" 87ff5d4f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="87ff5d4f0f812bad118600df0156f980b91191c5" OptCoercion: Ensure that TyConApps match in arity Previously OptCoercion would potentially change the type of UnivCo coercions of the shape, ``` co :: TyCon arg1 ... argN ~ TyCon arg1' ... argN' ``` where the arities of the left and right applications differ. In this case we would try to zip the two argument lists, meaning that one would get truncated. One would think this could never happen since it implies we are applying the same TyCon to two different numbers of arguments. However, it does arise in the case of applications of the `Any` tycon, which arises from the typechecker (in `Data.Typeable.Internal`) where we end up with an `UnsafeCo`, ``` co :: Any (Any -> Any) Any ~ Any (Any -> Any) ``` Test Plan: Validate Reviewers: simonpj, austin, goldfire Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13658 Differential Revision: https://phabricator.haskell.org/D3545 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 02:26:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 02:26:55 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double In-Reply-To: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> References: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> Message-ID: <062.86ba482e7b911a38a5f2baf5f0981147@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Nolan Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3212 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0279b745c29213c479b61f864ca5d3d2ae76ac77/ghc" 0279b745/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0279b745c29213c479b61f864ca5d3d2ae76ac77" Make XNegativeLiterals treat -0.0 as negative 0 Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, mpickering GHC Trac Issues: #13211 Differential Revision: https://phabricator.haskell.org/D3543 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 02:26:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 02:26:55 -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.620ba32199056e5c23b3c63999ac0b22@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c5b28e06cc71cba56153e59e2958f24cdf183fb9/ghc" c5b28e06/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c5b28e06cc71cba56153e59e2958f24cdf183fb9" Add a failing test for T13644 The problem originates in TcPat.find_field_ty but I don't know how to clearnly fix it. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13644 Differential Revision: https://phabricator.haskell.org/D3535 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 02:26:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 02:26:55 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.5fe9769bf21bc7cfa281c8dc5f216c79@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3525 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"372995364c52eef15066132d7d1ea8b6760034e6/ghc" 37299536/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="372995364c52eef15066132d7d1ea8b6760034e6" Treat banged bindings as FunBinds This reworks the HsSyn representation to make banged variable patterns (e.g. !x = e) be represented as FunBinds instead of PatBinds, adding a flag to FunRhs to record the bang. Fixes #13594. Reviewers: austin, goldfire, alanz, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D3525 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 02:27:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 02:27:24 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.c21ece703103b4ecb3089dd6fa0dd326@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3525 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 02:28:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 02:28:07 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double In-Reply-To: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> References: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> Message-ID: <062.4c4727b3c84678e44fad441a99c08573@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Nolan Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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:D3212 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 Comment: Thanks Nolan! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 02:28:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 02:28:28 -0000 Subject: [GHC] #13658: Assertion failure on HEAD: "optCoercion changed types!" In-Reply-To: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> References: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> Message-ID: <061.ef9d0822cdf7faf27b789f5528b87629@haskell.org> #13658: Assertion failure on HEAD: "optCoercion changed types!" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.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:D3545 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 03:59:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 03:59:36 -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.2e752f9de5daaf0113bfc0d747f51ebd@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: | ----------------------------------+-------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Bumping off to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 05:35:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 05:35:43 -0000 Subject: [GHC] #8332: hp2ps does not escape parentheses In-Reply-To: <044.c4542af34cc7ec300ffef7e02b78e741@haskell.org> References: <044.c4542af34cc7ec300ffef7e02b78e741@haskell.org> Message-ID: <059.d09b12f0331278fbfbde350f52359ebf@haskell.org> #8332: hp2ps does not escape parentheses -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by JamesM): * status: infoneeded => closed * resolution: => fixed Comment: I believe this was fixed in #9517. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 07:20:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 07:20:22 -0000 Subject: [GHC] #13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns. In-Reply-To: <049.3862587f91a2eaa8b116ce19f5a50e51@haskell.org> References: <049.3862587f91a2eaa8b116ce19f5a50e51@haskell.org> Message-ID: <064.e3f921fc72dd6b2447a67750d170f2d0@haskell.org> #13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AaronFriel): This turns out to be easier than I expected, which makes me expect it broke something else. The issue seems to be that the desugaring for `ApplicativeDo` had no casse for a `BodyStmt`. This was absent in three places: `stmtTreeToStmts`, `stmtTreeArg`, and `slurpIndependentStmts`. By adding a pattern match on `BodyStmt` and substituting the pattern where necessary with `nlWildPatName`, the desugaring now treats `BodyStmt` everywhere as a `BindStmt` with a wildcard pattern. This seems to work properly. Here is the renamer output before: {{{#!hs Main.testCase1 m1_a1O4 m2_a1O5 = do () <- do m1_a1O4 GHC.Base.return () | () <- do m2_a1O5 GHC.Base.return () return () }}} After adding the additional case to `stmtTreeToStmts`, I found the output was this: {{{#!hs Main.testCase1 m1_a259 m2_a25a = do () <- do _ <- m1_a259 () | () <- do _ <- m2_a25a () return () }}} While this ought to optimize just as well, it was clear the body statements were being grouped into separate applicative segments. To make sure this is handled correctly, I modified `stmtTreeArg` and `slurpIndependentStmts` as well. Now the renamer outputs the same AST for both wildcard pattern binds and body statements: {{{#!hs Main.testCase1 m1_a1N9 m2_a1Na = do _ <- m1_a1N9 | _ <- m2_a1Na return () Main.testCase2 m1_a1Nf m2_a1Ng = do _ <- m1_a1Nf | _ <- m2_a1Ng return () }}} I think if I did this correctly, the patch is pushed to phabricator here: https://phabricator.haskell.org/D3552 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 07:34:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 07:34:47 -0000 Subject: [GHC] #13668: Space leak re-introduced Message-ID: <046.5e1d0230b02f31e192a890c0b5a0e0b8@haskell.org> #13668: Space leak re-introduced -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Test `perf/compiler/T9675` is failing for me on a clean HEAD {{{ =====> T9675(optasm) 1 of 1 [0, 0, 0] cd "./T9675.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc- stage2" -c T9675.hs -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output +RTS -G1 -RTS -O -fasm +RTS -V0 -tT9675.comp.stats --machine-readable -RTS"/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -c T9675.hs -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output +RTS -G1 -RTS -O -fasm +RTS -V0 -tT9675.comp.stats --machine-readable -RTS max_bytes_used value is too high: Expected T9675(optasm) max_bytes_used: 17675240 +/-15% Lower bound T9675(optasm) max_bytes_used: 15023954 Upper bound T9675(optasm) max_bytes_used: 20326526 Actual T9675(optasm) max_bytes_used: 25571248 Deviation T9675(optasm) max_bytes_used: 44.7 % peak_megabytes_allocated value is too high: Expected T9675(optasm) peak_megabytes_allocated: 63 +/-15% Lower bound T9675(optasm) peak_megabytes_allocated: 53 Upper bound T9675(optasm) peak_megabytes_allocated: 73 Actual T9675(optasm) peak_megabytes_allocated: 93 Deviation T9675(optasm) peak_megabytes_allocated: 47.6 % *** unexpected stat test failure for T9675(optasm) }}} Compiling with `-RTS -S` gives {{{ Alloc Copied Live GC GC TOT TOT Page Flts bytes bytes bytes user elap user elap 1139048 56288 158880 0.028 0.028 0.032 0.032 0 0 (Gen: 0) 1036832 99080 193448 0.018 0.018 0.052 0.052 0 0 (Gen: 0) 1036784 137552 223696 0.018 0.018 0.073 0.073 0 0 (Gen: 0) 1015208 145088 231232 0.018 0.018 0.094 0.094 0 0 (Gen: 0) 1084448 505864 636944 0.019 0.019 0.116 0.116 0 0 (Gen: 0) 1039312 660432 783288 0.020 0.020 0.137 0.137 0 0 (Gen: 0) 1377128 845976 1001624 0.020 0.020 0.159 0.159 0 0 (Gen: 0) 1707720 1168392 1352664 0.024 0.024 0.186 0.186 0 0 (Gen: 0) 2411008 1554360 1764288 0.023 0.023 0.214 0.214 0 0 (Gen: 0) 3128632 1885104 2164224 0.021 0.021 0.239 0.240 0 0 (Gen: 0) 3891928 3029560 3501264 0.025 0.025 0.271 0.272 0 0 (Gen: 0) 6618768 4554248 5412752 0.031 0.031 0.312 0.313 0 0 (Gen: 0) 8966136 5509176 6359368 0.033 0.033 0.358 0.359 0 0 (Gen: 0) 10948736 6299736 7158072 0.034 0.034 0.409 0.410 0 0 (Gen: 0) 12489360 8415312 9277728 0.043 0.044 0.466 0.468 0 0 (Gen: 0) 16486944 7800096 8662512 0.043 0.043 0.528 0.529 0 0 (Gen: 0) 15450408 9812088 10674504 0.044 0.044 0.590 0.591 0 0 (Gen: 0) 19459168 11429320 12291736 0.054 0.054 0.671 0.673 0 0 (Gen: 0) 22684384 8611624 9474040 0.046 0.046 0.745 0.747 0 0 (Gen: 0) 17026576 10661064 11523480 0.045 0.045 0.810 0.812 0 0 (Gen: 0) 21146552 9790592 10653008 0.044 0.044 0.882 0.884 0 0 (Gen: 0) 19421144 9891256 10753672 0.045 0.045 0.955 0.957 0 0 (Gen: 0) 19622512 8678360 9540776 0.042 0.042 1.026 1.028 0 0 (Gen: 0) 17212344 9845688 10708104 0.042 0.042 1.088 1.091 0 0 (Gen: 0) 19568256 9928304 10790720 0.045 0.045 1.159 1.162 0 0 (Gen: 0) 19673096 8159672 9022088 0.040 0.040 1.223 1.226 0 0 (Gen: 0) 16172824 9362616 10225032 0.039 0.039 1.277 1.280 0 0 (Gen: 0) 18536544 10809776 11672192 0.051 0.051 1.347 1.350 0 0 (Gen: 0) 21412128 15177144 16039560 0.065 0.065 1.434 1.437 0 0 (Gen: 0) 30181520 16438872 17301288 0.071 0.071 1.541 1.544 0 0 (Gen: 0) 32568088 11742016 12604432 0.053 0.053 1.633 1.636 0 0 (Gen: 0) 23285000 13139928 14002344 0.054 0.054 1.714 1.718 0 0 (Gen: 0) 26054072 15188040 16050456 0.060 0.060 1.803 1.807 0 0 (Gen: 0) 30184528 10990656 11853072 0.050 0.050 1.890 1.894 0 0 (Gen: 0) 21814064 12636584 13499000 0.050 0.050 1.961 1.965 0 0 (Gen: 0) 25295544 13754616 14812696 0.059 0.059 2.048 2.052 0 0 (Gen: 0) 27448728 16160496 17210352 0.066 0.066 2.147 2.151 0 0 (Gen: 0) 30295624 22372880 24471344 0.090 0.090 2.279 2.283 0 0 (Gen: 0) 44477824 24497712 25572240 0.092 0.092 2.431 2.436 0 0 (Gen: 0) 48692880 2937512 3436608 0.017 0.017 2.548 2.571 0 0 (Gen: 0) 1840 0.000 0.000 662,063,640 bytes allocated in the heap 334,683,080 bytes copied during GC 25,572,240 bytes maximum residency (40 sample(s)) 1,194,192 bytes maximum slop 93 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 40 colls, 0 par 1.684s 1.685s 0.0421s 0.0924s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.001s elapsed) MUT time 0.862s ( 0.885s elapsed) GC time 1.684s ( 1.685s elapsed) EXIT time 0.001s ( 0.009s elapsed) Total time 2.549s ( 2.581s elapsed) Alloc rate 767,692,191 bytes per MUT second Productivity 33.9% of total user, 34.6% of total elapsed }}} It looks as if a space leak has come back; space usage on this benchmark dropped by half when Reid fixed the `CoreTidy` leak. I don't know which commit re-introduced it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 07:59:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 07:59:47 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.b9f036fd8440a8526692b20ccfbb1aed@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Phab:D3550 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm a bit lost on this * Do INLINE functions get cost centres with `-fprof-auto`? * Do INLINABLE functions get cost centres with `-fprof-auto`? * Whatever the answer we need a `Note` in `Coverage.hs` to explain (a) the design choice and (b) how the guard implements it * The user manual should specify what happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 08:55:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 08:55:18 -0000 Subject: [GHC] #13669: Identifier "Otherwise" in guarded equation can crash a program Message-ID: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> #13669: Identifier "Otherwise" in guarded equation can crash a program -------------------------------------+------------------------------------- Reporter: vanto | 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: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In GHC.Base the identifier {{{otherwise}}} is defined as the value "True" and it helps to make guards more readable.\\ The identifier {{{otherwise}}} is not secure.\\ We can change his property easily and trick the compiler.\\ As written in GHC Base, {{{otherwise = True}}} is perfectible.\\ The problem here is to protect the "otherwise" identifier from uncontrolled access.\\ See the code below and the result of the compilation as well as the output.\\ {{{ import qualified Prelude as P otherwise :: P.Bool otherwise = P.False fun :: (P.Num a, P.Ord a) => a -> [P.Char] fun x | x P.< 0 = "down" | otherwise = "up" main :: P.IO () main = P.print (fun 7) c:\Sourcehs>ghc -Wall otherwise.hs [1 of 1] Compiling Main ( otherwise.hs, otherwise.o ) otherwise.hs:7:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for `fun': Patterns not matched: _ otherwise.hs:11:17: warning: [-Wtype-defaults] * Defaulting the following constraints to type `P.Integer' (P.Num a0) arising from a use of `fun' at otherwise.hs:11:17-21 (P.Ord a0) arising from a use of `fun' at otherwise.hs:11:17-21 * In the first argument of `P.print', namely `(fun 7)' In the expression: P.print (fun 7) In an equation for `main': main = P.print (fun 7) Linking otherwise.exe ... c:\Sourcehs>otherwise otherwise: otherwise.hs:(7,1)-(8,27): Non-exhaustive patterns in function fun }}} I propose three solutions: 1- Delete {{{otherwise}}} from GHC.Base and use only TRUE.\\ 2- Add {{{otherwise}}} as a reserved word or keyword.\\ 3- Create protected objects in Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 09:44:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 09:44:19 -0000 Subject: [GHC] #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused-pattern-binds In-Reply-To: <044.32e35139f2ee897ece4f6184af2a605d@haskell.org> References: <044.32e35139f2ee897ece4f6184af2a605d@haskell.org> Message-ID: <059.066e5bd19bed5f103c8e645fc0c55a94@haskell.org> #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused- pattern-binds -------------------------------------+------------------------------------- Reporter: exphp | 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 Simon Peyton Jones ): In [changeset:"549c8b33da25371ab1aa1818ef27fc418252e667/ghc" 549c8b3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="549c8b33da25371ab1aa1818ef27fc418252e667" Don't warn about variable-free strict pattern bindings See Trac #13646 and the new Note [Pattern bindings that bind no variables] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 09:44:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 09:44:19 -0000 Subject: [GHC] #13659: Bug report: "AThing evaluated unexpectedly tcTyVar a_alF" In-Reply-To: <049.d62cb96a1aca162d6e090009156f882b@haskell.org> References: <049.d62cb96a1aca162d6e090009156f882b@haskell.org> Message-ID: <064.7aa0774ee48c56c6966454a9c9843766@haskell.org> #13659: Bug report: "AThing evaluated unexpectedly tcTyVar a_alF" -------------------------------------+------------------------------------- Reporter: costaparas | Owner: (none) Type: bug | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6f26fe79c1952df7881f17cb504c4ecae527def7/ghc" 6f26fe7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6f26fe79c1952df7881f17cb504c4ecae527def7" Add regression test for Trac #13659 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 09:44:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 09:44:19 -0000 Subject: [GHC] #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... In-Reply-To: <046.97ac1572178bf3067f644135fab3a749@haskell.org> References: <046.97ac1572178bf3067f644135fab3a749@haskell.org> Message-ID: <061.51723531822b6ae60b290f1d9d3ae757@haskell.org> #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"43a31683acbe2f8120fbb73fe5a6fd1f5de9db80/ghc" 43a31683/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="43a31683acbe2f8120fbb73fe5a6fd1f5de9db80" Reset cc_pend_sc flag in dropDerivedCt I'd forgotten to reset this flag to True when dropping Derived constraints, which led to Trac #13662. Easily fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 09:49:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 09:49:32 -0000 Subject: [GHC] #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused-pattern-binds In-Reply-To: <044.32e35139f2ee897ece4f6184af2a605d@haskell.org> References: <044.32e35139f2ee897ece4f6184af2a605d@haskell.org> Message-ID: <059.1cb6a48e9856528f8861a1b9e8f583d5@haskell.org> #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused- pattern-binds -------------------------------------+------------------------------------- Reporter: exphp | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_compile/T13646 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => rename/should_compile/T13646 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 09:50:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 09:50:15 -0000 Subject: [GHC] #13659: Bug report: "AThing evaluated unexpectedly tcTyVar a_alF" In-Reply-To: <049.d62cb96a1aca162d6e090009156f882b@haskell.org> References: <049.d62cb96a1aca162d6e090009156f882b@haskell.org> Message-ID: <064.dc4eca1cb5586cfcacbd1b1854802964@haskell.org> #13659: Bug report: "AThing evaluated unexpectedly tcTyVar a_alF" -------------------------------------+------------------------------------- Reporter: costaparas | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 09:51:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 09:51:09 -0000 Subject: [GHC] #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... In-Reply-To: <046.97ac1572178bf3067f644135fab3a749@haskell.org> References: <046.97ac1572178bf3067f644135fab3a749@haskell.org> Message-ID: <061.01f2abd9ffbe07d2c26310eeeb8f0e22@haskell.org> #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T13662 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => indexed-types/should_compile/T13662 Comment: Thanks for the report. Worth merging when convenient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 09:51:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 09:51:17 -0000 Subject: [GHC] #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... In-Reply-To: <046.97ac1572178bf3067f644135fab3a749@haskell.org> References: <046.97ac1572178bf3067f644135fab3a749@haskell.org> Message-ID: <061.eb2b1f20e621c11aa84dfe823143d0bc@haskell.org> #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T13662 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 09:51:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 09:51:57 -0000 Subject: [GHC] #13568: Name is reported as ambiguous and not in scope In-Reply-To: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> References: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> Message-ID: <064.b3ec35cfb486d2bbdb01837fb2300948@haskell.org> #13568: Name is reported as ambiguous and not in scope -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3547 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: D3547 => Phab:D3547 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 11:58:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 11:58:23 -0000 Subject: [GHC] #13655: Spurious untouchable type variable in connection with rank-2 type and constraint family In-Reply-To: <046.fa7a964aa5cdaeab62013eaa1b08a1df@haskell.org> References: <046.fa7a964aa5cdaeab62013eaa1b08a1df@haskell.org> Message-ID: <061.d3cca6682c4e68edf53dadb974fcdd1d@haskell.org> #13655: Spurious untouchable type variable in connection with rank-2 type and constraint family -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 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 simonpj): I can see that it seems odd. Imagine that you wrote {{{ f :: (forall b . F a b => T b c) -> a f _ = undefined g :: (forall bb . F aa bb => T bb cc) -> aa g x = f x }}} You'd expect that to work: the two signatures are the same. But in the call in g's rhs we have: {{{ Expected type of f's arg: forall b. F a0 b => T b c0) Actual type of x (after instantation): T bb0 cc plus a "wanted" constraint: F aa bb0 }}} where the "0" things are unification variables. Of course this is easily soluble by unifying `bb0=b, a0=aa, c0=cc`. The `a0=aa` is enforced by the result type of the call to `(f x)` but the other two are not. And the "untouchable" bit is because we don't unify under a given equality constraint, or something that might be a given equality, like `(F a0 b)`. (Why: see the OutsideIn paper.) The ambiguity check, which is failing here, is precisely implementing this reasoning. In short: it's all behaving as designed. The error message is unhelpful, but it IS a subtle issue. I wish I could be more helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 11:59:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 11:59:07 -0000 Subject: [GHC] #13669: Identifier "Otherwise" in guarded equation can crash a program In-Reply-To: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> References: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> Message-ID: <059.2c630e93dc702803b8c665253462e4f2@haskell.org> #13669: Identifier "Otherwise" in guarded equation can crash a program -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): You can replace `otherwise` by `let` which is a keyword ;) (The same is true of `True`: `pattern True = P.False`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 13:04:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 13:04:50 -0000 Subject: [GHC] #13669: Identifier "Otherwise" in guarded equation can crash a program In-Reply-To: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> References: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> Message-ID: <059.ff33a86dd3ccc388163d79ca9089ba92@haskell.org> #13669: Identifier "Otherwise" in guarded equation can crash a program -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): You could replace `otherwise` in the ticket description with any other identifier provided by `Prelude` and the same argument will apply. However, I really don't think this is an argument for adding complexity to the language. In the case that `Prelude` is imported unqualified the user will be faced with an ambiguity error and there will be no confusion. If they really do import `Prelude` qualified and define or otherwise import another `otherwise`, then who are we to say they shouldn't? I've never heard of anyone complain of being confused by `otherwise`, or any other `Prelude`-defined identifier, not behaving as expected for this reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 13:26:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 13:26:41 -0000 Subject: [GHC] #13668: Space leak re-introduced In-Reply-To: <046.5e1d0230b02f31e192a890c0b5a0e0b8@haskell.org> References: <046.5e1d0230b02f31e192a890c0b5a0e0b8@haskell.org> Message-ID: <061.43dc122aca6e3ec8da76a79ae575f2f0@haskell.org> #13668: Space leak re-introduced -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I know precisely which commit is at fault. It was, {{{ commit b3da6a6c3546562d5c5e83b8af5d3fd04c07e0c1 Author: Ben Gamari Date: Tue May 2 11:36:47 2017 -0400 CoreTidy: Don't seq unfoldings Previously we would force uf_is_value and friends to ensure that we didn't retain a reference to the pre-tidying template, resulting in a space leak. Instead, we now just reinitialize these fields (despite the fact that they should not have changed). This may result in a bit more computation, but most of the time we won't ever evaluate them anyways, so the damage shouldn't be so bad. See #13564. }}} Apparently this commit wasn't quite enough. I'm not sure how this didn't show up when I first tested this. I suppose we probably ought to revert for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 13:35:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 13:35:13 -0000 Subject: [GHC] #13669: Identifier "Otherwise" in guarded equation can crash a program In-Reply-To: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> References: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> Message-ID: <059.3ebe8cd90474654d33bf2b3a70cf4e9b@haskell.org> #13669: Identifier "Otherwise" in guarded equation can crash a program -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm with @bgamari here -- I see nothing unsettling about the original program. Note that GHC correctly identifies the pattern-match as non- exhaustive. Regardless of our opinions, writing up a [https://github.com/ghc-proposals /ghc-proposals proposal] is the official way to suggestions changes to the language GHC compiles. You may wish to do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 13:58:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 13:58:03 -0000 Subject: [GHC] #13668: Space leak re-introduced In-Reply-To: <046.5e1d0230b02f31e192a890c0b5a0e0b8@haskell.org> References: <046.5e1d0230b02f31e192a890c0b5a0e0b8@haskell.org> Message-ID: <061.b9f390635a848fb1d0c1d080457fa25b@haskell.org> #13668: Space leak re-introduced -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): If we `seqExpr` the tidied template expression we win back most, but not all, of the benefit. It still leaves a few percent reduction in `max_bytes_used` on the table relative to `seqUnfolding` the new unfolding, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 14:06:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 14:06:33 -0000 Subject: [GHC] #13668: Space leak re-introduced In-Reply-To: <046.5e1d0230b02f31e192a890c0b5a0e0b8@haskell.org> References: <046.5e1d0230b02f31e192a890c0b5a0e0b8@haskell.org> Message-ID: <061.234a3b215bc1ec9d92d9f1a91579e93e@haskell.org> #13668: Space leak re-introduced -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13564 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #13564 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 15:50:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 15:50:51 -0000 Subject: [GHC] #13669: Identifier "Otherwise" in guarded equation can crash a program In-Reply-To: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> References: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> Message-ID: <059.7a167d718f51487d807fe198b1d3c869@haskell.org> #13669: Identifier "Otherwise" in guarded equation can crash a program -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Reply to bgamari:\\ > I've never heard of anyone complain of being confused by otherwise, or any other Prelude-defined identifier, not behaving as expected for this reason.\\ It's because you've never worried about the problem! There is a beginning for everything. Golfire said:\\ > writing up a ​proposal is the official way to suggestions changes to the language GHC compiles.\\ Ben, tells goldfire my problem with the proposals, please.\\ Reply to golfire:\\ > Regardless of our opinions\\ Why do you hide your opinion in this ticket? Reply to bgamari and goldfire:\\ I know you will not do anything. You follow your way and you do not ask yourself the right questions. Haskell is still a language for research. Do not neglect what others have done in the past with other languages even if they are not functional language.\\ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 16:09:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 16:09:05 -0000 Subject: [GHC] #13670: Improving Type Error Messages Message-ID: <049.a5addc0df97fe0916cadf9848effc25a@haskell.org> #13670: Improving Type Error Messages -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was reading through https://medium.com/@sjsyrek/some-notes-on-haskell- pedagogy-de43281b1a5c the other day, and noticed a pretty gnarly error message produced by the following code {{{ {-# LANGUAGE InstanceSigs #-} data List a = EmptyList | ListElement a (List a) deriving Show instance Functor List where fmap :: (a -> b) -> List a -> List b fmap f xs = ListElement (f x) xs }}} {{{ list.hs:8:49: error: • Couldn't match type ‘a’ with ‘b’ ‘a’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at list.hs:7:11 ‘b’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at list.hs:7:11 Expected type: List b Actual type: List a • In the second argument of ‘ListElement’, namely ‘xs’ In the expression: ListElement (f x) xs In an equation for ‘fmap’: fmap f (ListElement x xs) = ListElement (f x) xs • Relevant bindings include xs :: List a (bound at list.hs:8:25) x :: a (bound at list.hs:8:23) f :: a -> b (bound at list.hs:8:8) fmap :: (a -> b) -> List a -> List b (bound at list.hs:8:3) }}} I think there are a few things we could do better here. 1. The biggest issue IMO is that the key piece of information, the mismatch between `List a` and `List b` is stuck right in the middle of the error message, obscured by GHC's attempt to be helpful by pointing out the provenance of `a` and `b`. The mismatch should be front and center, so users see it without having to dig through a wall of text! I think just swapping the order of the expected/actual types and the tyvar provenance would be a big improvement. {{{ list.hs:8:49: error: • Couldn't match type ‘a’ with ‘b’ Expected type: List b Actual type: List a ‘a’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at list.hs:7:11 ‘b’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at list.hs:7:11 • In the second argument of ‘ListElement’, namely ‘xs’ In the expression: ListElement (f x) xs In an equation for ‘fmap’: fmap f (ListElement x xs) = ListElement (f x) xs • Relevant bindings include xs :: List a (bound at list.hs:8:25) x :: a (bound at list.hs:8:23) f :: a -> b (bound at list.hs:8:8) fmap :: (a -> b) -> List a -> List b (bound at list.hs:8:3) }}} But there's more we can do! 2. The rust compiler does this very nice thing where it attaches helpful notes that relate to the error to other source spans. The benefit here is that editors can then '''highlight''' multiple spans to produce a nicer visual. In our case, the provenance of the tyvars feels like such a helpful note, rather than a core part of the error message. {{{ list.hs:8:49: error: • Couldn't match type ‘a’ with ‘b’ Expected type: List b Actual type: List a • In the second argument of ‘ListElement’, namely ‘xs’ In the expression: ListElement (f x) xs In an equation for ‘fmap’: fmap f (ListElement x xs) = ListElement (f x) xs • Relevant bindings include xs :: List a (bound at list.hs:8:25) x :: a (bound at list.hs:8:23) f :: a -> b (bound at list.hs:8:8) fmap :: (a -> b) -> List a -> List b (bound at list.hs:8:3) list.hs:7:11: note: • ‘a’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b list.hs:7:11: note: • ‘b’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b }}} Now the editor will highlight the ill-typed `xs` in red, with a popup that just provides the error; and the type for `fmap` in another color (usually blue it seems), with a popup that explains the provenance of the tyvars. (We might also want to separate the "relevant bindings" into a helpful note.) I believe many linter packages for editors are already setup to distinguish between errors and helpful notes, so this would be a really simple and free improvement. 3. Finally, I've always liked how GHC helpfully explains the context in which the error occurs ("in the second argument ... in the expression ... etc"), but I think we've been outclassed by other compilers that just print the offending line with the error underlined. We could adopt this strategy. (Related: it seems redundant to provide this context if the user is inside their editor rather than at the command-line. What if we had a flag `--editor-mode` to prune such redundancies?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 16:11:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 16:11:57 -0000 Subject: [GHC] #13670: Improving Type Error Messages In-Reply-To: <049.a5addc0df97fe0916cadf9848effc25a@haskell.org> References: <049.a5addc0df97fe0916cadf9848effc25a@haskell.org> Message-ID: <064.1be5a0066f8280905806beb5c7f0658a@haskell.org> #13670: Improving Type Error Messages -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeErrorMessages Comment: All good ideas. (1) is particularly easy to do. Any volunteers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 16:12:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 16:12:20 -0000 Subject: [GHC] #13671: Core lint error with PatternSynonyms and undefined Message-ID: <051.51c868349e622e97e157b502ef38c1f2@haskell.org> #13671: Core lint error with PatternSynonyms and undefined -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've submitted quite a few Core Lint errors lately, I don't have access to GHC HEAD so ignore this ticket if this has already been resolved {{{#!hs {-# Options_GHC -dcore-lint #-} {-# Language ViewPatterns, PatternSynonyms #-} import Data.Bifunctor.Fix import Data.Bifunctor.Tannen newtype ZipList a = ZL { getZipList :: Fix (Tannen Maybe (,)) a } pattern Nil :: ZipList a pattern Nil = ZL (In (Tannen Nothing)) infixr 5 ::: pattern (:::) :: a -> ZipList a -> ZipList a pattern a:::as <- ZL (In (Tannen (undefined -> (a, as)))) where a:::as = undefined }}} `↑` works fine without `-dcore-lint` but fails with it. Works fine if `undefined -> (a, as)` is replaced with `let x = x in x -> (a, as)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 16:17:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 16:17:42 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.a9215eca5d4e3dea68f773f9c3b331d3@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13122 Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906,#13670 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #8809,#10073,#10179,#12906 => #8809,#10073,#10179,#12906,#13670 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 16:18:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 16:18:41 -0000 Subject: [GHC] #13672: Pattern match on LHS of pattern synonym declaration Message-ID: <051.e9f1b3eec9bb917b1181b9c3499aeae0@haskell.org> #13672: Pattern match on LHS of pattern synonym declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Changing `ZipList` to a newtype {{{#!hs import Data.Bifunctor.Fix import Data.Bifunctor.Tannen type ZipList = Fix (Tannen Maybe (,)) pattern Nil :: ZipList a pattern Nil = In (Tannen Nothing) infixr 5 ::: pattern (:::) :: a -> ZipList a -> ZipList a pattern a:::as = In (Tannen (Just (as, a))) }}} works fine for the `Nil` pattern synonym (it remains implicitly bidirectional) {{{#!hs newtype ZipList a = ZL (Fix (Tannen Maybe (,)) a) pattern Nil :: ZipList a pattern Nil = ZL (In (Tannen Nothing)) }}} but `(:::)` needs to be explicitly bidirectional {{{#!hs infixr 5 ::: pattern (:::) :: a -> ZipList a -> ZipList a pattern a:::as <- ZL (In (Tannen (Just (ZL -> as, a)))) where a:::ZL as = ZL (In (Tannen (Just (as, a)))) }}} ---- I would like to write it as {{{#!hs pattern (:::) :: a -> ZipList a -> ZipList a pattern a:::ZL as = ZL (In (Tannen (Just (as, a)))) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 16:24:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 16:24:57 -0000 Subject: [GHC] #13670: Improving Type Error Messages In-Reply-To: <049.a5addc0df97fe0916cadf9848effc25a@haskell.org> References: <049.a5addc0df97fe0916cadf9848effc25a@haskell.org> Message-ID: <064.26b30fbb95196a7789ca2fe6bee2f1f2@haskell.org> #13670: Improving Type Error Messages -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Finally, I've always liked how GHC helpfully explains the context in which the error occurs ("in the second argument ... in the expression ... etc"), but I think we've been outclassed by other compilers that just print the offending line with the error underlined. We could adopt this strategy. Thanks to @Rufflewind GHC 8.2 does precisely this. e.g., {{{ hi.hs:9:33: error: • Couldn't match type ‘a’ with ‘b’ ‘a’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at hi.hs:8:11-38 ‘b’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at hi.hs:8:11-38 Expected type: List b Actual type: List a • In the second argument of ‘ListElement’, namely ‘xs’ In the expression: ListElement (f x) xs In an equation for ‘fmap’: fmap f xs = ListElement (f x) xs • Relevant bindings include xs :: List a (bound at hi.hs:9:10) f :: a -> b (bound at hi.hs:9:8) fmap :: (a -> b) -> List a -> List b (bound at hi.hs:9:3) | 9 | fmap f xs = ListElement (f x) xs | ^^ }}} (with color even!) Arguably the "in the second argument of ..." text can now be dropped, but this won't be done for 8.2. > (Related: it seems redundant to provide this context if the user is inside their editor rather than at the command-line. What if we had a flag --editor-mode to prune such redundancies?) I think we are now getting into the problem of more structured (in the machine-readable sense) error messages. I suggest an approach to attacking this problem in ticket:8809#comment:3. Recently this project has been un- stuck by Alfredo Di Napoli, who has been doing some great work reconciling GHC's `Pretty` module with the upstream `pretty` library. This will allow us to use `pretty`'s annotated pretty-printer to embed Haskell values in error messages, giving consumers the ability to pick out exactly the details that they want to show. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 16:30:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 16:30:07 -0000 Subject: [GHC] #13390: Strict literal float-out during desugaring regresses T1969 at -O0 In-Reply-To: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> References: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> Message-ID: <061.388d3d634a990c1d3022fd37f3d85e20@haskell.org> #13390: Strict literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I tried the example in the Description to try to get to the bottom of this. With HEAD and no -O I get {{{ -------------- Class-op selectors for c,d,e ---------- c :: forall a. C a => a -> String [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=, RULES: Built in rule for c: "Class op c"] c = \ (@ a_aop) (v_B1 :: C a_aop) -> case v_B1 of v_B1 { T1969.C:C v_B2 v_B3 v_B4 -> v_B2 } -- .....and similarly for 'd', 'e' -------------- Default methods for d,e ---------- T1969.$dmd :: forall a. C a => a -> String [GblId, Arity=2, Caf=NoCafRefs] T1969.$dmd = \ (@ a_aop) ($dC_aT1 :: C a_aop) (x_aoq :: a_aop) -> c @ a_aop $dC_aT1 x_aoq -- .....and similary for 'e' -------------- Dictionary for (C A1) ----------- $cc_rUv :: A1 -> String [GblId, Arity=1] $cc_rUv = \ (ds_dUq :: A1) -> case ds_dUq of { A1 -> GHC.CString.unpackCString# "A1"# } T1969.$fCA1 [InlPrag=CONLIKE] :: C A1 [GblId[DFunId]] T1969.$fCA1 = T1969.C:C @ A1 $cc_rUv $cc_rUv $cc_rUv }}} This looks absolutely fine to me. What is the problem we are trying to solve here? Maybe it's solved already? (In which case can we just make sure that T1969 at `-O0` is a regression test?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 16:33:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 16:33:18 -0000 Subject: [GHC] #13673: Core lint error with defer-typed-holes Message-ID: <051.478eea57a818aa5a79c3633c800e1f0c@haskell.org> #13673: Core lint error with defer-typed-holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Another Core Lint error {{{#!hs {-# Options_GHC -dcore-lint -fdefer-typed-holes #-} {-# Language ViewPatterns, PatternSynonyms, GeneralizedNewtypeDeriving, DeriveTraversable #-} import Data.Bifunctor.Fix import Data.Bifunctor.Tannen import Test.QuickCheck import Test.QuickCheck.Function import Control.Applicative newtype ZL a = ZL { getZL :: Fix (Tannen Maybe (,)) a } deriving (Eq, Ord, Read, Show, Functor, Applicative, Foldable, Traversable) fromList :: [a] -> ZL a fromList [] = Nil fromList (x:xs) = x:::fromList xs pattern Nil :: ZL a pattern Nil = ZL (In (Tannen Nothing)) foo :: ZL a -> Maybe (a, ZL a) foo (ZL (In (Tannen (Just (as, a))))) = Just (a, ZL as) infixr 5 ::: pattern (:::) :: a -> ZL a -> ZL a pattern a:::as <- ZL (In (Tannen (Just (ZL -> as, a)))) where a:::ZL as = ZL (In (Tannen (Just (as, a)))) u (Fn f) as bs = let (xs, ys) = (ZipList as, ZipList bs) in getZipList (liftA2 f xs ys) == toList (liftA2 f (fromList as) (fromList bs)) }}} unfortunately I don't have time to reduce it -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 16:33:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 16:33:51 -0000 Subject: [GHC] #13673: Core lint error with defer-typed-holes In-Reply-To: <051.478eea57a818aa5a79c3633c800e1f0c@haskell.org> References: <051.478eea57a818aa5a79c3633c800e1f0c@haskell.org> Message-ID: <066.7b4bcae9da6a2c036664cc8140ad07f1@haskell.org> #13673: Core lint error with defer-typed-holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "tQdw.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 16:34:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 16:34:55 -0000 Subject: [GHC] #13671: Core lint error with PatternSynonyms and undefined In-Reply-To: <051.51c868349e622e97e157b502ef38c1f2@haskell.org> References: <051.51c868349e622e97e157b502ef38c1f2@haskell.org> Message-ID: <066.116236c1df7a3f4ed0b9aaeca023e8db@haskell.org> #13671: Core lint error with PatternSynonyms and undefined -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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 Iceland_jack): * Attachment "tQdW.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 16:35:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 16:35:33 -0000 Subject: [GHC] #13671: Core lint error with PatternSynonyms and undefined In-Reply-To: <051.51c868349e622e97e157b502ef38c1f2@haskell.org> References: <051.51c868349e622e97e157b502ef38c1f2@haskell.org> Message-ID: <066.3b990224cbce7b1e5a5e51adb6a1dad3@haskell.org> #13671: Core lint error with PatternSynonyms and undefined -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: worksforme | 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 simonpj): * status: new => closed * resolution: => worksforme Comment: I don't know precisely which `Data.Bifunctor.Fix` etc you mean, but I tried this {{{ {-# Options_GHC -dcore-lint #-} {-# Language ViewPatterns, PatternSynonyms #-} module T13671 where newtype ZipList a = ZL { getZipList :: Fix (Tannen Maybe (,)) a } pattern Nil :: ZipList a pattern Nil = ZL (In (Tannen Nothing)) infixr 5 ::: pattern (:::) :: a -> ZipList a -> ZipList a pattern a:::as <- ZL (In (Tannen (undefined -> (a, as)))) where a:::as = undefined newtype Tannen f p a b = Tannen { runTannen :: f (p a b) } newtype Fix p a = In { out :: p (Fix p a) a } }}} That compiles fine with `-dcore-lint`. So I'll close. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 16:43:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 16:43:36 -0000 Subject: [GHC] #13673: Core lint error with defer-typed-holes In-Reply-To: <051.478eea57a818aa5a79c3633c800e1f0c@haskell.org> References: <051.478eea57a818aa5a79c3633c800e1f0c@haskell.org> Message-ID: <066.36c45cbddec150498160eb67324817e2@haskell.org> #13673: Core lint error with defer-typed-holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If you, or someone else, could make it self contained, it'd be very helpful. May well be fixed already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 16:49:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 16:49:46 -0000 Subject: [GHC] #13390: Strict literal float-out during desugaring regresses T1969 at -O0 In-Reply-To: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> References: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> Message-ID: <061.fbb15805d913378986075406afce8185@haskell.org> #13390: Strict literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Simon, HEAD is fine. The trouble shows up with the string literal floating patch, which has not been merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 17:39:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 17:39:16 -0000 Subject: [GHC] #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. In-Reply-To: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> References: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> Message-ID: <064.4e24204a1f06fe252ef336ce1c2baa64@haskell.org> #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | RebindableSyntax 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 bgamari): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 18:44:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 18:44:37 -0000 Subject: [GHC] #13672: Pattern match on LHS of pattern synonym declaration In-Reply-To: <051.e9f1b3eec9bb917b1181b9c3499aeae0@haskell.org> References: <051.e9f1b3eec9bb917b1181b9c3499aeae0@haskell.org> Message-ID: <066.f21422a37166b2f30c343453660c08b0@haskell.org> #13672: Pattern match on LHS of pattern synonym declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12203 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12203 Comment: I'm closing this as a duplicate of #12203, since that ticket asks for the same thing (albeit with a different motivating example). I'll add this example to #12203 for posterity's sake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 18:47:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 18:47:39 -0000 Subject: [GHC] #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym In-Reply-To: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> References: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> Message-ID: <060.32162664a528750a7dbd53ac3f574a1f@haskell.org> #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13672 Comment: Another example from #13672 which requires this functionality: {{{#!hs newtype Tannen f p a b = Tannen { runTannen :: f (p a b) } newtype Fix p a = In { out :: p (Fix p a) a } newtype ZipList a = ZL (Fix (Tannen Maybe (,)) a) pattern Nil :: ZipList a pattern Nil = ZL (In (Tannen Nothing)) pattern (:::) :: a -> ZipList a -> ZipList a pattern a:::ZL as = ZL (In (Tannen (Just (as, a)))) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 18:52:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 18:52:32 -0000 Subject: [GHC] #13673: Core lint error with defer-typed-holes In-Reply-To: <051.478eea57a818aa5a79c3633c800e1f0c@haskell.org> References: <051.478eea57a818aa5a79c3633c800e1f0c@haskell.org> Message-ID: <066.1d5faa92d39644b475c68e82c6646bbc@haskell.org> #13673: Core lint error with defer-typed-holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: I can't reproduce this on GHC 8.0.2 or 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 19:24:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 19:24:29 -0000 Subject: [GHC] #13674: GHC doesn't discharge heterogenous equality constraint when it ought to Message-ID: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> #13674: GHC doesn't discharge heterogenous equality constraint when it ought to -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's some code, reduced from an example in https://github.com/ekmett/constraints/issues/55: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} import Data.Proxy import GHC.Exts (Constraint) import GHC.TypeLits import Unsafe.Coerce (unsafeCoerce) data Dict :: Constraint -> * where Dict :: a => Dict a infixr 9 :- newtype a :- b = Sub (a => Dict b) -- | Given that @a :- b@, derive something that needs a context @b@, using the context @a@ (\\) :: a => (b => r) -> (a :- b) -> r r \\ Sub Dict = r newtype Magic n = Magic (KnownNat n => Dict (KnownNat n)) magic :: forall n m o. (Integer -> Integer -> Integer) -> (KnownNat n, KnownNat m) :- KnownNat o magic f = Sub $ unsafeCoerce (Magic Dict) (natVal (Proxy :: Proxy n) `f` natVal (Proxy :: Proxy m)) type family Lcm :: Nat -> Nat -> Nat where axiom :: forall a b. Dict (a ~ b) axiom = unsafeCoerce (Dict :: Dict (a ~ a)) lcmNat :: forall n m. (KnownNat n, KnownNat m) :- KnownNat (Lcm n m) lcmNat = magic lcm lcmIsIdempotent :: forall n. Dict (n ~ Lcm n n) lcmIsIdempotent = axiom newtype GF (n :: Nat) = GF Integer x :: GF 5 x = GF 3 y :: GF 5 y = GF 4 foo :: (KnownNat m, KnownNat n) => GF m -> GF n -> GF (Lcm m n) foo m@(GF x) n@(GF y) = GF $ (x*y) `mod` (lcm (natVal m) (natVal n)) bar :: (KnownNat m) => GF m -> GF m -> GF m bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) }}} Compiling this (with either GHC 8.0.1, 8.0.2, 8.2.1, or HEAD) gives you a downright puzzling type error: {{{ $ /opt/ghc/head/bin/ghci Bug.hs GHCi, version 8.3.20170509: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:54:21: error: • Couldn't match type ‘m’ with ‘Lcm m m’ ‘m’ is a rigid type variable bound by the type signature for: bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m at Bug.hs:53:1-44 Expected type: GF m Actual type: GF (Lcm m m) • In the first argument of ‘(-)’, namely ‘foo x y’ In the expression: foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) In an equation for ‘bar’: bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) • Relevant bindings include y :: GF m (bound at Bug.hs:54:17) x :: GF m (bound at Bug.hs:54:6) bar :: GF m -> GF m -> GF m (bound at Bug.hs:54:1) | 54 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) | ^^^^^^^ Bug.hs:54:31: error: • Could not deduce: m ~ Lcm m m from the context: m ~ Lcm m m bound by a type expected by the context: m ~ Lcm m m => GF m at Bug.hs:54:31-85 ‘m’ is a rigid type variable bound by the type signature for: bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m at Bug.hs:53:1-44 Expected type: GF m Actual type: GF (Lcm m m) • In the first argument of ‘(\\)’, namely ‘foo y x’ In the first argument of ‘(\\)’, namely ‘foo y x \\ lcmNat @m @m’ In the second argument of ‘(-)’, namely ‘foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m)’ • Relevant bindings include y :: GF m (bound at Bug.hs:54:17) x :: GF m (bound at Bug.hs:54:6) bar :: GF m -> GF m -> GF m (bound at Bug.hs:54:1) | 54 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) | ^^^^^^^ }}} In particular, I'd like to emphasize this part: {{{ • Could not deduce: m ~ Lcm m m from the context: m ~ Lcm m m }}} Wat!? Surely, GHC can deduce `m ~ Lcm m m` from `m ~ Lcm m m`? I decided to flip on `-fprint-explicit-kinds` and see if there was some other issue lurking beneath the surface: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs -fprint-explicit-kinds GHCi, version 8.2.0.20170505: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:54:21: error: • Couldn't match type ‘m’ with ‘Lcm m m’ ‘m’ is a rigid type variable bound by the type signature for: bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m at Bug.hs:53:1-44 Expected type: GF m Actual type: GF (Lcm m m) • In the first argument of ‘(-)’, namely ‘foo x y’ In the expression: foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) In an equation for ‘bar’: bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) • Relevant bindings include y :: GF m (bound at Bug.hs:54:17) x :: GF m (bound at Bug.hs:54:6) bar :: GF m -> GF m -> GF m (bound at Bug.hs:54:1) | 54 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) | ^^^^^^^ Bug.hs:54:31: error: • Could not deduce: (m :: Nat) ~~ (Lcm m m :: Nat) from the context: m ~ Lcm m m bound by a type expected by the context: m ~ Lcm m m => GF m at Bug.hs:54:31-85 ‘m’ is a rigid type variable bound by the type signature for: bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m at Bug.hs:53:1-44 Expected type: GF m Actual type: GF (Lcm m m) • In the first argument of ‘(\\)’, namely ‘foo y x’ In the first argument of ‘(\\)’, namely ‘foo y x \\ lcmNat @m @m’ In the second argument of ‘(-)’, namely ‘foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m)’ • Relevant bindings include y :: GF m (bound at Bug.hs:54:17) x :: GF m (bound at Bug.hs:54:6) bar :: GF m -> GF m -> GF m (bound at Bug.hs:54:1) | 54 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) | ^^^^^^^ }}} Well, not a whole lot changed. We now have this, slightly more specific error instead: {{{ • Could not deduce: (m :: Nat) ~~ (Lcm m m :: Nat) from the context: m ~ Lcm m m }}} Huh, this is flummoxing. Surely `(m :: Nat) ~~ (Lcm m m :: Nat)` ought to be the same thing as `m ~ Lcm m m`, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 19:40:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 19:40:32 -0000 Subject: [GHC] #11272: Overloaded state-monadic function is not specialised In-Reply-To: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> References: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> Message-ID: <067.412f93a2aec78fcd393b7844bd8a1019@haskell.org> #11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3561 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D3561 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 20:23:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 20:23:05 -0000 Subject: [GHC] #13675: Binary.get(TyClDecl): ForeignType Message-ID: <045.a58aeb2a4dfc7f06891fc02dfa70f144@haskell.org> #13675: Binary.get(TyClDecl): ForeignType -------------------------------------+------------------------------------- Reporter: Neidon | 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: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Binary.get(TyClDecl): ForeignType CallStack (from HasCallStack): error, called at compiler/iface/IfaceSyn.hs:1530:18 in ghc:IfaceSyn }}} Steps to reproduce: 1. Download a 640 Mb zip archive from https://drive.google.com/file/d/0B0Jnpz9ldbuHZHI4NFB3XzBucVU/view?usp=sharing. Unpack it. Inside are two directories: * `home_stack` (`du -s` reports size 2691340 Kb) * `cardano-sl` (`du -s` reports size 639820 Kb) 2. Move `home_stack` to `~/.stack`, deleting the original directory if it exists. 3. Move `cardano-sl` to `~/repos/cardano-sl`. 4. `cd` to `~/repos/cardano-sl`. 5. Issue `stack build --flag cardano-sl:with-explorer --ghc-options -fprint-potential-instances`. (Should also reproduce with `stack build` alone, but the following output is from the longer command.) Output on my machine: {{{ Cloning into '/home/ser/repos/cardano-sl/.stack- work/downloaded/GcgJH7g69OEv'... remote: Counting objects: 20, done. remote: Total 20 (delta 0), reused 0 (delta 0), pack-reused 20 Unpacking objects: 100% (20/20), done. Cloning into '/home/ser/repos/cardano-sl/.stack- work/downloaded/ENyDIhK06WOU'... remote: Counting objects: 1297, done. remote: Total 1297 (delta 0), reused 0 (delta 0), pack-reused 1297 Receiving objects: 100% (1297/1297), 260.82 KiB | 402.00 KiB/s, done. Resolving deltas: 100% (605/605), done. Cloning into '/home/ser/repos/cardano-sl/.stack- work/downloaded/TD50yXVIvxc9'... remote: Counting objects: 1740, done. remote: Total 1740 (delta 0), reused 0 (delta 0), pack-reused 1740 Receiving objects: 100% (1740/1740), 300.55 KiB | 0 bytes/s, done. Resolving deltas: 100% (988/988), done. Cloning into '/home/ser/repos/cardano-sl/.stack- work/downloaded/XNE9sXB7eSlZ'... remote: Counting objects: 782, done. remote: Total 782 (delta 0), reused 0 (delta 0), pack-reused 782 Receiving objects: 100% (782/782), 361.32 KiB | 352.00 KiB/s, done. Resolving deltas: 100% (496/496), done. Cloning into '/home/ser/repos/cardano-sl/.stack-work/downloaded/SOLx- DoyBtx1'... remote: Counting objects: 911, done. remote: Total 911 (delta 0), reused 0 (delta 0), pack-reused 911 Receiving objects: 100% (911/911), 466.06 KiB | 754.00 KiB/s, done. Resolving deltas: 100% (346/346), done. Cloning into '/home/ser/repos/cardano-sl/.stack- work/downloaded/GCp_IHcTNp9P'... remote: Counting objects: 713, done. remote: Total 713 (delta 0), reused 0 (delta 0), pack-reused 713 Receiving objects: 100% (713/713), 179.48 KiB | 0 bytes/s, done. Resolving deltas: 100% (312/312), done. Cloning into '/home/ser/repos/cardano-sl/.stack- work/downloaded/Lyd_i8-L91FJ'... remote: Counting objects: 161, done. remote: Total 161 (delta 0), reused 0 (delta 0), pack-reused 161 Receiving objects: 100% (161/161), 36.19 KiB | 0 bytes/s, done. Resolving deltas: 100% (82/82), done. Cloning into '/home/ser/repos/cardano-sl/.stack- work/downloaded/CiIBoLUguKbQ'... remote: Counting objects: 2556, done. remote: Compressing objects: 100% (36/36), done. remote: Total 2556 (delta 7), reused 1 (delta 1), pack-reused 2518 Receiving objects: 100% (2556/2556), 678.84 KiB | 1.01 MiB/s, done. Resolving deltas: 100% (1511/1511), done. Cloning into '/home/ser/repos/cardano-sl/.stack- work/downloaded/ZdBBqCDMftE9'... remote: Counting objects: 1463, done. remote: Compressing objects: 100% (13/13), done. remote: Total 1463 (delta 3), reused 0 (delta 0), pack-reused 1446 Receiving objects: 100% (1463/1463), 518.63 KiB | 975.00 KiB/s, done. Resolving deltas: 100% (585/585), done. Cloning into '/home/ser/repos/cardano-sl/.stack- work/downloaded/_k2aE31sX6Xe'... remote: Counting objects: 1137, done. remote: Total 1137 (delta 0), reused 0 (delta 0), pack-reused 1137 Receiving objects: 100% (1137/1137), 210.59 KiB | 360.00 KiB/s, done. Resolving deltas: 100% (528/528), done. Cloning into '/home/ser/repos/cardano-sl/.stack- work/downloaded/wSJGfkFIKfNg'... remote: Counting objects: 345, done. remote: Compressing objects: 100% (42/42), done. remote: Total 345 (delta 18), reused 0 (delta 0), pack-reused 299 Receiving objects: 100% (345/345), 136.62 KiB | 0 bytes/s, done. Resolving deltas: 100% (138/138), done. Cloning into '/home/ser/repos/cardano-sl/.stack- work/downloaded/5U2760eQdlAf'... remote: Counting objects: 2454, done. remote: Total 2454 (delta 0), reused 0 (delta 0), pack-reused 2454 Receiving objects: 100% (2454/2454), 401.41 KiB | 0 bytes/s, done. Resolving deltas: 100% (1100/1100), done. No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl" No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl" No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl" No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl" No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl" No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl" No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl" No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl" No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl" No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl" Missing build-tools may be caused by dependencies of the build-tool being overridden by extra-deps. This should be fixed soon - see this issue https://github.com/commercialhaskell/stack/issues/595 No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl-core" Missing build-tools may be caused by dependencies of the build-tool being overridden by extra-deps. This should be fixed soon - see this issue https://github.com/commercialhaskell/stack/issues/595 No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl-db" Missing build-tools may be caused by dependencies of the build-tool being overridden by extra-deps. This should be fixed soon - see this issue https://github.com/commercialhaskell/stack/issues/595 No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl-infra" Missing build-tools may be caused by dependencies of the build-tool being overridden by extra-deps. This should be fixed soon - see this issue https://github.com/commercialhaskell/stack/issues/595 No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl-lrc" Missing build-tools may be caused by dependencies of the build-tool being overridden by extra-deps. This should be fixed soon - see this issue https://github.com/commercialhaskell/stack/issues/595 No packages found in snapshot which provide a "cpphs" executable, which is a build-tool dependency of "cardano-sl-update" Missing build-tools may be caused by dependencies of the build-tool being overridden by extra-deps. This should be fixed soon - see this issue https://github.com/commercialhaskell/stack/issues/595 base58-bytestring-0.1.0: configure base58-bytestring-0.1.0: build concurrent-extra-0.7.0.10: configure base58-bytestring-0.1.0: copy/register concurrent-extra-0.7.0.10: build directory-1.3.1.0: configure concurrent-extra-0.7.0.10: copy/register directory-1.3.1.0: build cryptonite-0.22: configure cryptonite-0.22: build ed25519-0.0.5.0: configure (lib) ed25519-0.0.5.0: build (lib) network-transport-0.5.1: configure (lib) network-transport-0.5.1: build (lib) directory-1.3.1.0: copy/register Glob-0.7.14: configure ed25519-0.0.5.0: copy/register network-transport-0.5.1: copy/register Glob-0.7.14: build SHA-1.6.4.2: configure SHA-1.6.4.2: build acid-state-0.14.2: configure (lib) acid-state-0.14.2: build (lib) Glob-0.7.14: copy/register cryptonite-0.22: copy/register SHA-1.6.4.2: copy/register Progress: 9/91 -- While building package acid-state-0.14.2 using: /home/ser/.stack/setup-exe-cache/x86_64-linux/Cabal- simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.2.0 build lib:acid-state --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /home/ser/repos/cardano-sl/.stack-work/logs /acid-state-0.14.2.log Configuring acid-state-0.14.2... Preprocessing library acid-state-0.14.2... [ 1 of 15] Compiling Paths_acid_state ( .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/autogen/Paths_acid_state.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/Paths_acid_state.o ) [ 2 of 15] Compiling FileIO ( src-unix/FileIO.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/FileIO.o ) [ 3 of 15] Compiling Data.Acid.Core ( src/Data/Acid/Core.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/Data/Acid/Core.o ) [ 4 of 15] Compiling Data.Acid.Common ( src/Data/Acid/Common.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/Data/Acid/Common.o ) /home/ser/repos/cardano-sl/.stack- work/downloaded/ENyDIhK06WOU/src/Data/Acid/Common.hs:21:1: warning: [-Wunused-imports] The import of ‘Control.Applicative’ is redundant except perhaps to import instances from ‘Control.Applicative’ To import instances alone, use: import Control.Applicative() [ 5 of 15] Compiling Data.Acid.Memory.Pure ( src/Data/Acid/Memory/Pure.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/Data/Acid/Memory/Pure.o ) [ 6 of 15] Compiling Data.Acid.TemplateHaskell ( src/Data/Acid/TemplateHaskell.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/Data/Acid/TemplateHaskell.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Binary.get(TyClDecl): ForeignType CallStack (from HasCallStack): error, called at compiler/iface/IfaceSyn.hs:1530:18 in ghc:IfaceSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Output of `stack --version`: {{{ Version 1.3.2 x86_64 Compiled with: - Cabal-1.24.0.0 - Glob-0.7.14 - HUnit-1.5.0.0 - MonadRandom-0.5.1 - QuickCheck-2.9.2 - SHA-1.6.4.2 - StateVar-1.1.0.4 - aeson-1.0.2.1 - aeson-compat-0.3.6 - annotated-wl-pprint-0.7.0 - ansi-terminal-0.6.2.3 - ansi-wl-pprint-0.6.7.3 - array-0.5.1.1 - asn1-encoding-0.9.5 - asn1-parse-0.9.4 - asn1-types-0.3.2 - async-2.1.1 - attoparsec-0.13.1.0 - auto-update-0.1.4 - base-4.9.0.0 - base-compat-0.9.2 - base-orphans-0.5.4 - base16-bytestring-0.1.1.6 - base64-bytestring-1.0.0.1 - bifunctors-5.4.1 - binary-0.8.3.0 - binary-tagged-0.1.4.2 - bitarray-0.0.1.1 - blaze-builder-0.4.0.2 - blaze-html-0.8.1.3 - blaze-markup-0.7.1.1 - byteable-0.1.1 - bytestring-0.10.8.1 - call-stack-0.1.0 - case-insensitive-1.2.0.8 - cereal-0.5.4.0 - clock-0.7.2 - comonad-5 - conduit-1.2.9 - conduit-extra-1.1.15 - connection-0.2.7 - constraints-0.9.1 - containers-0.5.7.1 - contravariant-1.4 - cookie-0.4.2.1 - cryptohash-0.11.9 - cryptohash-conduit-0.1.1 - cryptonite-0.22 - data-default-class-0.1.2.0 - deepseq-1.4.2.0 - digest-0.0.1.2 - directory-1.2.6.2 - distributive-0.5.2 - dlist-0.8.0.2 - easy-file-0.2.1 - either-4.4.1.1 - errors-2.1.3 - exceptions-0.8.3 - extra-1.5.1 - fast-logger-2.4.10 - file-embed-0.0.10 - filelock-0.1.0.1 - filepath-1.4.1.0 - free-4.12.4 - fsnotify-0.2.1 - generic-deriving-1.11.1 - generics-sop-0.2.4.0 - ghc-boot-th-8.0.1 - ghc-prim-0.5.0.0 - gitrev-1.2.0 - hashable-1.2.5.0 - hastache-0.6.1 - hinotify-0.3.9 - hit-0.6.3 - hourglass-0.2.10 - hpack-0.16.0 - hpc-0.6.0.3 - hspec-2.4.2 - hspec-core-2.4.2 - hspec-discover-2.4.2 - hspec-expectations-0.8.2 - hspec-smallcheck-0.4.2 - http-api-data-0.3.5 - http-client-0.5.6.1 - http-client-tls-0.3.4 - http-conduit-2.2.3.1 - http-types-0.9.1 - ieee754-0.7.9 - integer-gmp-1.0.0.1 - integer-logarithms-1.0.1 - lifted-async-0.9.1.1 - lifted-base-0.2.3.10 - logict-0.6.0.2 - memory-0.14.2 - microlens-0.4.8.0 - microlens-th-0.4.1.1 - mime-types-0.1.0.7 - mmorph-1.0.9 - monad-control-1.0.1.0 - monad-logger-0.3.21 - monad-loops-0.4.3 - monad-unlift-0.2.0 - mono-traversable-1.0.2 - mtl-2.2.1 - network-2.6.3.1 - network-uri-2.6.1.0 - old-locale-1.0.0.7 - old-time-1.1.0.3 - open-browser-0.2.1.0 - optparse-applicative-0.13.2.0 - optparse-simple-0.0.3 - parsec-3.1.11 - path-0.5.12 - path-io-1.2.2 - path-pieces-0.2.1 - patience-0.1.1 - pem-0.2.2 - persistent-2.6.1 - persistent-sqlite-2.6.2 - persistent-template-2.5.2 - pid1-0.1.0.1 - prelude-extras-0.4.0.3 - pretty-1.1.3.3 - primitive-0.6.1.0 - process-1.4.2.0 - profunctors-5.2 - project-template-0.2.0 - quickcheck-io-0.1.4 - random-1.1 - regex-applicative-0.3.3 - regex-applicative-text-0.1.0.1 - resource-pool-0.2.3.2 - resourcet-1.1.9 - retry-0.7.4.2 - rts-1.0 - safe-0.3.14 - safe-exceptions-0.1.5.0 - scientific-0.3.4.10 - semigroupoids-5.1 - semigroups-0.18.2 - setenv-0.1.1.3 - silently-1.2.5 - smallcheck-1.1.1 - socks-0.5.5 - split-0.2.3.1 - stm-2.4.4.1 - stm-chans-3.0.0.4 - store-0.3.1 - store-core-0.3 - streaming-commons-0.1.17 - syb-0.6 - system-fileio-0.3.16.3 - system-filepath-0.4.13.4 - tagged-0.8.5 - tar-0.5.0.3 - template-haskell-2.11.0.0 - temporary-1.2.0.4 - text-1.2.2.1 - text-binary-0.2.1.1 - text-metrics-0.2.0 - tf-random-0.5 - th-expand-syns-0.4.2.0 - th-lift-0.7.6 - th-lift-instances-0.1.11 - th-orphans-0.13.3 - th-reify-many-0.1.6 - th-utilities-0.2.0.1 - time-1.6.0.1 - time-locale-compat-0.1.1.3 - tls-1.3.10 - transformers-0.5.2.0 - transformers-base-0.4.4 - transformers-compat-0.5.1.4 - unexceptionalio-0.3.0 - unicode-transforms-0.2.1 - unix-2.7.2.0 - unix-compat-0.4.3.1 - unix-time-0.3.7 - unordered-containers-0.2.7.2 - uri-bytestring-0.2.3.1 - utf8-string-1.0.1.1 - uuid-types-1.0.3 - vector-0.11.0.0 - vector-algorithms-0.7.0.1 - vector-binary-instances-0.2.3.4 - void-0.7.1 - x509-1.6.5 - x509-store-1.6.2 - x509-system-1.6.4 - x509-validation-1.6.5 - yaml-0.8.22 - zip-archive-0.3.0.5 - zlib-0.6.1.2 - zlib-bindings-0.1.1.5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 21:34:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 21:34:03 -0000 Subject: [GHC] #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to (was: GHC doesn't discharge heterogenous equality constraint when it ought to) In-Reply-To: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> References: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> Message-ID: <065.558154f2b6fd9761ad3433ab08190418@haskell.org> #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to -------------------------------------+------------------------------------- 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 21:34:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 21:34:41 -0000 Subject: [GHC] #13676: Command line written to stats file by the rts is not executable Message-ID: <043.05bc91383c339dd2ff8ddb0a3cf67e10@haskell.org> #13676: Command line written to stats file by the rts is not executable -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The first line of the stats file output by the rts is the invocation of the program. However the "s around arguments are not present in that line. For example: {{{ $ ghc +RTS -trts-test -RTS -e "do {putStrLn\$ show [1,2] ++ (\"(\\\\haskell)\")}" &>/dev/null && cat rts-test | head -n 1 /opt/ghc/8.0.2/lib/ghc-8.0.2/bin/ghc -B/opt/ghc/8.0.2/lib/ghc-8.0.2 -e do {putStrLn$ show [1,2] ++ ("(\\haskell)")} +RTS -trts-test }}} I would expect that this line could be pasted into a shell to invoke the command, however this is not the case as evidenced above. There are several issues evidenced by the above example: * the quoted argument "do {...}" does not have quotes in the output. I believe this is a true bug. * the $,"s and \s inside the quoted argument are not escaped. I'm fairly sure that at least the "s and \s should be escaped. Not so sure that $ should be, since a shell isn't the only way to run a program. * The +RTS options are moved to the end. This is seems intentional and doesn't change semantics, but it seems better to be exactly the same. The relevant code is in initStatsFile in RtsFlags.c I'd suggest quoting each argument, escaping at least "s and \s inside arguments and thinking about whether escaping other shell characters like $ is a good idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 21:35:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 21:35:55 -0000 Subject: [GHC] #13676: Command line written to stats file by the rts is not executable In-Reply-To: <043.05bc91383c339dd2ff8ddb0a3cf67e10@haskell.org> References: <043.05bc91383c339dd2ff8ddb0a3cf67e10@haskell.org> Message-ID: <058.992a311b8e775961b5142d6134d7569d@haskell.org> #13676: Command line written to stats file by the rts is not executable -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * version: 8.0.1 => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 22:16:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 22:16:57 -0000 Subject: [GHC] #13676: Command line written to stats file by the rts is not executable In-Reply-To: <043.05bc91383c339dd2ff8ddb0a3cf67e10@haskell.org> References: <043.05bc91383c339dd2ff8ddb0a3cf67e10@haskell.org> Message-ID: <058.6dbf8d7462baf8280d7db5ab8c70a6e3@haskell.org> #13676: Command line written to stats file by the rts is not executable -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 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 duog): The same issues is present in at least the Profiling Report, grep for prog_argv. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 22:19:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 22:19:57 -0000 Subject: [GHC] #13677: Incorrect parenthesization of type in error message Message-ID: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> #13677: Incorrect parenthesization of type in error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you compile this program: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} import GHC.Exts (Constraint) data Dict a where Dict :: a => Dict a foo :: Dict (Int ~ Int) => Int foo = undefined }}} In GHC 8.0.1, 8.0.2, 8.2.1, or HEAD, it will give this error message: {{{ GHCi, version 8.3.20170509: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug2.hs, interpreted ) Bug2.hs:9:8: error: • Expected a constraint, but ‘Dict Int ~ Int’ has kind ‘*’ • In the type signature: foo :: Dict (Int ~ Int) => Int | 9 | foo :: Dict (Int ~ Int) => Int | ^^^^^^^^^^^^^^^^ }}} But `Dict Int ~ Int` is not parenthesized correctly! This is a regression, as GHC 7.10.3 and earlier parenthesize it correctly: {{{ GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Bug2.hs, interpreted ) Bug2.hs:9:8: Expected a constraint, but ‘Dict (Int ~ Int)’ has kind ‘*’ In the type signature for ‘foo’: foo :: Dict (Int ~ Int) => Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 22:20:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 22:20:22 -0000 Subject: [GHC] #314: #line pragmas not respected inside nested comments In-Reply-To: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> References: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> Message-ID: <060.ba974c80e3867eee678e783d40e8e53c@haskell.org> #314: #line pragmas not respected inside nested comments -------------------------------------+------------------------------------- Reporter: nobody | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 6.4 (Parser) | Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: read032 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal Comment: This clearly isn't particularly hurtful to anyone given it has been open for 12 years. Happy birthday, bug! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 22:22:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 22:22:01 -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.9e657543f1fa5f5860d933c795c2fbbf@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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: I need to r try again with 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 22:23:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 22:23:58 -0000 Subject: [GHC] #13239: Phabricator upgrade broke the ticket custom field In-Reply-To: <049.46dde039393aed4aa73448d64c0403c4@haskell.org> References: <049.46dde039393aed4aa73448d64c0403c4@haskell.org> Message-ID: <064.7798dbfa6706614e506ec41fc5ce55bd@haskell.org> #13239: Phabricator upgrade broke the ticket custom field -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: Component: None | 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 * component: Compiler => None * resolution: => fixed Comment: This has been resolved thanks to mpickering's tireless debugging efforts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 22:29:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 22:29:44 -0000 Subject: [GHC] #13150: unknown warning is not reported by GHC In-Reply-To: <049.672ae1b4361f2e5aa46b2a80fb5e7e8f@haskell.org> References: <049.672ae1b4361f2e5aa46b2a80fb5e7e8f@haskell.org> Message-ID: <064.294a806053570edcadd85e6ac1c21082@haskell.org> #13150: unknown warning is not reported by GHC -------------------------------------+------------------------------------- Reporter: jonaprieto | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: quchen, hvr (added) Comment: Relatedly, I wonder whether we should split up `Wwarnings-deprecations` into two distinct flags: `Wwarnings` and `Wdeprecations`, as I can imagine cases where users may want to make one `Werror` but not the other. Ccjng quchen and hvr, who have both thought about the structure of our warning flags quite a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 22:49:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 22:49:00 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.05cc679692762d31b8929d3f7fde1094@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It would be interesting to know how many ticks 7.10 requires. Currently it's unclear whether the package was previously just on the edge and was pushed over in 8.0, or whether 8.0 regressed significantly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 22:53:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 22:53:31 -0000 Subject: [GHC] #1290: ghc runs preprocessor too much In-Reply-To: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> References: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> Message-ID: <059.ae39b78f48136e9f745b4f9bbe3a59ae@haskell.org> #1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.7 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): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 22:56:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 22:56:46 -0000 Subject: [GHC] #1318: add warning for prefix negate operator and flag to replace it with negative numeric literals In-Reply-To: <051.8afc8cd3429be203bc781261234852fc@haskell.org> References: <051.8afc8cd3429be203bc781261234852fc@haskell.org> Message-ID: <066.86802cc23d2db2f61de2b9a95ad29673@haskell.org> #1318: add warning for prefix negate operator and flag to replace it with negative numeric literals -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.6.1 (Parser) | Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: We have `-XNegativeLiterals` now but I don't think that removing the `-` operator is going to happen at this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 23:00:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 23:00:44 -0000 Subject: [GHC] #1349: Generalise the ! and UNPACK mechanism for data types, to unpack function arguments In-Reply-To: <046.9dd17815048ce25749ab5bff260d2925@haskell.org> References: <046.9dd17815048ce25749ab5bff260d2925@haskell.org> Message-ID: <061.06ded7e749bf3ba6d33ad9fe813ae539@haskell.org> #1349: Generalise the ! and UNPACK mechanism for data types, to unpack function arguments -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: dfeuer (added) Comment: Dfeuer, I believe this is relevant to your recent proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 23:07:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 23:07:31 -0000 Subject: [GHC] #3024: Rewrite hp2ps in Haskell In-Reply-To: <043.5e2ae06063a38e8d4403ee8cfc50d869@haskell.org> References: <043.5e2ae06063a38e8d4403ee8cfc50d869@haskell.org> Message-ID: <058.4d7754cbdc98bdd330e50a5eeaadc823@haskell.org> #3024: Rewrite hp2ps in Haskell -------------------------------------+------------------------------------- Reporter: SamB | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Profiling | Version: 6.10.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5641, 7291 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: For what it is worth there are now numerous alternatives to hp2ps on Hackage (e.g. `hp2pretty`). Moreover, we are now able to emit profiler records to the event log, making parsing much simpler. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 23:09:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 23:09:26 -0000 Subject: [GHC] #3021: A way to programmatically insert marks into heap profiling output In-Reply-To: <043.8f6f7af4d3cf139bc012e761a76247cb@haskell.org> References: <043.8f6f7af4d3cf139bc012e761a76247cb@haskell.org> Message-ID: <058.38d2069baec389e3fd9f7de53517406f@haskell.org> #3021: A way to programmatically insert marks into heap profiling output -------------------------------------+------------------------------------- Reporter: SamB | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Profiling | Version: 6.10.1 Resolution: fixed | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11094 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Profiler records can now be sent to the event log, making the request in this ticket possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 23:14:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 23:14:41 -0000 Subject: [GHC] #4102: Bit manipulation built-ins In-Reply-To: <049.9814fd052d90f7d2841adf98c6e4a213@haskell.org> References: <049.9814fd052d90f7d2841adf98c6e4a213@haskell.org> Message-ID: <064.5f58dd4d5d8c54570834b88a8d7658cd@haskell.org> #4102: Bit manipulation built-ins -------------------------------------+------------------------------------- Reporter: uzytkownik | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: Core Libraries | Version: 6.12.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.0.2 Comment: I believe all of the suggested operations have been implemented in `Data.Bits`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 23:41:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 23:41:08 -0000 Subject: [GHC] #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to In-Reply-To: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> References: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> Message-ID: <065.b0dba655230b340d167361828a324a55@haskell.org> #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to -------------------------------------+------------------------------------- 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): For what it's worth, it still doesn't help (in GHC 8.0.1) if I change all the `~`s to `~~`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 23:55:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 23:55:02 -0000 Subject: [GHC] #7104: Add tryWriteTBQueue to Control.Concurrent.STM.TBQueue In-Reply-To: <048.820960f7a81343147437e4061ea19d9b@haskell.org> References: <048.820960f7a81343147437e4061ea19d9b@haskell.org> Message-ID: <063.e7376914b206aa9584299e6343915424@haskell.org> #7104: Add tryWriteTBQueue to Control.Concurrent.STM.TBQueue -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.4.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Comment: We should probably act on these one way or another. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 23:57:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 23:57:04 -0000 Subject: [GHC] #7320: GHC crashes when building on 32-bit Linux in a Linode In-Reply-To: <043.0168db82b571fa620930b74d5d40cf16@haskell.org> References: <043.0168db82b571fa620930b74d5d40cf16@haskell.org> Message-ID: <058.af6a052af781720a4d2dcadaa7963677@haskell.org> #7320: GHC crashes when building on 32-bit Linux in a Linode ---------------------------------------+-------------------------------- Reporter: benl | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.6.1 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+-------------------------------- Changes (by bgamari): * status: new => closed * resolution: => worksforme Comment: Closing due to inactivity. Feel free to reopen if this is still the case with a recent release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 9 23:58:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 May 2017 23:58:04 -0000 Subject: [GHC] #7337: GHC does not generate great code for bit-level rotation In-Reply-To: <042.1bdaae6f89f84d88685747f45c6e6712@haskell.org> References: <042.1bdaae6f89f84d88685747f45c6e6712@haskell.org> Message-ID: <057.227892348c8dbca3fac2bcb9f1977dbb@haskell.org> #7337: GHC does not generate great code for bit-level rotation -------------------------------------+------------------------------------- Reporter: bos | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Any progress on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 00:02:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 00:02:49 -0000 Subject: [GHC] #7461: Error messages about "do" statements contain false information In-Reply-To: <048.c398523dc448a90c4ad05d90f3fe6eb0@haskell.org> References: <048.c398523dc448a90c4ad05d90f3fe6eb0@haskell.org> Message-ID: <063.bd3e9b518a29b1dadcbb87bd3e0c841f@haskell.org> #7461: Error messages about "do" statements contain false information -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 7.6.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.0.2 Comment: GHC 8.0 produces, {{{ hi.hs:2:3: error: • Couldn't match expected type ‘Char’ with actual type ‘IO Char’ • In a stmt of a 'do' block: getLine In the second argument of ‘($)’, namely ‘do { getLine; return 'x' }’ In the expression: putChar $ do { getLine; return 'x' } }}} Which seems quite reasonable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 00:04:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 00:04:19 -0000 Subject: [GHC] #13669: Identifier "Otherwise" in guarded equation can crash a program In-Reply-To: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> References: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> Message-ID: <059.8dbdc6b39b2d27c00dcc341e160d011f@haskell.org> #13669: Identifier "Otherwise" in guarded equation can crash a program -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm certainly agreed that there is a beginning for everything and that users can and should bring up new ideas with an effort to evolve the language. GHC is an open-source compiler for an open language. Anyone can write proposals for language changes and submit patches for inclusion in the compiler. The proposals process, as decided on by the community, is the way to get a consensus of opinion so that a change to the language can be made. This is why I said "Regardless of our opinions": our personal opinions don't really matter, because you can always make a proposal and seek community consensus beyond just the two of us. I'm not sure what problem you have had with the proposals process, but I don't think it's Ben's responsibility to explain. If you've already posted where your problem lies, please provide a link. While I'm not involved in the communities of other languages, I do use several non-functional languages. This past year, I taught courses in Java and C (as well as Haskell), and next year I will be teaching just Java in my courses. When I teach a programming languages course, the focus of the course will be Java, not Haskell. (This is because, with Java 8, Java supports programming in a large variety of modes, including functional.) So I don't think it's fair to presume our familiarity or lack thereof with other languages and the ideas stemming from these languages. Do you have a language in mind with the feature you are seeking here? But don't answer me here -- put it in the proposal! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 00:16:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 00:16:07 -0000 Subject: [GHC] #8082: Ordering of assembly blocks affects performance In-Reply-To: <048.a1c9fecabf21ad13e9b6872825272ba6@haskell.org> References: <048.a1c9fecabf21ad13e9b6872825272ba6@haskell.org> Message-ID: <063.54eae6b3bb5c72a68e950412d1fe8339@haskell.org> #8082: Ordering of assembly blocks affects performance -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: I don't really see what we can do about this. There are numerous reasons why code layout affects performance (e.g., see [[http://llvm.org/devmtg/2016-11/#talk2|this talk]] from the LLVM developers meeting) and tackling most of them is Very Hard. We can continue to chat on this ticket, but I'm going to close it as its not really actionable as-is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 00:28:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 00:28:41 -0000 Subject: [GHC] #8573: "evacuate: strange closure type 0" when creating large array In-Reply-To: <042.f5cd7a98abbf8cf5e70fa72eb7020fdc@haskell.org> References: <042.f5cd7a98abbf8cf5e70fa72eb7020fdc@haskell.org> Message-ID: <057.7add9b642fe23f7f0d8bea6bdd149ce9@haskell.org> #8573: "evacuate: strange closure type 0" when creating large array -------------------------------------+------------------------------------- Reporter: nad | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 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): With GHC HEAD I get, {{{ $ ghc --make hi.hs -O -main-is strangeClosureType [1 of 1] Compiling Main ( hi.hs, hi.o ) Linking hi ... $ ./hi 2111752566 hi: Out of memory }}} rwbarton, I suppose your thought was that the primop implementations should also do their own integer overflow checks? I'm not entirely convinced that is necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 00:32:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 00:32:18 -0000 Subject: [GHC] #8396: cleanup / refactor native code gens In-Reply-To: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> References: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> Message-ID: <060.f044507e5eebce272ee897179ac3d69a@haskell.org> #8396: cleanup / refactor native code gens -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler (NCG) | Version: Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8299 , #8287 | Differential Rev(s): ,#8272 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: Given that this is four years old and not terribly actionable, I'm going to close this. I think these sorts of tasks are better tracked as individual narrow tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 00:36:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 00:36:24 -0000 Subject: [GHC] #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to In-Reply-To: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> References: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> Message-ID: <065.82744a277e34c96a7ba88c05999b6e88@haskell.org> #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to -------------------------------------+------------------------------------- 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 00:39:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 00:39:06 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.c2c4792893c6b52b4e6d2ee902fdf994@haskell.org> #8949: switch -msse2 to be on by default --------------------------------------------+------------------------------ Reporter: errge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (CodeGen) | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Changes (by bgamari): * priority: normal => high * milestone: => 8.4.1 Comment: I am fine doing this for 8.4. Milestonjng. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 00:41:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 00:41:03 -0000 Subject: [GHC] #8875: Track Exceptions In-Reply-To: <044.40ee9daff1e997b21df30175182c507b@haskell.org> References: <044.40ee9daff1e997b21df30175182c507b@haskell.org> Message-ID: <059.8519977b8d8aae1df7f5636926d450bd@haskell.org> #8875: Track Exceptions -------------------------------------+------------------------------------- Reporter: yokto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => ⊥ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 00:45:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 00:45:45 -0000 Subject: [GHC] #9120: Cache intermediate powers In-Reply-To: <049.1ee5b6115869efb06c318270302523f2@haskell.org> References: <049.1ee5b6115869efb06c318270302523f2@haskell.org> Message-ID: <064.03c69d422afe8fec2d5b1f8bf6c13976@haskell.org> #9120: Cache intermediate powers -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 00:56:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 00:56:18 -0000 Subject: [GHC] #13678: Overhaul the linker Message-ID: <047.e127759c3a4017d82c97188d47fb36ec@haskell.org> #13678: Overhaul the linker -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 8.3 (Linking) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The linker has gained support for aarch64/macho, and aarch64/elf, as well as improved arm/elf code, this code introduces separate mapping of sections into different pages, to allow for `W^X` protection. This is essentially a requirement on iOS, and I believe a sane default to have. To this extend the symbol extras logic needed to be split up into GOT and PLTs, where the PLTs are allocated alongside the sections, as the architecture may not allow arbitrary jumps (arm/aarch64). The introduction aarch64/elf has also been done through a pseudo interface so that the actual relocation logic can be contained within it's own files. Ideally we'd improve the linker by migrating the existing (heavily #ifdef'd) to the new separate section mapping (`W^X`) and pseudo interface approach. The separate section mapping logic has an inherent memory inefficiency (which might be improved a bit by aggregating similar sections into the same page), and might also cause a performance penalty due to separate mapping instead of a single file mmap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 01:08:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 01:08:31 -0000 Subject: [GHC] #9287: changed dependency generation In-Reply-To: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> References: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> Message-ID: <060.c97d58906281f32078d1a34d22594f3d@haskell.org> #9287: changed dependency generation -------------------------------------+------------------------------------- Reporter: maeder | Owner: simonmar Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Driver | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #9749, #7381 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Was this ever resolved? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 01:38:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 01:38:28 -0000 Subject: [GHC] #10323: Add Android and iOS Operating Systems in Trac In-Reply-To: <047.f0e8ed2b242d053a71552d342705050c@haskell.org> References: <047.f0e8ed2b242d053a71552d342705050c@haskell.org> Message-ID: <062.6050a66052ac88c0afe3d2a0034fad2b@haskell.org> #10323: Add Android and iOS Operating Systems in Trac -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: hvr Type: feature request | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 01:40:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 01:40:19 -0000 Subject: [GHC] #10584: Installation of SFML failed In-Reply-To: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> References: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> Message-ID: <062.473ed0b65b87a6b3c1124981e5f395cc@haskell.org> #10584: Installation of SFML failed -------------------------------------+------------------------------------- Reporter: SoleSoul | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 01:40:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 01:40:40 -0000 Subject: [GHC] #10584: Installation of SFML failed In-Reply-To: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> References: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> Message-ID: <062.95264d31292b658b7305fd2ed71d9122@haskell.org> #10584: Installation of SFML failed -------------------------------------+------------------------------------- Reporter: SoleSoul | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -4,0 +4,1 @@ + {{{ @@ -102,0 +103,1 @@ + }}} New description: This report is bad because I have no idea what I'm reporting but the compiler asked me to so there you go: {{{ % cabal install sfml :( Resolving dependencies... Configuring SFML-0.2.0.0... Building SFML-0.2.0.0... Failed to install SFML-0.2.0.0 Build log ( /home/user/.cabal/logs/SFML-0.2.0.0.log ): Configuring SFML-0.2.0.0... Building SFML-0.2.0.0... Preprocessing library SFML-0.2.0.0... [ 1 of 71] Compiling SFML.Window.WindowHandle ( src/SFML/Window/WindowHandle.hs, dist/build/SFML/Window/WindowHandle.o ) [ 2 of 71] Compiling SFML.SFDisplayable ( src/SFML/SFDisplayable.hs, dist/build/SFML/SFDisplayable.o ) [ 3 of 71] Compiling SFML.SFCopyable ( src/SFML/SFCopyable.hs, dist/build/SFML/SFCopyable.o ) [ 4 of 71] Compiling SFML.System.InputStream ( dist/build/SFML/System/InputStream.hs, dist/build/SFML/System/InputStream.o ) [ 5 of 71] Compiling SFML.SFResource ( src/SFML/SFResource.hs, dist/build/SFML/SFResource.o ) [ 6 of 71] Compiling SFML.Utils ( src/SFML/Utils.hs, dist/build/SFML/Utils.o ) [ 7 of 71] Compiling SFML.Window.VideoMode ( dist/build/SFML/Window/VideoMode.hs, dist/build/SFML/Window/VideoMode.o ) [ 8 of 71] Compiling SFML.Window.Types ( src/SFML/Window/Types.hs, dist/build/SFML/Window/Types.o ) [ 9 of 71] Compiling SFML.Window.Keyboard ( dist/build/SFML/Window/Keyboard.hs, dist/build/SFML/Window/Keyboard.o ) [10 of 71] Compiling SFML.Window.Joystick ( dist/build/SFML/Window/Joystick.hs, dist/build/SFML/Window/Joystick.o ) [11 of 71] Compiling SFML.Window.ContextSettings ( dist/build/SFML/Window/ContextSettings.hs, dist/build/SFML/Window/ContextSettings.o ) [12 of 71] Compiling SFML.Window.Context ( dist/build/SFML/Window/Context.hs, dist/build/SFML/Window/Context.o ) [13 of 71] Compiling SFML.System.Vector3 ( dist/build/SFML/System/Vector3.hs, dist/build/SFML/System/Vector3.o ) [14 of 71] Compiling SFML.System.Vector2 ( dist/build/SFML/System/Vector2.hs, dist/build/SFML/System/Vector2.o ) [15 of 71] Compiling SFML.Window.Mouse ( dist/build/SFML/Window/Mouse.hs, dist/build/SFML/Window/Mouse.o ) [16 of 71] Compiling SFML.Window.Event ( dist/build/SFML/Window/Event.hs, dist/build/SFML/Window/Event.o ) [17 of 71] Compiling SFML.Window.SFWindow ( src/SFML/Window/SFWindow.hs, dist/build/SFML/Window/SFWindow.o ) [18 of 71] Compiling SFML.Window.Window ( dist/build/SFML/Window/Window.hs, dist/build/SFML/Window/Window.o ) [19 of 71] Compiling SFML.System.Time ( dist/build/SFML/System/Time.hs, dist/build/SFML/System/Time.o ) [20 of 71] Compiling SFML.Audio.SFSoundBuffer ( src/SFML/Audio/SFSoundBuffer.hs, dist/build/SFML/Audio/SFSoundBuffer.o ) [21 of 71] Compiling SFML.System.Sleep ( dist/build/SFML/System/Sleep.hs, dist/build/SFML/System/Sleep.o ) [22 of 71] Compiling SFML.System.Clock ( src/SFML/System/Clock.hs, dist/build/SFML/System/Clock.o ) [23 of 71] Compiling SFML.System ( src/SFML/System.hs, dist/build/SFML/System.o ) [24 of 71] Compiling SFML.Window ( src/SFML/Window.hs, dist/build/SFML/Window.o ) [25 of 71] Compiling SFML.Graphics.Types ( src/SFML/Graphics/Types.hs, dist/build/SFML/Graphics/Types.o ) [26 of 71] Compiling SFML.Graphics.SFSmoothTexture ( src/SFML/Graphics/SFSmoothTexture.hs, dist/build/SFML/Graphics/SFSmoothTexture.o ) [27 of 71] Compiling SFML.Graphics.SFShapeResizable ( src/SFML/Graphics/SFShapeResizable.hs, dist/build/SFML/Graphics/SFShapeResizable.o ) [28 of 71] Compiling SFML.Graphics.SFCoordSpace ( src/SFML/Graphics/SFCoordSpace.hs, dist/build/SFML/Graphics/SFCoordSpace.o ) [29 of 71] Compiling SFML.Graphics.SFBindable ( src/SFML/Graphics/SFBindable.hs, dist/build/SFML/Graphics/SFBindable.o ) [30 of 71] Compiling SFML.Graphics.Rect ( dist/build/SFML/Graphics/Rect.hs, dist/build/SFML/Graphics/Rect.o ) [31 of 71] Compiling SFML.Graphics.SFBounded ( src/SFML/Graphics/SFBounded.hs, dist/build/SFML/Graphics/SFBounded.o ) [32 of 71] Compiling SFML.Graphics.SFViewable ( src/SFML/Graphics/SFViewable.hs, dist/build/SFML/Graphics/SFViewable.o ) [33 of 71] Compiling SFML.Graphics.Texture ( src/SFML/Graphics/Texture.hs, dist/build/SFML/Graphics/Texture.o ) [34 of 71] Compiling SFML.Graphics.Transform ( dist/build/SFML/Graphics/Transform.hs, dist/build/SFML/Graphics/Transform.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $j_sJFj To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 190129 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: SFML-0.2.0.0 failed during the building phase. The exception was: ExitFailure 1 cabal install sfml 7.18s user 0.76s system 93% cpu 8.460 total }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 02:39:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 02:39:26 -0000 Subject: [GHC] #13677: Incorrect parenthesization of type in error message In-Reply-To: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> References: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> Message-ID: <065.86528f66ce26e5f40d4bcd04deeba46d@haskell.org> #13677: Incorrect parenthesization of type in error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Commit 09b872dc61590a71c28feb37c37bf864664efaf7 (Make equality print better. (#11712)) is responsible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 06:26:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 06:26:10 -0000 Subject: [GHC] #9287: changed dependency generation In-Reply-To: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> References: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> Message-ID: <060.4c397909344be5118391cf06a41389d4@haskell.org> #9287: changed dependency generation -------------------------------------+------------------------------------- Reporter: maeder | Owner: simonmar Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Driver | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #9749, #7381 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by maeder): It was only a documentation issue for "ghc -M". I don't know if the documentation for this section changed after ghc-7.8 (or if the code was changed back). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 06:41:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 06:41:08 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.88140b3a182cb05a0d2bdacb8b3164ec@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by LocutusOfBorg): Hello, I guess you mean 8.0.1 not 7.10. 8.0.1 required at least 81 ticks, while 8.0.2 requires at least 103 (with ghc 8.0.1 80 fails and with ghc 8.0.2 104 fails) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 07:16:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 07:16:35 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.d82b361d8874b3c22245fb716091b118@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Phab:D3550 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Simon, there's a Note [inline sccs] about why we don't have them for `INLINE` things: {{{#!hs -- It should be reasonable to add ticks to INLINE functions; however -- currently this tickles a bug later on because the SCCfinal pass -- does not look inside unfoldings to find CostCentres. It would be -- difficult to fix that, because SCCfinal currently works on STG and -- not Core (and since it also generates CostCentres for CAFs, -- changing this would be difficult too). -- -- Another reason not to add ticks to INLINE functions is that this -- sometimes handy for avoiding adding a tick to a particular function -- (see #6131) -- -- So for now we do not add any ticks to INLINE functions at all. }}} Even if dealing with ticks through inlining isn't feasible, this whole thing seems a bit surprising to me because `INLINE` bindings aren't always inlined, and non-`INLINE` bindings often are. Using an `INLINE` annotation for its side effect on SCC annotations seems rather ugly. The current proposed change just does what osa1 seems to suggest, limiting the exclusion to `INLINE` rather than to both `INLINE` and `INLINABLE` in `Coverage.hs`. This appears to affect ticks generally, rather than SCC ticks specifically, but that ''seems'' to my uneducated eye to be the case for the various auto-add options too (see `shouldTickBind` and `mkDensity`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 07:34:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 07:34:29 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.8d7d5cb3cc1b2ac80d21372ce699473f@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Phab:D3550 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Fine -- whatever the resolution: * could the Note be made specific about the INLINE/INLINABLE choice, and point to this ticket? and * could the calls to `isInlinePragma` have a pointer to that Note? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 07:42:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 07:42:21 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.7b6aecfac7871881a71774d68c9b2164@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by marinelli): Is it still open? I've just tried listing and dumping packages with the both release candidate versions, obtaining the same result, e.g.: {{{ $ ghc-pkg list WARNING: cache is out of date: /opt/apps/ghc/20170510-8.2.1-rc2-1/lib/ghc-8.2.0.20170507/package.conf.d/package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. /opt/apps/ghc/20170510-8.2.1-rc2-1/lib/ghc-8.2.0.20170507/package.conf.d Cabal-2.0.0.0 array-0.5.1.2 ---✂--- }}} I am working with a Debian distribution (testing channel) on a btrfs file system, and I've used the x86_64-deb8 builds of GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 07:51:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 07:51:26 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.a97eafea32c4a72ca8b1334e34bf3713@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by arybczak): What are the steps to reproduce? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 08:41:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 08:41:19 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.e8279a584afd9aa37ab53fa9cb124a04@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by marinelli): Here they are: {{{ $ mkdir -p /tmp/ghc $ wget -q -P /tmp/ghc/ 'https://downloads.haskell.org/~ghc/8.2.1-rc2/ghc-8.2.0.20170507-x86_64-deb8-linux.tar.xz' $ cd /tmp/ghc/ $ tar xf ghc-8.2.0.20170507-x86_64-deb8-linux.tar.xz $ cd ./ghc-8.2.0.20170507/ $ sh configure --prefix=/opt/ghc $ make install $ env PATH=/opt/ghc/bin:$PATH ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.0.20170507 $ env PATH=/opt/ghc/bin:$PATH ghc-pkg list WARNING: cache is out of date: /opt/ghc/lib/ghc-8.2.0.20170507/package.conf.d/package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. /opt/ghc/lib/ghc-8.2.0.20170507/package.conf.d Cabal-2.0.0.0 array-0.5.1.2 ---✂--- }}} The file config.log is here https://gist.github.com/anonymous/05fc2191ffd6a49eb8f3108b17d07d51 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 09:51:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 09:51:41 -0000 Subject: [GHC] #13669: Identifier "Otherwise" in guarded equation can crash a program In-Reply-To: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> References: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> Message-ID: <059.8b7d4317340bde1cda257419cd75a473@haskell.org> #13669: Identifier "Otherwise" in guarded equation can crash a program -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Reply to goldfire:\\ Thank you for your opinion. I respect your choice.\\ I failed to explain why I do not write proposals.\\ Take a look at ticket {{{#13505}}}. Thank you for giving a reply in this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 10:14:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 10:14:03 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.529c4c9045ae5056e2ca777b9505ca7b@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by arybczak): The problem is that `make install` script, after installing all packages, does this: `for f in '/home/unknown/Media/GHC/8.2.1_rc2/lib/ghc-8.2.0.20170507/package.conf.d'/*; do create () { touch "$1" && chmod 644 "$1" ; } && create "$f"; done` which puts modification time of several .conf packages ahead of package.cache. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 14:07:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 14:07:16 -0000 Subject: [GHC] #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to In-Reply-To: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> References: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> Message-ID: <065.d994021bc70bbab66fa2a89fcf03b657@haskell.org> #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to -------------------------------------+------------------------------------- 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: @@ -51,0 +51,9 @@ + instance KnownNat n => Num (GF n) where + xf@(GF x) + GF y = GF $ (x+y) `mod` (natVal xf) + xf@(GF x) - GF y = GF $ (x-y) `mod` (natVal xf) + xf@(GF x) * GF y = GF $ (x*y) `mod` (natVal xf) + abs = id + signum xf@(GF x) | x==0 = xf + | otherwise = GF 1 + fromInteger = GF + @@ -74,1 +83,1 @@ - Bug.hs:54:21: error: + Bug.hs:63:21: error: @@ -79,1 +88,1 @@ - at Bug.hs:53:1-44 + at Bug.hs:62:1-44 @@ -90,5 +99,5 @@ - y :: GF m (bound at Bug.hs:54:17) - x :: GF m (bound at Bug.hs:54:6) - bar :: GF m -> GF m -> GF m (bound at Bug.hs:54:1) - | - 54 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() + y :: GF m (bound at Bug.hs:63:17) + x :: GF m (bound at Bug.hs:63:6) + bar :: GF m -> GF m -> GF m (bound at Bug.hs:63:1) + | + 63 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() @@ -98,1 +107,1 @@ - Bug.hs:54:31: error: + Bug.hs:63:31: error: @@ -103,5 +112,5 @@ - at Bug.hs:54:31-85 - ‘m’ is a rigid type variable bound by - the type signature for: - bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m - at Bug.hs:53:1-44 + at Bug.hs:63:31-85 + ‘m’ is a rigid type variable bound by + the type signature for: + bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m + at Bug.hs:62:1-44 @@ -115,5 +124,5 @@ - y :: GF m (bound at Bug.hs:54:17) - x :: GF m (bound at Bug.hs:54:6) - bar :: GF m -> GF m -> GF m (bound at Bug.hs:54:1) - | - 54 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() + y :: GF m (bound at Bug.hs:63:17) + x :: GF m (bound at Bug.hs:63:6) + bar :: GF m -> GF m -> GF m (bound at Bug.hs:63:1) + | + 63 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() @@ -136,2 +145,2 @@ - $ /opt/ghc/8.2.1/bin/ghci Bug.hs -fprint-explicit-kinds - GHCi, version 8.2.0.20170505: http://www.haskell.org/ghc/ :? for help + $ /opt/ghc/head/bin/ghci Bug.hs -fprint-explicit-kinds + GHCi, version 8.3.20170509: http://www.haskell.org/ghc/ :? for help @@ -141,1 +150,1 @@ - Bug.hs:54:21: error: + Bug.hs:63:21: error: @@ -146,1 +155,1 @@ - at Bug.hs:53:1-44 + at Bug.hs:62:1-44 @@ -157,5 +166,5 @@ - y :: GF m (bound at Bug.hs:54:17) - x :: GF m (bound at Bug.hs:54:6) - bar :: GF m -> GF m -> GF m (bound at Bug.hs:54:1) - | - 54 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() + y :: GF m (bound at Bug.hs:63:17) + x :: GF m (bound at Bug.hs:63:6) + bar :: GF m -> GF m -> GF m (bound at Bug.hs:63:1) + | + 63 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() @@ -165,1 +174,1 @@ - Bug.hs:54:31: error: + Bug.hs:63:31: error: @@ -170,5 +179,5 @@ - at Bug.hs:54:31-85 - ‘m’ is a rigid type variable bound by - the type signature for: - bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m - at Bug.hs:53:1-44 + at Bug.hs:63:31-85 + ‘m’ is a rigid type variable bound by + the type signature for: + bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m + at Bug.hs:62:1-44 @@ -182,7 +191,7 @@ - y :: GF m (bound at Bug.hs:54:17) - x :: GF m (bound at Bug.hs:54:6) - bar :: GF m -> GF m -> GF m (bound at Bug.hs:54:1) - | - 54 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() - (lcmIsIdempotent @m) - | ^^^^^^^ + y :: GF m (bound at Bug.hs:63:17) + x :: GF m (bound at Bug.hs:63:6) + bar :: GF m -> GF m -> GF m (bound at Bug.hs:63:1) + | + 63 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() + (lcmIsIdempotent @m) + | New description: Here's some code, reduced from an example in https://github.com/ekmett/constraints/issues/55: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} import Data.Proxy import GHC.Exts (Constraint) import GHC.TypeLits import Unsafe.Coerce (unsafeCoerce) data Dict :: Constraint -> * where Dict :: a => Dict a infixr 9 :- newtype a :- b = Sub (a => Dict b) -- | Given that @a :- b@, derive something that needs a context @b@, using the context @a@ (\\) :: a => (b => r) -> (a :- b) -> r r \\ Sub Dict = r newtype Magic n = Magic (KnownNat n => Dict (KnownNat n)) magic :: forall n m o. (Integer -> Integer -> Integer) -> (KnownNat n, KnownNat m) :- KnownNat o magic f = Sub $ unsafeCoerce (Magic Dict) (natVal (Proxy :: Proxy n) `f` natVal (Proxy :: Proxy m)) type family Lcm :: Nat -> Nat -> Nat where axiom :: forall a b. Dict (a ~ b) axiom = unsafeCoerce (Dict :: Dict (a ~ a)) lcmNat :: forall n m. (KnownNat n, KnownNat m) :- KnownNat (Lcm n m) lcmNat = magic lcm lcmIsIdempotent :: forall n. Dict (n ~ Lcm n n) lcmIsIdempotent = axiom newtype GF (n :: Nat) = GF Integer instance KnownNat n => Num (GF n) where xf@(GF x) + GF y = GF $ (x+y) `mod` (natVal xf) xf@(GF x) - GF y = GF $ (x-y) `mod` (natVal xf) xf@(GF x) * GF y = GF $ (x*y) `mod` (natVal xf) abs = id signum xf@(GF x) | x==0 = xf | otherwise = GF 1 fromInteger = GF x :: GF 5 x = GF 3 y :: GF 5 y = GF 4 foo :: (KnownNat m, KnownNat n) => GF m -> GF n -> GF (Lcm m n) foo m@(GF x) n@(GF y) = GF $ (x*y) `mod` (lcm (natVal m) (natVal n)) bar :: (KnownNat m) => GF m -> GF m -> GF m bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) }}} Compiling this (with either GHC 8.0.1, 8.0.2, 8.2.1, or HEAD) gives you a downright puzzling type error: {{{ $ /opt/ghc/head/bin/ghci Bug.hs GHCi, version 8.3.20170509: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:63:21: error: • Couldn't match type ‘m’ with ‘Lcm m m’ ‘m’ is a rigid type variable bound by the type signature for: bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m at Bug.hs:62:1-44 Expected type: GF m Actual type: GF (Lcm m m) • In the first argument of ‘(-)’, namely ‘foo x y’ In the expression: foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) In an equation for ‘bar’: bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) • Relevant bindings include y :: GF m (bound at Bug.hs:63:17) x :: GF m (bound at Bug.hs:63:6) bar :: GF m -> GF m -> GF m (bound at Bug.hs:63:1) | 63 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) | ^^^^^^^ Bug.hs:63:31: error: • Could not deduce: m ~ Lcm m m from the context: m ~ Lcm m m bound by a type expected by the context: m ~ Lcm m m => GF m at Bug.hs:63:31-85 ‘m’ is a rigid type variable bound by the type signature for: bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m at Bug.hs:62:1-44 Expected type: GF m Actual type: GF (Lcm m m) • In the first argument of ‘(\\)’, namely ‘foo y x’ In the first argument of ‘(\\)’, namely ‘foo y x \\ lcmNat @m @m’ In the second argument of ‘(-)’, namely ‘foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m)’ • Relevant bindings include y :: GF m (bound at Bug.hs:63:17) x :: GF m (bound at Bug.hs:63:6) bar :: GF m -> GF m -> GF m (bound at Bug.hs:63:1) | 63 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) | ^^^^^^^ }}} In particular, I'd like to emphasize this part: {{{ • Could not deduce: m ~ Lcm m m from the context: m ~ Lcm m m }}} Wat!? Surely, GHC can deduce `m ~ Lcm m m` from `m ~ Lcm m m`? I decided to flip on `-fprint-explicit-kinds` and see if there was some other issue lurking beneath the surface: {{{ $ /opt/ghc/head/bin/ghci Bug.hs -fprint-explicit-kinds GHCi, version 8.3.20170509: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:63:21: error: • Couldn't match type ‘m’ with ‘Lcm m m’ ‘m’ is a rigid type variable bound by the type signature for: bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m at Bug.hs:62:1-44 Expected type: GF m Actual type: GF (Lcm m m) • In the first argument of ‘(-)’, namely ‘foo x y’ In the expression: foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) In an equation for ‘bar’: bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) • Relevant bindings include y :: GF m (bound at Bug.hs:63:17) x :: GF m (bound at Bug.hs:63:6) bar :: GF m -> GF m -> GF m (bound at Bug.hs:63:1) | 63 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) | ^^^^^^^ Bug.hs:63:31: error: • Could not deduce: (m :: Nat) ~~ (Lcm m m :: Nat) from the context: m ~ Lcm m m bound by a type expected by the context: m ~ Lcm m m => GF m at Bug.hs:63:31-85 ‘m’ is a rigid type variable bound by the type signature for: bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m at Bug.hs:62:1-44 Expected type: GF m Actual type: GF (Lcm m m) • In the first argument of ‘(\\)’, namely ‘foo y x’ In the first argument of ‘(\\)’, namely ‘foo y x \\ lcmNat @m @m’ In the second argument of ‘(-)’, namely ‘foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m)’ • Relevant bindings include y :: GF m (bound at Bug.hs:63:17) x :: GF m (bound at Bug.hs:63:6) bar :: GF m -> GF m -> GF m (bound at Bug.hs:63:1) | 63 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) | }}} Well, not a whole lot changed. We now have this, slightly more specific error instead: {{{ • Could not deduce: (m :: Nat) ~~ (Lcm m m :: Nat) from the context: m ~ Lcm m m }}} Huh, this is flummoxing. Surely `(m :: Nat) ~~ (Lcm m m :: Nat)` ought to be the same thing as `m ~ Lcm m m`, right? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 14:13:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 14:13:08 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.1fe18c6e9876297f6bdad747b0ea6734@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: jstolarek Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6024 | Differential Rev(s): Phab:D1778 Wiki Page: | GhcKinds/KindsWithoutData | -------------------------------------+------------------------------------- Changes (by kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 14:24:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 14:24:29 -0000 Subject: [GHC] #13679: Kill eqIfaceType Message-ID: <046.77537b9b11d93850811e91290669da0c@haskell.org> #13679: Kill eqIfaceType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `IfaceType.eqIfaceType` seems to be dead code. Can we kill it? It appears to be something to do with backpack. It would be good to kill it because eqType is subtle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 14:30:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 14:30:35 -0000 Subject: [GHC] #13680: Can't use TypeApplications with empty list expression Message-ID: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> #13680: Can't use TypeApplications with empty list expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Why can't I do this? {{{#!hs {-# LANGUAGE TypeApplications #-} module Bug where foo :: [Int] foo = [] @Int }}} Compiling this with GHC 8.0.1, 8.0.2, 8.2.1, or HEAD gives me: {{{ $ /opt/ghc/head/bin/ghci Bug2.hs GHCi, version 8.3.20170509: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug2.hs, interpreted ) Bug2.hs:5:7: error: • Cannot apply expression of type ‘[a0]’ to a visible type argument ‘Int’ • In the expression: [] @Int In an equation for ‘foo’: foo = [] @Int | 5 | foo = [] @Int | ^^^^^^^ }}} This seems really strange, since I can use `TypeApplications` with expressions like `Nothing @Int` without issues. According to GHCi: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.3.20170509: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XTypeApplications -fprint-explicit-foralls λ> :type +v [] [] :: forall {a}. [a] λ> :type +v Nothing Nothing :: forall a. Maybe a }}} The type variable for `[]` isn't visible! But I don't see any reason why it shouldn't be, especially since, conceptually, the data type declaration for lists is: {{{#!hs data [] a = [] | a : [a] }}} I suspect that `[]`'s tyvar binder visibility is not wired into GHC correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 14:42:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 14:42:55 -0000 Subject: [GHC] #13680: Can't use TypeApplications with empty list expression In-Reply-To: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> References: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> Message-ID: <065.76ab1d4773bab04d94681988e6bed918@haskell.org> #13680: Can't use TypeApplications with empty list expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I wish type application worked with a more things, see #11409 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 14:46:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 14:46:48 -0000 Subject: [GHC] #13680: Can't use TypeApplications with empty list expression In-Reply-To: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> References: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> Message-ID: <065.1fcc59cc9dc81fd9edf9c5dd61f28c6d@haskell.org> #13680: Can't use TypeApplications with empty list expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Indeed. However, I think #11409 is unrelated to the issue at hand here. Using `TypeApplications` with numeric literals is tricky due to the desugaring down to `fromInteger` that has to take place, whereas there's no such obstacle here, as far as I understand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 14:49:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 14:49:50 -0000 Subject: [GHC] #13680: Can't use TypeApplications with empty list expression In-Reply-To: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> References: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> Message-ID: <065.5baeb231e95fcca1d22b05a55542a2f0@haskell.org> #13680: Can't use TypeApplications with empty list expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Yes for lists it's more of a no-brainer, as you say `[]` is conceptually a constructor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 14:50:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 14:50:41 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.e16b8fe52c456969abf472439da16c75@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: jstolarek Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6024 | Differential Rev(s): Phab:D1778 Wiki Page: | GhcKinds/KindsWithoutData | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 14:51:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 14:51:30 -0000 Subject: [GHC] #13679: Kill eqIfaceType In-Reply-To: <046.77537b9b11d93850811e91290669da0c@haskell.org> References: <046.77537b9b11d93850811e91290669da0c@haskell.org> Message-ID: <061.cc1c7193f41bb54bce78aa8ca3095227@haskell.org> #13679: Kill eqIfaceType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Yes, this is old code from when we tried to check type equality prior to typechecking the iface. Backpack is taking a different approach now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 15:05:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 15:05:57 -0000 Subject: [GHC] #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to In-Reply-To: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> References: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> Message-ID: <065.2d4037b2833d0c625405462af686d165@haskell.org> #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to -------------------------------------+------------------------------------- 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: 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 program is wrong, but the error message also is wrong. Because `Lcm` is a nullary type family, the constraint `m ~ Lcm m m` is morally equivalent to `m ~ Either m m`. This constraint is an occurs-check failure and is surely going to lead to an error. It seems that the error- reporting code is mischaracterizing it, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 15:16:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 15:16:02 -0000 Subject: [GHC] #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to In-Reply-To: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> References: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> Message-ID: <065.75aa517d6cd4797ce6abd3dbcac8cb63@haskell.org> #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to -------------------------------------+------------------------------------- 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): > This constraint is an occurs-check failure and is surely going to lead to an error. Ah, that's a good point. I forgot that `Lcm m m` doesn't reduce as a type family (you're only ever to get out the `lcm` of `m` and `m` at the value level by using `knownNat` with the reflection-style trickery in `magic`, but this doesn't work at the type level). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 15:34:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 15:34:12 -0000 Subject: [GHC] #13681: Remove deprecated ForceSpecConstr Message-ID: <049.c8d6f6a3a96e7a7cae56561f41f485a6@haskell.org> #13681: Remove deprecated ForceSpecConstr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: SpecConstr | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is a note at the top of `SpecConstr` which says {{{ ToDo [Oct 2013] ~~~~~~~~~~~~~~~ 1. Nuke ForceSpecConstr for good (it is subsumed by GHC.Types.SPEC in ghc-prim) 2. Nuke NoSpecConstr }}} `ForceSpecConstr` still exists so this ticket is to track the progress made on removing it. It isn't clear to me why it is ok to get rid of `NoSpecConstr` (which prevents SpecConstr firing) either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 15:35:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 15:35:10 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.83f7f601b12c4c8470bf9c58e19ad88a@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, yes. Thanks for point this out. Indeed that is a rather significant jump and it shouldn't be hard to work out what it's from, given that there are only 300 commits or so between the releases. That being said, having had a brief look through the commits, nothing in particular jumps out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 16:11:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 16:11:59 -0000 Subject: [GHC] #13661: User manual warnings In-Reply-To: <046.a508cf314fe89c8eac2361ee70eaeaa8@haskell.org> References: <046.a508cf314fe89c8eac2361ee70eaeaa8@haskell.org> Message-ID: <061.a6e23ad13ea44a4a43c7197045c302b6@haskell.org> #13661: User manual warnings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): {{{ WARNING: Bullet list ends without a blank line; unexpected unindent. /5playpen/simonpj/HEAD-4/docs/users_guide/using-warnings.rst:4: SEVERE: Duplicate ID: "ghc-flag--Werror". /5playpen/simonpj/HEAD-4/docs/users_guide/using-warnings.rst:4: SEVERE: Duplicate ID: "ghc-flag--Wwarn". }}} I've fixed these. {{{ /5playpen/simonpj/HEAD-4/docs/users_guide/profiling.rst:507: WARNING: Pygments lexer name u'json' is not known }}} I suspect this is just due to an old Pygments version; `json` is only supported by 1.4.2 and later. The warning is pretty harmless though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 16:13:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 16:13:24 -0000 Subject: [GHC] #13661: User manual warnings In-Reply-To: <046.a508cf314fe89c8eac2361ee70eaeaa8@haskell.org> References: <046.a508cf314fe89c8eac2361ee70eaeaa8@haskell.org> Message-ID: <061.4adda3ddefd6679d96f5e3caa6c9b76c@haskell.org> #13661: User manual warnings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Closed with 476307cee7ff142b0eff91d45fddf17775417814. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 16:14:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 16:14:02 -0000 Subject: [GHC] #13661: User manual warnings In-Reply-To: <046.a508cf314fe89c8eac2361ee70eaeaa8@haskell.org> References: <046.a508cf314fe89c8eac2361ee70eaeaa8@haskell.org> Message-ID: <061.c40e387bdd1d2ca9099d2fcb5a9835a4@haskell.org> #13661: User manual warnings -------------------------------------+------------------------------------- Reporter: simonpj | 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 17:10:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 17:10:59 -0000 Subject: [GHC] #13682: When printf "%g" with trailing 0 number, decial point be printed. Message-ID: <050.490573f64c08d47bec1fad0af5100e99@haskell.org> #13682: When printf "%g" with trailing 0 number, decial point be printed. ----------------------------------------+--------------------------------- Reporter: nakaji_dayo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Keywords: printf | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- C lang's printf function doesn't print decimal point if only trailing 0s. But GHC does. {{{ Prelude Text.Printf> :m + Text.Printf Prelude Text.Printf> printf "%g\n" 2.0 2.0 }}} {{{ #include int main() { printf("%g\n", 2.0); return 0; } // output: 2 }}} Is this bug? Should printf be compatible with C? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 17:50:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 17:50:09 -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.33b17c7529b79b748ed80f9c876fc7f4@haskell.org> #13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Frankly, I've been surprised by the converse of this bug: GHC doesn't recompile when I request different optimization options. I can see the argument for a "go fast" mode, which uses any existing build products to avoid recompilation if at all possible, but it's not clear to me that this should be the default behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 19:04:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 19:04:23 -0000 Subject: [GHC] #13680: Can't use TypeApplications with empty list expression In-Reply-To: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> References: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> Message-ID: <065.56b001461c931014d4486cd7fdafbb16@haskell.org> #13680: Can't use TypeApplications with empty list expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): A have a (very slight) hunch what might be happening here. `[]` is wired in to GHC [http://git.haskell.org/ghc.git/blob/4d9167b087abd2f4dad4ccfaba7bbde177fd2797:/compiler/prelude/TysWiredIn.hs#l1425 here]: {{{#!hs nilDataCon :: DataCon nilDataCon = pcDataCon nilDataConName alpha_tyvar [] listTyCon }}} And if you follow the definition of `pcDataCon` deep enough, you'll discover it eventually calls [http://git.haskell.org/ghc.git/blob/4d9167b087abd2f4dad4ccfaba7bbde177fd2797:/compiler/prelude/TysWiredIn.hs#l513 this code]: {{{#!hs pcDataConWithFixity' :: Bool -> Name -> Unique -> RuntimeRepInfo -> [TyVar] -> [TyVar] -> [Type] -> TyCon -> DataCon -- The Name should be in the DataName name space; it's the name -- of the DataCon itself. pcDataConWithFixity' declared_infix dc_name wrk_key rri tyvars ex_tyvars arg_tys tycon = data_con where data_con = mkDataCon dc_name declared_infix prom_info (map (const no_bang) arg_tys) [] -- No labelled fields (mkTyVarBinders Specified tyvars) (mkTyVarBinders Specified ex_tyvars) [] -- No equality spec [] -- No theta arg_tys (mkTyConApp tycon (mkTyVarTys tyvars)) rri tycon [] -- No stupid theta (mkDataConWorkId wrk_name data_con) NoDataConRep -- Wired-in types are too simple to need wrappers no_bang = HsSrcBang NoSourceText NoSrcUnpack NoSrcStrict wrk_name = mkDataConWorkerName data_con wrk_key prom_info = mkPrelTyConRepName dc_name }}} The use of `Specified` is a tad suspicious. I tried changing it to `Required`, but unfortunately, the bug still persists after this. So there must be something else that explains this behavior, but it eludes me for now... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 19:21:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 19:21:25 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.1e0b03ac6f65ded0af3d0e3277ddfa92@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Phab:D3550 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:19 simonpj]: > Fine -- whatever the resolution: > > * could the Note be made specific about the INLINE/INLINABLE choice, and point to this ticket? and > * could the calls to `isInlinePragma` have a pointer to that Note? Yes, absolutely. I'm just hoping for a bit more clarity on why this is the right way to do it, so I can explain properly in the note. I'll make a stab at it anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 19:40:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 19:40:26 -0000 Subject: [GHC] #13675: Binary.get(TyClDecl): ForeignType In-Reply-To: <045.a58aeb2a4dfc7f06891fc02dfa70f144@haskell.org> References: <045.a58aeb2a4dfc7f06891fc02dfa70f144@haskell.org> Message-ID: <060.fa5080f4435913f318ce12bc7ba3eecc@haskell.org> #13675: Binary.get(TyClDecl): ForeignType -------------------------------------+------------------------------------- Reporter: Neidon | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: I'm afraid I can't reproduce this as-is. I end up failing with missing interface files, {{{ /tmp/stack6279/cryptonite-0.22/Crypto/Number/Serialize/Internal.hs:19:1: error: Failed to load interface for ‘Data.Memory.PtrMethods’ There are files missing in the ‘memory-0.14.1’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. }}} Have you been able to reproduce this after wiping your `.stack` directory? I don't see how the compiler could have possibly written out the interface file in question and this is the first time I've ever seen this error. It would be nice to rule out a simple bit-flip. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 19:56:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 19:56:41 -0000 Subject: [GHC] #13675: Binary.get(TyClDecl): ForeignType In-Reply-To: <045.a58aeb2a4dfc7f06891fc02dfa70f144@haskell.org> References: <045.a58aeb2a4dfc7f06891fc02dfa70f144@haskell.org> Message-ID: <060.450cd887039704bbee0e456ed53d630d@haskell.org> #13675: Binary.get(TyClDecl): ForeignType -------------------------------------+------------------------------------- Reporter: Neidon | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Neidon): > Have you been able to reproduce this after wiping your .stack directory? No. I did `rm -rf ~/.stack`, then rebuilt the whole project from scratch `stack build --install-ghc` and the problem was gone. I've tried this just now on the same machine and I'm also getting missed interface files, albeit for a different package. {{{ /tmp/stack13960/cpphs-1.20.4/Language/Preprocessor/Cpphs/ReadFirst.hs:21:1: error: Failed to load interface for ‘System.Directory’ There are files missing in the ‘directory-1.3.1.0’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. }}} So I don't know how to reproduce this anymore. For future reference, it would be nice to know what I should include in the dumps of the computer's state aside from `~/.stack` and the project directory, but for now this bug should probably be closed and reopened only if someone else encounters it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 21:36:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 21:36:58 -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.d21881932763653b8a2c6ef1675e181d@haskell.org> #13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): I think I will be happy with whatever people come up with here. I filed the bug originally as I was surprised by the change in behavior. As Simon wrote above: it would be good if the user manual documented the behaviour and the underlying principles. And describes how to work around it if you want something different. As Ben wrote above ideally the final fix will also address the converse of this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 22:03:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 22:03:34 -0000 Subject: [GHC] #13675: Binary.get(TyClDecl): ForeignType In-Reply-To: <045.a58aeb2a4dfc7f06891fc02dfa70f144@haskell.org> References: <045.a58aeb2a4dfc7f06891fc02dfa70f144@haskell.org> Message-ID: <060.b19123468979fc2b7347683add9e0948@haskell.org> #13675: Binary.get(TyClDecl): ForeignType -------------------------------------+------------------------------------- Reporter: Neidon | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: worksforme | 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: infoneeded => closed * resolution: => worksforme Comment: I admit that I don't use stack myself and know relatively little about how it invokes ghc. From what I do know I would have thought that `~/.stack` would be sufficient, so I was a bit surprised when your (very complete; thank you!) reproduction instructions failed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 22:52:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 22:52:43 -0000 Subject: [GHC] #13683: Use epoll rather than poll where appropriate Message-ID: <045.c2ab45ba7445ee160d1efae06a34ff10@haskell.org> #13683: Use epoll rather than poll where appropriate ----------------------------------------+--------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Linux supports an `epoll` system call that's supposed to scale better to large numbers of watched file descriptors than `poll`. We should probably use it when available and appropriate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 23:57:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 23:57:02 -0000 Subject: [GHC] #13684: Core lint error with defer-typed-holes and coerce Message-ID: <051.94c6492a321888baea1a5ea5ba703850@haskell.org> #13684: Core lint error with defer-typed-holes and coerce -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Options_GHC -dcore-lint -fdefer-typed-holes #-} {-# Language FlexibleInstances, UndecidableInstances, MultiParamTypeClasses, GeneralizedNewtypeDeriving #-} import Data.Traversable import Control.Lens.Indexed import Control.Lens.Fold (ifoldMapOf) import Control.Lens.Setter (iover) newtype Foo a = F (WrapITraversable [] a) newtype WrapITraversable f a = WIT (f a) instance TraversableWithIndex i f => Functor (WrapITraversable f) where fmap = fmapDefault instance TraversableWithIndex i f => Foldable (WrapITraversable f) where foldMap = foldMapDefault instance TraversableWithIndex i f => Traversable (WrapITraversable f) where traverse = itraverse . const instance TraversableWithIndex i f => FoldableWithIndex i (WrapITraversable f) where ifoldMap = ifoldMapOf itraversed instance TraversableWithIndex i f => FunctorWithIndex i (WrapITraversable f) where imap = iover itraversed instance TraversableWithIndex i f => TraversableWithIndex i (WrapITraversable f) where itraverse = coerce itraverse }}} causes with `lens 4.14` or `4.15.1`, GHC 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 10 23:57:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 May 2017 23:57:50 -0000 Subject: [GHC] #13684: Core lint error with defer-typed-holes and coerce In-Reply-To: <051.94c6492a321888baea1a5ea5ba703850@haskell.org> References: <051.94c6492a321888baea1a5ea5ba703850@haskell.org> Message-ID: <066.f203310e267d5c1fbf660b3e20a30f5c@haskell.org> #13684: Core lint error with defer-typed-holes and coerce -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "t0OK.log" added. stdout from ghci t0Ok.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 00:11:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 00:11:05 -0000 Subject: [GHC] #13682: When printf "%g" with trailing 0 number, decial point be printed. In-Reply-To: <050.490573f64c08d47bec1fad0af5100e99@haskell.org> References: <050.490573f64c08d47bec1fad0af5100e99@haskell.org> Message-ID: <065.55e47c5536577552a8bc54080f022f67@haskell.org> #13682: When printf "%g" with trailing 0 number, decial point be printed. -------------------------------------+------------------------------------- Reporter: nakaji_dayo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: printf Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I don't believe we make any claim that `Text.Printf.printf` will reflect the behavior of C's `printf`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 01:36:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 01:36:58 -0000 Subject: [GHC] #13683: Use epoll rather than poll where appropriate In-Reply-To: <045.c2ab45ba7445ee160d1efae06a34ff10@haskell.org> References: <045.c2ab45ba7445ee160d1efae06a34ff10@haskell.org> Message-ID: <060.ee85f0afb1547034275e7df07d270004@haskell.org> #13683: Use epoll rather than poll where appropriate -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): The event manager already does. See `GHC.Event.Epoll`. What usage of `poll` are you referring to? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 01:52:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 01:52:19 -0000 Subject: [GHC] #13685: ghc: panic Message-ID: <051.c61ea8203470cab8ee010e6dae14f368@haskell.org> #13685: ghc: panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A friendly compiler asked me to report {{{#!hs {-# Language KindSignatures, TypeInType, MagicHash #-} module A where import Data.Kind import GHC.Types i :: (a :: TYPE DoubleRep) -> a i x = x main = print (D# (i 3.0##)) }}} panics {{{ $ ghci -ignore-dot-ghci /tmp/A.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling A ( /tmp/A.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): getIdFromTrivialExpr 3.0## 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 May 11 04:51:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 04:51:01 -0000 Subject: [GHC] #13683: Use epoll rather than poll where appropriate In-Reply-To: <045.c2ab45ba7445ee160d1efae06a34ff10@haskell.org> References: <045.c2ab45ba7445ee160d1efae06a34ff10@haskell.org> Message-ID: <060.3202e21810ce405af72bc813a1873afd@haskell.org> #13683: Use epoll rather than poll where appropriate -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): bgamari, see `fdReady` in `libraries/base/cbits/inputReady.c`. I don't know if `epoll` is appropriate there (I gather `epoll` is only for non- files?), but I ran into it in a commit shortly before 8.0.2 and looked up what the things were and figured it was worth checking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 05:07:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 05:07:15 -0000 Subject: [GHC] #13686: Compile a few modules for profiling unconditionally Message-ID: <045.5af3feac5c5ebe385b098ccfc6d200cc@haskell.org> #13686: Compile a few modules for profiling unconditionally -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When GHC is built without enabling profiling of the libraries, it is utterly impossible to compile anything ''with'' profiling. I would like to compile just enough libraries with profiling, unconditionally, to be able to compile any module with profiling as long as it satisfies approximately three conditions: 1. It uses `NoImplicitPrelude`. 2. It does not import any modules from a boot package. 3. It does not use `TemplateHaskell` (I'm not sure if this is necessary, but I wouldn't be surprised if it were). To make this work, I think we would need to compile at least `GHC.Types` and the `Data.Typeable.Internal` for profiling in all cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 05:09:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 05:09:16 -0000 Subject: [GHC] #13686: Compile a few modules for profiling unconditionally In-Reply-To: <045.5af3feac5c5ebe385b098ccfc6d200cc@haskell.org> References: <045.5af3feac5c5ebe385b098ccfc6d200cc@haskell.org> Message-ID: <060.1c7a5601a5dfca266c81874d1e4c01ff@haskell.org> #13686: Compile a few modules for profiling unconditionally -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | 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: | -------------------------------------+------------------------------------- Description changed by dfeuer: @@ -14,0 +14,4 @@ + + The point of this is that it would be convenient to be able to work on + small profiling issues without having to build a tree specifically for the + job: a `devel2` or `quick` build would be sufficient. New description: When GHC is built without enabling profiling of the libraries, it is utterly impossible to compile anything ''with'' profiling. I would like to compile just enough libraries with profiling, unconditionally, to be able to compile any module with profiling as long as it satisfies approximately three conditions: 1. It uses `NoImplicitPrelude`. 2. It does not import any modules from a boot package. 3. It does not use `TemplateHaskell` (I'm not sure if this is necessary, but I wouldn't be surprised if it were). To make this work, I think we would need to compile at least `GHC.Types` and the `Data.Typeable.Internal` for profiling in all cases. The point of this is that it would be convenient to be able to work on small profiling issues without having to build a tree specifically for the job: a `devel2` or `quick` build would be sufficient. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 05:10:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 05:10:02 -0000 Subject: [GHC] #13686: Compile a few modules for profiling unconditionally In-Reply-To: <045.5af3feac5c5ebe385b098ccfc6d200cc@haskell.org> References: <045.5af3feac5c5ebe385b098ccfc6d200cc@haskell.org> Message-ID: <060.ad7dc7682ed41d11f7644aba4147b756@haskell.org> #13686: Compile a few modules for profiling unconditionally -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | 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: | -------------------------------------+------------------------------------- Description changed by dfeuer: @@ -13,1 +13,1 @@ - and the `Data.Typeable.Internal` for profiling in all cases. + and `Data.Typeable.Internal` for profiling in all cases. New description: When GHC is built without enabling profiling of the libraries, it is utterly impossible to compile anything ''with'' profiling. I would like to compile just enough libraries with profiling, unconditionally, to be able to compile any module with profiling as long as it satisfies approximately three conditions: 1. It uses `NoImplicitPrelude`. 2. It does not import any modules from a boot package. 3. It does not use `TemplateHaskell` (I'm not sure if this is necessary, but I wouldn't be surprised if it were). To make this work, I think we would need to compile at least `GHC.Types` and `Data.Typeable.Internal` for profiling in all cases. The point of this is that it would be convenient to be able to work on small profiling issues without having to build a tree specifically for the job: a `devel2` or `quick` build would be sufficient. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 09:16:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 09:16:26 -0000 Subject: [GHC] #13687: GHC internal error: associated type not in scope during typechecking Message-ID: <046.d6baac6c7dc957f56e65b2abe23eeba1@haskell.org> #13687: GHC internal error: associated type not in scope during typechecking -------------------------------------+------------------------------------- Reporter: mrkgnao | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From a larger snippet of code: {{{#!hs type family Strategy' a b n where Strategy' a b Zero = St a b -- this is where the error occurs Strategy' a b (Succ n) = Strategy' a b n <| ReverseArgs (Strategy' b a n) <| Combine (Strategy' a a n) (Strategy' b b n) class DefinedStrategy a b where type St }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 09:17:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 09:17:33 -0000 Subject: [GHC] #13687: GHC internal error: associated type not in scope during typechecking In-Reply-To: <046.d6baac6c7dc957f56e65b2abe23eeba1@haskell.org> References: <046.d6baac6c7dc957f56e65b2abe23eeba1@haskell.org> Message-ID: <061.f604dcb6a857f033b2c86e4bca9d8334@haskell.org> #13687: GHC internal error: associated type not in scope during typechecking -------------------------------------+------------------------------------- Reporter: mrkgnao | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by mrkgnao: @@ -1,1 +1,1 @@ - From a larger snippet of code: + Trying to add a really bad associated type to a class as follows @@ -14,0 +14,22 @@ + + triggers + + {{{ + + /home/mrkgnao/code/haskell/noether/library/Algebra/DeOverlap.hs:126:24: + error: + • GHC internal error: ‘St’ is not in scope during type checking, but + it passed the renamer + tcl_env of environment: [amtJ :-> Type variable ‘a’ = a, + amtK :-> Type variable ‘b’ = b, roW :-> + ATcTyCon Strategy'] + • In the type ‘St a b’ + In the type family declaration for ‘Strategy'’ + + /home/mrkgnao/code/haskell/noether/library/Algebra/DeOverlap.hs:132:1: + error: + • The associated type ‘St’ + mentions none of the type or kind variables of the class + ‘DefinedStrategy a b’ + • In the class declaration for ‘DefinedStrategy’ + }}} New description: Trying to add a really bad associated type to a class as follows {{{#!hs type family Strategy' a b n where Strategy' a b Zero = St a b -- this is where the error occurs Strategy' a b (Succ n) = Strategy' a b n <| ReverseArgs (Strategy' b a n) <| Combine (Strategy' a a n) (Strategy' b b n) class DefinedStrategy a b where type St }}} triggers {{{ /home/mrkgnao/code/haskell/noether/library/Algebra/DeOverlap.hs:126:24: error: • GHC internal error: ‘St’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [amtJ :-> Type variable ‘a’ = a, amtK :-> Type variable ‘b’ = b, roW :-> ATcTyCon Strategy'] • In the type ‘St a b’ In the type family declaration for ‘Strategy'’ /home/mrkgnao/code/haskell/noether/library/Algebra/DeOverlap.hs:132:1: error: • The associated type ‘St’ mentions none of the type or kind variables of the class ‘DefinedStrategy a b’ • In the class declaration for ‘DefinedStrategy’ }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 11:42:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 11:42:06 -0000 Subject: [GHC] #13687: GHC internal error: associated type not in scope during typechecking In-Reply-To: <046.d6baac6c7dc957f56e65b2abe23eeba1@haskell.org> References: <046.d6baac6c7dc957f56e65b2abe23eeba1@haskell.org> Message-ID: <061.663bfad6bc533bc67d21edbcda10b2fb@haskell.org> #13687: GHC internal error: associated type not in scope during typechecking -------------------------------------+------------------------------------- Reporter: mrkgnao | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12867 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12867 Comment: Thanks for the bug report. This is a duplicate of #12867, which has been fixed in GHC 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 11:49:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 11:49:46 -0000 Subject: [GHC] #13684: Core lint error with defer-typed-holes and coerce In-Reply-To: <051.94c6492a321888baea1a5ea5ba703850@haskell.org> References: <051.94c6492a321888baea1a5ea5ba703850@haskell.org> Message-ID: <066.3b97c4187d5ad601c45d3acd17f8d280@haskell.org> #13684: Core lint error with defer-typed-holes and coerce -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: I can't reproduce this on GHC 8.0.2 or 8.2.1. (BTW, in the future, you might want to verify that these Core Lint errors happen in 8.0.2 before posting to Trac, since 8.0.2 fixed a good number of these kinds of issues.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 12:19:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 12:19:54 -0000 Subject: [GHC] #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to In-Reply-To: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> References: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> Message-ID: <065.a6243c05213c6d418d9cb02e9bba3287@haskell.org> #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to -------------------------------------+------------------------------------- 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, I'm not sure if I find this occurs check explanation entirely satisfactory. SkorikGG points out [https://github.com/ekmett/constraints/issues/55#issuecomment-300767277 here] that you can make this program work with a slight tweak: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} import Data.Proxy import Data.Type.Equality import GHC.Exts (Constraint) import GHC.TypeLits import Unsafe.Coerce (unsafeCoerce) data Dict :: Constraint -> * where Dict :: a => Dict a infixr 9 :- newtype a :- b = Sub (a => Dict b) -- | Given that @a :- b@, derive something that needs a context @b@, using the context @a@ (\\) :: a => (b => r) -> (a :- b) -> r r \\ Sub Dict = r newtype Magic n = Magic (KnownNat n => Dict (KnownNat n)) magic :: forall n m o. (Integer -> Integer -> Integer) -> (KnownNat n, KnownNat m) :- KnownNat o magic f = Sub $ unsafeCoerce (Magic Dict) (natVal (Proxy :: Proxy n) `f` natVal (Proxy :: Proxy m)) type family Lcm :: Nat -> Nat -> Nat where axiom :: forall a b. Dict (a ~ b) axiom = unsafeCoerce (Dict :: Dict (a ~ a)) lcmNat :: forall n m. (KnownNat n, KnownNat m) :- KnownNat (Lcm n m) lcmNat = magic lcm lcmIsIdempotent :: forall n. Dict (Lcm n n ~ n) lcmIsIdempotent = axiom newtype GF (n :: Nat) = GF Integer instance KnownNat n => Num (GF n) where xf@(GF x) + GF y = GF $ (x+y) `mod` (natVal xf) xf@(GF x) - GF y = GF $ (x-y) `mod` (natVal xf) xf@(GF x) * GF y = GF $ (x*y) `mod` (natVal xf) abs = id signum xf@(GF x) | x==0 = xf | otherwise = GF 1 fromInteger = GF x :: GF 5 x = GF 3 y :: GF 5 y = GF 4 foo :: (KnownNat m, KnownNat n) => GF m -> GF n -> GF (Lcm m n) foo m@(GF x) n@(GF y) = GF $ (x*y) `mod` (lcm (natVal m) (natVal n)) dictToRefl :: Dict (a ~ b) -> a :~: b dictToRefl Dict = Refl bar :: (KnownNat m) => GF m -> GF m -> GF m bar (x :: GF m) y = castWith (apply Refl $ dictToRefl (lcmIsIdempotent :: Dict (Lcm m m ~ m))) (foo x y - foo y x) \\ lcmNat @m @m z :: GF 5 z = bar x y }}} Notice that in `bar`, we're using a trick of converting the `lcmIsIdempotent` `Dict` to a `(:~:)` using `dictToRefl`. And it's clear that we are using the fact that `Lcm m m ~ m` in order for `bar` to typecheck, but this time, GHC accepts it! Should it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 12:26:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 12:26:26 -0000 Subject: [GHC] #13684: Core lint error with defer-typed-holes and coerce In-Reply-To: <051.94c6492a321888baea1a5ea5ba703850@haskell.org> References: <051.94c6492a321888baea1a5ea5ba703850@haskell.org> Message-ID: <066.d53e0c3329475ca85fa3cd94b8c9df8e@haskell.org> #13684: Core lint error with defer-typed-holes and coerce -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Yeah I unfortunately don't have access to anything over 8.0.1 but I will soon enough -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 12:42:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 12:42:02 -0000 Subject: [GHC] #13683: Use epoll rather than poll where appropriate In-Reply-To: <045.c2ab45ba7445ee160d1efae06a34ff10@haskell.org> References: <045.c2ab45ba7445ee160d1efae06a34ff10@haskell.org> Message-ID: <060.5a0413bd880df83239cae0cee806cefb@haskell.org> #13683: Use epoll rather than poll where appropriate -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): AFAIK `fdReady` is used only by the single threaded runtime, which is a pretty low priority as far as optimization is concerned; if users want strong IO performance they should be using the threaded runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 13:00:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 13:00:46 -0000 Subject: [GHC] #13678: Overhaul the linker In-Reply-To: <047.e127759c3a4017d82c97188d47fb36ec@haskell.org> References: <047.e127759c3a4017d82c97188d47fb36ec@haskell.org> Message-ID: <062.7fb9ab4783e06c36f6771f8e3870b137@haskell.org> #13678: Overhaul the linker -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 8.3 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Moritz Angermann ): In [changeset:"094a752a1561b5cb8640648b0882cea97831226c/ghc" 094a752/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="094a752a1561b5cb8640648b0882cea97831226c" Fix iossimulator The introduction of the aarch64 linker for iOS forgot that the ios simulator was still using the x86_64/mach-o linker, which requires the use of symbol extras. Until this is overhauled (see #13678), we should revert to the symbol extras logic for x86_64-apple-ios Reviewers: austin, bgamari, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3556 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 13:36:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 13:36:07 -0000 Subject: [GHC] #12850: Panic with unboxed integers and ghci In-Reply-To: <047.0ea5f00888799dccd8ce378372f99f9b@haskell.org> References: <047.0ea5f00888799dccd8ce378372f99f9b@haskell.org> Message-ID: <062.fd1466dbb178d84b008e0f9a191bdc69@haskell.org> #12850: Panic with unboxed integers and ghci -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"2316ee1c42d7f4dc229295a5b5426dde40944dc1/ghc" 2316ee1c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2316ee1c42d7f4dc229295a5b5426dde40944dc1" Add regression test for #12850 Commit e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9 happened to fix #12850, so let's add a regression test for the program reported in #12850. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 13:38:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 13:38:07 -0000 Subject: [GHC] #12850: Panic with unboxed integers and ghci In-Reply-To: <047.0ea5f00888799dccd8ce378372f99f9b@haskell.org> References: <047.0ea5f00888799dccd8ce378372f99f9b@haskell.org> Message-ID: <062.8380ff7125f2c73d8be2c31879883688@haskell.org> #12850: Panic with unboxed integers and ghci -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: | typecheck/should_compile/T12850 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => typecheck/should_compile/T12850 * resolution: => fixed * milestone: => 8.2.1 Comment: Commit e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9 (Update levity polymorphism) happened to nab this bug. Hooray! I've added a regression test for the program in this ticket, so I'll opt to close it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 13:39:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 13:39:09 -0000 Subject: [GHC] #13685: ghc: panic In-Reply-To: <051.c61ea8203470cab8ee010e6dae14f368@haskell.org> References: <051.c61ea8203470cab8ee010e6dae14f368@haskell.org> Message-ID: <066.6b102e9e423766217c9a1d8a63cb76f6@haskell.org> #13685: ghc: panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12850 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12850 Comment: I'm closing this as a duplicate of #12850, since they're extremely similar programs. Luckily, I just noticed that #12850 (and this ticket as well) have been fixed as of GHC 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 13:41:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 13:41:50 -0000 Subject: [GHC] #13685: ghc: panic In-Reply-To: <051.c61ea8203470cab8ee010e6dae14f368@haskell.org> References: <051.c61ea8203470cab8ee010e6dae14f368@haskell.org> Message-ID: <066.737fa67a602a5ab7776eb8fd7c74146b@haskell.org> #13685: ghc: panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12850 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Excellent, thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 14:08:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 14:08:35 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.8589a1c3a1c01e6745239c3109b2a207@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3525 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Erm, the commit in 372995364c52eef15066132d7d1ea8b6760034e6 doesn't actually fix either of the programs I reported, does it? I get the same errors on a recent GHC HEAD build: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.3.20170511: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XBangPatterns -XRankNTypes -XTypeFamilies λ> let x :: forall a . a ~ Integer => forall b. b ~ Integer => (a, b); !x = (1, 2) :2:74: error: • Couldn't match expected type ‘forall b. b ~ Integer => (a, b)’ with actual type ‘(Integer, Integer)’ • In the expression: (1, 2) In a pattern binding: !x = (1, 2) • Relevant bindings include x :: forall b. b ~ Integer => (a, b) (bound at :2:70) }}} {{{ $ inplace/bin/ghc-stage2 ../Bug.hs [1 of 1] Compiling Bug ( ../Bug.hs, ../Bug.o ) ../Bug.hs:6:1: error: Overloaded signature conflicts with monomorphism restriction x :: forall a. a ~ Integer => forall b. b ~ Integer => (a, b) | 6 | x :: forall a . a ~ Integer => forall b. b ~ Integer => (a, b) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 14:13:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 14:13:42 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.0c73a358eedc75f2a4698aad333b3a24@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Good catch, arybczak! I suppose we could just touch the cache at the end of `install`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 14:21:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 14:21:52 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.b5ad5cc81ba089ac47c86503830de2d9@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3569 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * differential: => Phab:D3569 * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 14:22:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 14:22:05 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.8c0cd6122c71634183c00580dbc2c82a@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3569 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 14:46:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 14:46:00 -0000 Subject: [GHC] #13682: When printf "%g" with trailing 0 number, decial point be printed. In-Reply-To: <050.490573f64c08d47bec1fad0af5100e99@haskell.org> References: <050.490573f64c08d47bec1fad0af5100e99@haskell.org> Message-ID: <065.0e1d27f6ea592d7527d84cfc9528c268@haskell.org> #13682: When printf "%g" with trailing 0 number, decial point be printed. -------------------------------------+------------------------------------- Reporter: nakaji_dayo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: printf Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Indeed, we currently note in the documentation that the identifiers for `RealFloat` types differs from how C treats them. Quote [http://git.haskell.org/ghc.git/blob/2316ee1c42d7f4dc229295a5b5426dde40944dc1:/libraries/base/Text/Printf.hs#l226 the docs], > Note that the formatting for `RealFloat` types is currently a bit different from that of C `printf(3)`, conforming instead to `showEFloat`, `showFFloat` and **`showGFloat`** (and their alternate versions `showFFloatAlt` and **`showGFloatAlt`**). This is hard to fix: the fixed versions would format in a backward-incompatible way. **In any case the Haskell behavior is generally more sensible than the C behavior.** A brief summary of some key differences: > > * Haskell `printf` never uses the default "6-digit" precision used by C printf. > * Haskell `printf` treats the "precision" specifier as indicating the number of digits after the decimal point. > * Haskell `printf` prints the exponent of e-format numbers without a gratuitous plus sign, and with the minimum possible number of digits. > * **Haskell `printf` will place a zero after a decimal point when possible.** (Emphasis is mine.) So the `showGFloat(Alt)` functions explain the difference in behavior. Note that you can prevent Haskell `printf` from printing out trailing decimal points by using `%.0g` instead of `%g`: {{{ λ> import Text.Printf λ> printf "%.0g\n" 2.0 2 }}} Is this explanation satisfactory? If so, feel free to close the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 14:53:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 14:53:42 -0000 Subject: [GHC] #13677: Incorrect parenthesization of type in error message In-Reply-To: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> References: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> Message-ID: <065.34c965e3a1748bf2d2e6dca6d565465f@haskell.org> #13677: Incorrect parenthesization of type in error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3570 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3570 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 15:25:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 15:25:26 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.5709b4d5b5ebaa8a8cc863d593e557b0@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3569 Wiki Page: | -------------------------------------+------------------------------------- Comment (by marinelli): Wouldn't it be better to rebuild it? We'll certainly obtain a package.cache file that is consistent. We could use something like this after that for-loop in ghc.mk: {{{ "$(INSTALLED_GHC_PKG_REAL)" --global-package-db "$(INSTALLED_PACKAGE_CONF)" recache }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 15:30:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 15:30:30 -0000 Subject: [GHC] #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to In-Reply-To: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> References: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> Message-ID: <065.6c42d92dfa594e8ae9ed19c362451455@haskell.org> #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to -------------------------------------+------------------------------------- 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): I assume the difference, as usual in these kinds of tricks, is that in the workaround, GHC never gets directly asked to produce `Lcm m m ~ m` as a wanted constraint, and so never gets a chance to smell anything fishy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 15:40:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 15:40:02 -0000 Subject: [GHC] #13688: Allow splices in definition of pattern synonym Message-ID: <046.5beee9937aa2b9f772a28bdf0d66ee56@haskell.org> #13688: Allow splices in definition of pattern synonym -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- shlevy requests the ability to write, {{{#!hs pattern MyUUID = [uuid|dbf20a11-b04a-47a5-a7d6-a6f9ae7ff895|] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 16:20:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 16:20:40 -0000 Subject: [GHC] #13688: Allow splices in definition of pattern synonym In-Reply-To: <046.5beee9937aa2b9f772a28bdf0d66ee56@haskell.org> References: <046.5beee9937aa2b9f772a28bdf0d66ee56@haskell.org> Message-ID: <061.29b160767b111676a0618a5940f67571@haskell.org> #13688: Allow splices in definition of pattern synonym -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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 bgamari): * owner: (none) => bgamari @@ -2,0 +2,1 @@ + New description: shlevy requests the ability to write, {{{#!hs pattern MyUUID = [uuid|dbf20a11-b04a-47a5-a7d6-a6f9ae7ff895|] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 16:21:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 16:21:08 -0000 Subject: [GHC] #13688: Allow splices in definition of pattern synonym In-Reply-To: <046.5beee9937aa2b9f772a28bdf0d66ee56@haskell.org> References: <046.5beee9937aa2b9f772a28bdf0d66ee56@haskell.org> Message-ID: <061.e23128d6a54a484501fba612b8805942@haskell.org> #13688: Allow splices in definition of pattern synonym -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | 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): Phab:D3571 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3571 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 16:21:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 16:21:17 -0000 Subject: [GHC] #13688: Allow splices in definition of pattern synonym In-Reply-To: <046.5beee9937aa2b9f772a28bdf0d66ee56@haskell.org> References: <046.5beee9937aa2b9f772a28bdf0d66ee56@haskell.org> Message-ID: <061.fc9436f30346c7d35c3ec9749e04b6b6@haskell.org> #13688: Allow splices in definition of pattern synonym -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Template Haskell | 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): Phab:D3571 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 16:24:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 16:24:08 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.0c0f2c40cd1a5d174c457759396d1e34@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3569 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Fair point, I suppose that would be a bit more foolproof. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 18:02:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 18:02:52 -0000 Subject: [GHC] #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound In-Reply-To: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> References: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> Message-ID: <065.98ba09737c23e732cc33fc465a5d42ea@haskell.org> #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3572 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3572 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 18:14:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 18:14:47 -0000 Subject: [GHC] #13547: Lint error in arrows program In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.fa0eadde810a82ed43e7d4e79d00c74c@haskell.org> #13547: Lint error in arrows program -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #5777, #10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: 10158 => #5777, #10158 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 18:15:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 18:15:04 -0000 Subject: [GHC] #5777: core lint error with arrow notation and GADTs In-Reply-To: <045.ddc610a1c7376d3ac8e7cf64940c7d90@haskell.org> References: <045.ddc610a1c7376d3ac8e7cf64940c7d90@haskell.org> Message-ID: <060.5a898cac064fdcd68c41ac5457645234@haskell.org> #5777: core lint error with arrow notation and GADTs -------------------------------------+------------------------------------- Reporter: benmos | Owner: ross Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: arrows, Resolution: | GADTs, Arrows Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #13547 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13547 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 18:27:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 18:27:11 -0000 Subject: [GHC] #13686: Compile a few modules for profiling unconditionally In-Reply-To: <045.5af3feac5c5ebe385b098ccfc6d200cc@haskell.org> References: <045.5af3feac5c5ebe385b098ccfc6d200cc@haskell.org> Message-ID: <060.54fdd9b10d2b04857d66778b7aa821fb@haskell.org> #13686: Compile a few modules for profiling unconditionally -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In my opinion we should wait for Hadrian to implement this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 18:27:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 18:27:31 -0000 Subject: [GHC] #9450: GHC instantiates Data instances before checking hs-boot files In-Reply-To: <044.e97ab0330439b82d1df8c46c46f1a39d@haskell.org> References: <044.e97ab0330439b82d1df8c46c46f1a39d@haskell.org> Message-ID: <059.56f31442e14ae1f9f7d5984b09a1ed08@haskell.org> #9450: GHC instantiates Data instances before checking hs-boot files -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: deriving, hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #13591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13591 Comment: Interestingly, if you compile this with GHC 8.0.1 or later, you get an error described in #13591: {{{ $ /opt/ghc/8.0.1/bin/ghci HsLit.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 4] Compiling HsLit[boot] ( HsLit.hs-boot, interpreted ) [2 of 4] Compiling HsExpr[boot] ( HsExpr.hs-boot, interpreted ) [3 of 4] Compiling HsExpr ( HsExpr.hs, interpreted ) HsExpr.hs:1:1: error: instance (Data.Data.Data id, Data.Data.Data (HsLit.TypeAnnot id), Data.Data.Data (HsLit.NameAnnot id)) => Data.Data.Data (HsExpr id) -- Defined at HsExpr.hs-boot:19:10 is defined in the hs-boot file, but not in the module itself HsExpr.hs-boot:17:1: error: Type constructor ‘HsExpr’ has conflicting definitions in the module and its hs-boot file Main module: data HsExpr i = E i | E2 i Boot file: type role HsExpr nominal abstract HsExpr i The roles do not match. Roles on abstract types default to ‘representational’ in boot files. *** Exception: expectJust showModule CallStack (from HasCallStack): error, called at compiler/utils/Maybes.hs:48:27 in ghc:Maybes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 18:28:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 18:28:07 -0000 Subject: [GHC] #13591: "*** Exception: expectJust showModule" in ghci with hs-boot In-Reply-To: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> References: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> Message-ID: <063.90b4e0f9cd0f9128c2d3e8c1b2c4859b@haskell.org> #13591: "*** Exception: expectJust showModule" in ghci with hs-boot -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: ghci hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #9450 Comment: The program in #9450 also experiences this error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 18:30:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 18:30:15 -0000 Subject: [GHC] #13591: "*** Exception: expectJust showModule" in ghci with hs-boot In-Reply-To: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> References: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> Message-ID: <063.5403be348681c64a328a3a136194c9b6@haskell.org> #13591: "*** Exception: expectJust showModule" in ghci with hs-boot -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: ghci hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch Comment: lspitzner posted a fix for this issue at https://github.com/ghc/ghc/pull/37. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 18:41:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 18:41:49 -0000 Subject: [GHC] #11722: No TypeRep for unboxed tuples In-Reply-To: <047.62aa410ace38ef8cf0e4ab854da20597@haskell.org> References: <047.62aa410ace38ef8cf0e4ab854da20597@haskell.org> Message-ID: <062.8251f4a26008c501a32ef9f71c299f7b@haskell.org> #11722: No TypeRep for unboxed tuples -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12409 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: This was fixed in 8fa4bf9ab3f4ea4b208f4a43cc90857987e6d497 (Type-indexed Typeable). See `typecheck/should_compile/T11736` for a very similar test which exercises this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 19:08:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 19:08:50 -0000 Subject: [GHC] #13417: piResultTys1 In-Reply-To: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> References: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> Message-ID: <058.e32e5d252e9ea2c8dd25123eb8dbfca7@haskell.org> #13417: piResultTys1 -------------------------------------+------------------------------------- Reporter: ralf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.2 Resolution: fixed | 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 RyanGlScott): * status: merge => closed * resolution: => fixed Comment: If I'm reading this correctly, this has been fixed and merged, so I'll close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:10:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:10:12 -0000 Subject: [GHC] #12083: ghc-8.0.1-rc4: tyConRoles sees a TcTyCon In-Reply-To: <048.a4a2a5816a0aa4dfbaf2640f489bd6c3@haskell.org> References: <048.a4a2a5816a0aa4dfbaf2640f489bd6c3@haskell.org> Message-ID: <063.e60f2dd08fbc5a51bca244573f1ea303@haskell.org> #12083: ghc-8.0.1-rc4: tyConRoles sees a TcTyCon -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc4 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Yes. Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3573 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3573 Comment: Happily, commit 0c9d9dec0a924a4f34f4cff26d004143c028861a (Remove panics for TcTyCon, the fix for #13271) fixed the two programs in this ticket. I've added regression tests for them in Phab:D3573. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:21:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:21:22 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.744eaeac900cefc30f810f9e6d0d1977@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3525 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => (none) * status: merge => new Comment: Yes, it seems you are right; I should have reviewed the ticket summary before concluding that the issue was fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:33:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:33:23 -0000 Subject: [GHC] #13568: Name is reported as ambiguous and not in scope In-Reply-To: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> References: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> Message-ID: <064.5e0ee9fec21d5dbcb568e56ff87b43d9@haskell.org> #13568: Name is reported as ambiguous and not in scope -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3547 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1381c142cd8d030f9997cdc206dcad006c028bbb/ghc" 1381c142/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1381c142cd8d030f9997cdc206dcad006c028bbb" Fix incorrect ambiguity error on identically-named data constructors Given multiple in-scope constructors with the same name, say `A`, and a function of type `A -> Int`, say, the compiler reports both a "type `A` is not in scope" and (incorrectly) an ambiguity error. The latter shouldn't be there if `DataKinds` isn't enabled. This issue was recommended to me by @mpickering as a suitable first task, and the fix was also outlined in the original Trac ticket. It involved a simple reordering of the steps taken in `lookup_demoted` in `RnEnv.hs`. The fix is to make the `DataKinds` check happen earlier, ensuring that the ambiguity check doesn't happen at all if we know the constructors couldn't have been promoted. Signed-off-by: Soham Chowdhury Reviewers: mpickering, austin, bgamari Reviewed By: mpickering, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13568 Differential Revision: https://phabricator.haskell.org/D3547 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:33:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:33:23 -0000 Subject: [GHC] #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. In-Reply-To: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> References: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> Message-ID: <064.bce756b97d8c4b4e0d159734e203d711@haskell.org> #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | RebindableSyntax 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:"2fcb5c5c3f6c5a5936eeb5dc07b476e5737f12ad/ghc" 2fcb5c5c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2fcb5c5c3f6c5a5936eeb5dc07b476e5737f12ad" compiler: Do not look up fail in RnExpr if bind pattern is irrefutible. Adds a check in `rnStmt`, in sub-expr `getFailFunction`, to determine if the pattern of a bind statement is irrefutible. If so, skip looking up the `fail` name. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13649 Differential Revision: https://phabricator.haskell.org/D3553 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:33:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:33:23 -0000 Subject: [GHC] #13677: Incorrect parenthesization of type in error message In-Reply-To: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> References: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> Message-ID: <065.882e85a94f56bd4a076d964839a85f0a@haskell.org> #13677: Incorrect parenthesization of type in error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3570 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2277172ac3ea0bbeddebc9999a5d8b5f9f58afc9/ghc" 2277172a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2277172ac3ea0bbeddebc9999a5d8b5f9f58afc9" Parenthesize pretty-printed equalities when necessary Fixes #13677 by parenthesizing equalities in a sufficiently high pretty-printing context. Test Plan: make test TEST=T13677 Reviewers: goldfire, austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13677 Differential Revision: https://phabricator.haskell.org/D3570 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:33:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:33:23 -0000 Subject: [GHC] #13688: Allow splices in definition of pattern synonym In-Reply-To: <046.5beee9937aa2b9f772a28bdf0d66ee56@haskell.org> References: <046.5beee9937aa2b9f772a28bdf0d66ee56@haskell.org> Message-ID: <061.af8395408d7f81c14f00bc6dd33556de@haskell.org> #13688: Allow splices in definition of pattern synonym -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Template Haskell | 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): Phab:D3571 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"01db13586a6eab9f66101b01d1b0584f334d5d25/ghc" 01db135/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="01db13586a6eab9f66101b01d1b0584f334d5d25" Allow spliced patterns in pattern synonyms This ended up being quite simple. Reviewers: austin, goldfire, mpickering Subscribers: rwbarton, shlevy, thomie GHC Trac Issues: #13688 Differential Revision: https://phabricator.haskell.org/D3571 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:33:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:33:23 -0000 Subject: [GHC] #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound In-Reply-To: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> References: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> Message-ID: <065.072fb27a81f7e9c5918552d02cb6d8c6@haskell.org> #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3572 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"eaf9cc4240019c2e91922ef38ae7236b59d59bdd/ghc" eaf9cc42/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eaf9cc4240019c2e91922ef38ae7236b59d59bdd" Fix collect_lpat's treatment of HsSplicedPats `collect_lpat` was missing a case for `HsSplicedPat`, which caused incorrect renaming of TH-spliced pattern variables. Fixes #13473. Test Plan: make test TEST=T13473 Reviewers: facundominguez, austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13473 Differential Revision: https://phabricator.haskell.org/D3572 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:33:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:33:23 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.907558967a2de9867aeeaa565dfdb337@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3525 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3e79fe42b907653d97cd3a5496a8f133320354eb/ghc" 3e79fe42/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3e79fe42b907653d97cd3a5496a8f133320354eb" Fix up tests for #13594 This adds the GHCi variant of the failing program in #13594. Also, I inadvertently changed the T13594 test previously introduced in a way that made it no longer faithfully test the ticket as written. Fix this. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:33:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:33:23 -0000 Subject: [GHC] #9287: changed dependency generation In-Reply-To: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> References: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> Message-ID: <060.d5cc9eda30a2a8b70a4041ebbead473e@haskell.org> #9287: changed dependency generation -------------------------------------+------------------------------------- Reporter: maeder | Owner: simonmar Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Driver | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #9749, #7381 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b9d1dae0c0ee0bd3b7e9be3c83ce932d837944f1/ghc" b9d1dae0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b9d1dae0c0ee0bd3b7e9be3c83ce932d837944f1" users-guide: Document requirement of at least one -dep-suffix This requirement was introduced around 7.8 but was never documented. Resolves #9287. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:33:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:33:26 -0000 Subject: [GHC] #13591: "*** Exception: expectJust showModule" in ghci with hs-boot In-Reply-To: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> References: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> Message-ID: <063.fad04dd5b8fa429d144b072b9965475c@haskell.org> #13591: "*** Exception: expectJust showModule" in ghci with hs-boot -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: ghci hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ezyang (added) Comment: Edward, you know about `hs-boot` stuff. Might you look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:33:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:33:52 -0000 Subject: [GHC] #9287: changed dependency generation In-Reply-To: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> References: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> Message-ID: <060.d450fb29d17944a2d62bf3bc50e3401e@haskell.org> #9287: changed dependency generation -------------------------------------+------------------------------------- Reporter: maeder | Owner: simonmar Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Driver | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #9749, #7381 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => merge * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:34:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:34:09 -0000 Subject: [GHC] #13688: Allow splices in definition of pattern synonym In-Reply-To: <046.5beee9937aa2b9f772a28bdf0d66ee56@haskell.org> References: <046.5beee9937aa2b9f772a28bdf0d66ee56@haskell.org> Message-ID: <061.46d6788be7bc51f8485826b1aa802799@haskell.org> #13688: Allow splices in definition of pattern synonym -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | 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:D3571 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:34:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:34:48 -0000 Subject: [GHC] #13677: Incorrect parenthesization of type in error message In-Reply-To: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> References: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> Message-ID: <065.fe0727a150ae35e37fbda468fe523b9e@haskell.org> #13677: Incorrect parenthesization of type in error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3570 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:35:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:35:56 -0000 Subject: [GHC] #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. In-Reply-To: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> References: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> Message-ID: <064.222d47118ad0e72ff03c0db8b92bc4e2@haskell.org> #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | RebindableSyntax Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3553 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * differential: => Phab:D3553 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:37:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:37:52 -0000 Subject: [GHC] #13568: Name is reported as ambiguous and not in scope In-Reply-To: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> References: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> Message-ID: <064.da4d1213a332fcef683d24d38ce48dc8@haskell.org> #13568: Name is reported as ambiguous and not in scope -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3547 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 21:46:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 21:46:30 -0000 Subject: [GHC] #13591: "*** Exception: expectJust showModule" in ghci with hs-boot In-Reply-To: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> References: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> Message-ID: <063.69b3fbf12245da7b517edcc7bc4c6929@haskell.org> #13591: "*** Exception: expectJust showModule" in ghci with hs-boot -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: ghci hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Note that we have a patch for this which resolves the issue as reported. However, I suspect that this bit of code could do with some refactoring. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 22:04:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 22:04:34 -0000 Subject: [GHC] #12991: panic when using IrredPreds in a type checker plugin. In-Reply-To: <043.3217b821d2aaafeace19f4825d72c2ca@haskell.org> References: <043.3217b821d2aaafeace19f4825d72c2ca@haskell.org> Message-ID: <058.e5658330d95e4ecf43a18092e787fbc4@haskell.org> #12991: panic when using IrredPreds in a type checker plugin. -------------------------------------+------------------------------------- Reporter: owen | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Indeed, this was fixed by commit b4bdbe4957ae8b82c4cda5584203b44d3c4f004f (Don't omit any evidence bindings, the fix for #12156). Do we typically add regression tests for the GHC API? If so, I could do that. Otherwise, this can be marked as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 22:30:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 22:30:22 -0000 Subject: [GHC] #11964: Without TypeInType, inconsistently accepts Data.Kind.Type but not type synonym In-Reply-To: <045.8ccc62b1fd247c9c170f9f51a6d9bc8c@haskell.org> References: <045.8ccc62b1fd247c9c170f9f51a6d9bc8c@haskell.org> Message-ID: <060.a3cdf4c7a4e1802f8f96f7097b16942a@haskell.org> #11964: Without TypeInType, inconsistently accepts Data.Kind.Type but not type synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Interestingly, I can't reproduce this issue on GHC 8.0.1 or later, so perhaps this issue only existed in the GHC 8.0.1 release candidates? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 22:30:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 22:30:23 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.014fcb0c762b70efe256126cfca490da@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3525 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahhh, I see what happened here. It looks like I must have dropped the critical hunk from my patch somewhere along the line. Validating fix currently. Thanks for catching this Ryan! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 22:40:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 22:40:26 -0000 Subject: [GHC] #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild In-Reply-To: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> References: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> Message-ID: <064.99f79e077dca0441e445b7d9887ab487@haskell.org> #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"a3873e8cdec8fc966e91ebe024808376a4077e2b/ghc" a3873e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a3873e8cdec8fc966e91ebe024808376a4077e2b" RnEnv refactoring Summary: Lots of refactoring in RnEnv to reduce code duplication. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13545 Differential Revision: https://phabricator.haskell.org/D3507 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 22:41:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 22:41:45 -0000 Subject: [GHC] #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild In-Reply-To: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> References: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> Message-ID: <064.baa6a92d345639c7d118ce5fd1e9bbfd@haskell.org> #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 22:43:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 22:43:17 -0000 Subject: [GHC] #12991: panic when using IrredPreds in a type checker plugin. In-Reply-To: <043.3217b821d2aaafeace19f4825d72c2ca@haskell.org> References: <043.3217b821d2aaafeace19f4825d72c2ca@haskell.org> Message-ID: <058.79311708555787f4356f00ce73c87b8d@haskell.org> #12991: panic when using IrredPreds in a type checker plugin. -------------------------------------+------------------------------------- Reporter: owen | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Given that a test case has presented itself it seems quite reasonable to add it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 23:14:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 23:14:52 -0000 Subject: [GHC] #13666: The gcc wrapper can't handle trailing backslashes In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <061.2281685bc7e5b2921341ad4607283f6f@haskell.org> #13666: The gcc wrapper can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by niklasl): * Attachment "0001-Handle-trailing-backslashes-in-gcc-wrapper.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 23:17:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 23:17:59 -0000 Subject: [GHC] #13666: The gcc wrapper can't handle trailing backslashes In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <061.98f271534a50da76f8fa5a1a75dd2dc3@haskell.org> #13666: The gcc wrapper can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by niklasl): * status: new => patch Comment: Added a patch. The trailing backslash escapes the quote, so it needs to be escaped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 23:24:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 23:24:47 -0000 Subject: [GHC] #13666: The gcc wrapper can't handle trailing backslashes In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <061.bd4ed2d45b7b27e3a8cf3a7abc4d3d21@haskell.org> #13666: The gcc wrapper can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by niklasl): * Attachment "0001-Handle-trailing-backslashes-in-gcc-wrapper.2.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 23:25:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 23:25:40 -0000 Subject: [GHC] #13666: The gcc wrapper can't handle trailing backslashes (was: The fake gcc can't handle trailing backslashes) In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> #13666: The gcc wrapper can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by niklasl): * Attachment "0001-Handle-trailing-backslashes-in-gcc-wrapper.patch" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 23:25:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 23:25:40 -0000 Subject: [GHC] #13666: The gcc wrapper can't handle trailing backslashes In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <061.406a5720daeaba812ed97b9de6063a6c@haskell.org> #13666: The gcc wrapper can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by niklasl): * Attachment "0001-Handle-trailing-backslashes-in-gcc-wrapper.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 23:27:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 23:27:30 -0000 Subject: [GHC] #13666: The gcc wrapper can't handle trailing backslashes In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <061.16f0adbef08561c7343b8b29d2e505a8@haskell.org> #13666: The gcc wrapper can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by niklasl): * Attachment "0001-Handle-trailing-backslashes-in-gcc-wrapper.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 23:27:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 23:27:30 -0000 Subject: [GHC] #13666: The gcc wrapper can't handle trailing backslashes (was: The fake gcc can't handle trailing backslashes) In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> #13666: The gcc wrapper can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by niklasl): * Attachment "0001-Handle-trailing-backslashes-in-gcc-wrapper.patch" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 23:29:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 23:29:24 -0000 Subject: [GHC] #13666: The gcc wrapper can't handle trailing backslashes (was: The fake gcc can't handle trailing backslashes) In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> #13666: The gcc wrapper can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by niklasl): * Attachment "0001-Handle-trailing-backslashes-in-gcc-wrapper.2.patch" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 23:29:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 23:29:24 -0000 Subject: [GHC] #13666: The gcc wrapper can't handle trailing backslashes In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <061.8582d6a2628589b786adf9b2a74814ed@haskell.org> #13666: The gcc wrapper can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by niklasl): * Attachment "0001-Handle-trailing-backslashes-in-gcc-wrapper.2.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 11 23:53:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 May 2017 23:53:41 -0000 Subject: [GHC] #13666: The gcc wrapper can't handle trailing backslashes In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <061.38c3087c65f05357aa5df433c2ac3061@haskell.org> #13666: The gcc wrapper can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Should we disregard one of these? They look identical. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 00:04:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 00:04:45 -0000 Subject: [GHC] #13666: The gcc wrapper can't handle trailing backslashes In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <061.ff8ed0b60a29e65018d73152c46dbe24@haskell.org> #13666: The gcc wrapper can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by niklasl): Yes, they're the same patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 01:00:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 01:00:52 -0000 Subject: [GHC] #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to In-Reply-To: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> References: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> Message-ID: <065.08d87f0d4bd6c739f311cc30952de835@haskell.org> #13674: GHC doesn't discharge heterogeneous equality constraint when it ought to -------------------------------------+------------------------------------- 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): comment:8 is essentially correct. Consider two scenarios: 1. We have a Given proving `blah` and a Wanted `blah`. We use the Given to solve the Wanted. Later, we learn that `blah` is `Lcm m m ~ m`, but nothing above changes. 2. We have a Given proving `blah`. We learn that `blah` is `Lcm m m ~ m`, so we mark it as insoluble. Then, we get a Wanted `blah`, which we see is `Lcm m m ~ m`. This, too, is marked as insoluble. In case 1, we'll succeed; in case 2, we'll fail. The problem is that the only difference in these cases is the order in which constraints are treated and/or solved, something notoriously difficult to control. The "fix" for this problem is not to error on occurs-checks, which would then allow us to succeed in case 2. That seems unsatisfactory, though, because even if occurs-checks don't immediately error, we'll have a hard time solving `m ~ Lcm m m` from `Lcm m m ~ m`. I'm inclined to say that we let this behavior stand. Note that when we accept the program, nothing goes wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 03:05:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 03:05:33 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.7a299208132a4e1632296d326c162df5@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Replying to [comment:15 simonmar]: > @winter it's always wrong to pass an unpinned `ByteArray#` to a foreign call, regardless of whether the call is annotated as `safe` or `unsafe`, because GHC is free to implement an `unsafe` call as a `safe` call. Indeed we do this in GHCi. But lots of packages(text, for example) seems to be relying on this assumption, as you pointed out, text implemented its copy with FFI memcpy rather than a `copyByteArray#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 09:20:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 09:20:10 -0000 Subject: [GHC] #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound In-Reply-To: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> References: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> Message-ID: <065.d30c3d032a1b32b9883498b3bb49d82f@haskell.org> #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3572 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Thanks, Ryan. Please, excuse me for not looking at this earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 12:25:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 12:25:16 -0000 Subject: [GHC] #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound In-Reply-To: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> References: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> Message-ID: <065.7d1fd47931d4c99a4e56af65c2eee904@haskell.org> #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3572 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * milestone: => 8.2.1 Comment: No worries, Facundo! I'll optimistically mark this is merge, since it seems to be a straightforward bugfix. Feel free to close if you think otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 12:32:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 12:32:16 -0000 Subject: [GHC] #13674: Poor error message which masks occurs-check failure (was: GHC doesn't discharge heterogeneous equality constraint when it ought to) In-Reply-To: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> References: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> Message-ID: <065.28b8e1f711c47cfaec50eb7aa506b0c5@haskell.org> #13674: Poor error message which masks occurs-check failure -------------------------------------+------------------------------------- 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: 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 inclined to say that we let this behavior stand. Note that when we accept the program, nothing goes wrong. OK, I can live with that. Sorry for derailing the discussion in the ticket a bit, but I wanted make sure I understood what was going on. Since the behavior here seems to be correct (modulo error messages), I'll change the title accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 12:46:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 12:46:44 -0000 Subject: [GHC] #11966: Surprising behavior with higher-rank quantification of kind variables In-Reply-To: <047.8ead3955d96d6526d9461332f9167c7a@haskell.org> References: <047.8ead3955d96d6526d9461332f9167c7a@haskell.org> Message-ID: <062.d1e5e28118d81702732092b63d3f5b6e@haskell.org> #11966: Surprising behavior with higher-rank quantification of kind variables -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Luckily, commit a7ee2d4c4229b27af324ebac93081f692835365d (Improve TcFlatten.flattenTyVar) fixed this! I'll add a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 13:06:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 13:06:20 -0000 Subject: [GHC] #13669: Identifier "Otherwise" in guarded equation can crash a program In-Reply-To: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> References: <044.2ae7b65cc5d8e7fbba5549a7d3cc3853@haskell.org> Message-ID: <059.748f826d7639948ed4ec38be0577727d@haskell.org> #13669: Identifier "Otherwise" in guarded equation can crash a program -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Solution n° 2 appears to be well.\\ Note that {{{otherwise}}}, which is a guard, is reserved word in Miranda. Why not in Haskell? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 13:08:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 13:08:08 -0000 Subject: [GHC] #12083: ghc-8.0.1-rc4: tyConRoles sees a TcTyCon In-Reply-To: <048.a4a2a5816a0aa4dfbaf2640f489bd6c3@haskell.org> References: <048.a4a2a5816a0aa4dfbaf2640f489bd6c3@haskell.org> Message-ID: <063.a9c343decca97f5e7e050d1608832b4e@haskell.org> #12083: ghc-8.0.1-rc4: tyConRoles sees a TcTyCon -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc4 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Yes. Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3573 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"01af8aee30c743ab505e164ac9aa02149fbe4b9e/ghc" 01af8ae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="01af8aee30c743ab505e164ac9aa02149fbe4b9e" Add regression tests for #12083 Summary: Commit 0c9d9dec0a924a4f34f4cff26d004143c028861a (the fix for #13271) fixed the programs in #12083. This adds regression tests for them. Test Plan: make test TEST="T12083a T12083b" Reviewers: austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #12083 Differential Revision: https://phabricator.haskell.org/D3573 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 13:08:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 13:08:08 -0000 Subject: [GHC] #11966: Surprising behavior with higher-rank quantification of kind variables In-Reply-To: <047.8ead3955d96d6526d9461332f9167c7a@haskell.org> References: <047.8ead3955d96d6526d9461332f9167c7a@haskell.org> Message-ID: <062.85b1a6651aadef5e4897d01640c124a5@haskell.org> #11966: Surprising behavior with higher-rank quantification of kind variables -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"ba5114e310e9140f2b4987245ba1f3709c7b06ec/ghc" ba5114e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ba5114e310e9140f2b4987245ba1f3709c7b06ec" Add regression test for #11966 Commit a7ee2d4c4229b27af324ebac93081f692835365d fixed #11966. Here's a regression test for it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 13:08:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 13:08:08 -0000 Subject: [GHC] #13271: GHC Panic With Injective Type Families In-Reply-To: <050.85e94bb0ec476229be5da928608f3194@haskell.org> References: <050.85e94bb0ec476229be5da928608f3194@haskell.org> Message-ID: <065.58441b8ee4bd709a150b829fac917361@haskell.org> #13271: GHC Panic With Injective Type Families -------------------------------------+------------------------------------- Reporter: wayofthepie | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T13271 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"01af8aee30c743ab505e164ac9aa02149fbe4b9e/ghc" 01af8ae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="01af8aee30c743ab505e164ac9aa02149fbe4b9e" Add regression tests for #12083 Summary: Commit 0c9d9dec0a924a4f34f4cff26d004143c028861a (the fix for #13271) fixed the programs in #12083. This adds regression tests for them. Test Plan: make test TEST="T12083a T12083b" Reviewers: austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #12083 Differential Revision: https://phabricator.haskell.org/D3573 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 13:08:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 13:08:08 -0000 Subject: [GHC] #11964: Without TypeInType, inconsistently accepts Data.Kind.Type but not type synonym In-Reply-To: <045.8ccc62b1fd247c9c170f9f51a6d9bc8c@haskell.org> References: <045.8ccc62b1fd247c9c170f9f51a6d9bc8c@haskell.org> Message-ID: <060.9fb123c2044853a54ac1386443732688@haskell.org> #11964: Without TypeInType, inconsistently accepts Data.Kind.Type but not type synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"a13adcf8cfc650979a80101c0879c11a507734f9/ghc" a13adcf8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a13adcf8cfc650979a80101c0879c11a507734f9" Add regression test for #11964 This issue was only ever present in the GHC 8.0.1 release candidates, but let's add a regression test for it just to be safe. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 13:10:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 13:10:28 -0000 Subject: [GHC] #12083: ghc-8.0.1-rc4: tyConRoles sees a TcTyCon In-Reply-To: <048.a4a2a5816a0aa4dfbaf2640f489bd6c3@haskell.org> References: <048.a4a2a5816a0aa4dfbaf2640f489bd6c3@haskell.org> Message-ID: <063.8b127c164e1834585a36586a07ff3b17@haskell.org> #12083: ghc-8.0.1-rc4: tyConRoles sees a TcTyCon -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc4 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T12083a, | typecheck/should_fail/T12083b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3573 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: Yes. => typecheck/should_fail/T12083a, typecheck/should_fail/T12083b * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 13:11:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 13:11:32 -0000 Subject: [GHC] #11966: Surprising behavior with higher-rank quantification of kind variables In-Reply-To: <047.8ead3955d96d6526d9461332f9167c7a@haskell.org> References: <047.8ead3955d96d6526d9461332f9167c7a@haskell.org> Message-ID: <062.02ac53445e5ecb07f2321be22d7f04b2@haskell.org> #11966: Surprising behavior with higher-rank quantification of kind variables -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc3 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11966 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => dependent/should_compile/T11966 * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 13:12:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 13:12:17 -0000 Subject: [GHC] #11964: Without TypeInType, inconsistently accepts Data.Kind.Type but not type synonym In-Reply-To: <045.8ccc62b1fd247c9c170f9f51a6d9bc8c@haskell.org> References: <045.8ccc62b1fd247c9c170f9f51a6d9bc8c@haskell.org> Message-ID: <060.08927a467d1cf52e3308d67bec472e77@haskell.org> #11964: Without TypeInType, inconsistently accepts Data.Kind.Type but not type synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_run/T11964 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => dependent/should_run/T11964 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 14:42:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 14:42:20 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" Message-ID: <045.57be69db71101b923edaf0af27593704@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.2 Libraries | 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: -------------------------------------+------------------------------------- Currently if I use Data.Either's simple functions like "rights", "isLeft", etc. In Core/Cmm with -O2 I see that they are called like external functions and not inlined. This is because they are not marked as INLINABLE in the library itself. It'll be great if such functions in base are marked as INLINABLE so optimizator/inliner to generate more efficient code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 14:53:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 14:53:15 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.09151a42b54b0ed8b5be2033bbaf8db8@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 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 rwbarton): * status: new => infoneeded Comment: No, that isn't how inlining works. You do not need an INLINABLE pragma on a function for its unfolding to be included in an interface file and used at a call site. (Otherwise virtually nothing would get inlined ever!) Can you provide a reproducer where you are not seeing inlining that you expect to happen? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 15:16:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 15:16:44 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.1933f193356f83fcaf4c083d04b39d27@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): {{{ {-# LANGUAGE BangPatterns, ScopedTypeVariables, NoMonomorphismRestriction #-} import Control.Monad import qualified Data.ByteString as B import Data.Csv.Incremental import Data.Either (rights) import System.Exit import System.IO import System.Environment (getArgs) import qualified Data.List as DL main :: IO () main = do [input] <- getArgs withFile input ReadMode $ \ csvFile -> do let loop !acc (Many rs k) = loop (acc + countFields rs) =<< feed k loop !acc (Done rs) = print (countFields rs + acc) loop !_ (Fail _ errMsg) = putStrLn errMsg >> exitFailure feed k = k <$> B.hGetSome csvFile (16*1024) loop 0 (decode NoHeader :: Parser [()]) where countFields = sum . map length . rights }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 15:17:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 15:17:15 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.332eaa18e965605ecd8e000217539f97@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have confirmed that these two indeed don't have an unfolding in 8.0.2, {{{#!hs 2155eed1475edba07fc3c0eac3a8a1c2 rights :: [Either a b] -> [b] {- Arity: 1, HasNoCafRefs, Strictness: , Unfolding: (\ @ a @ b (x :: [Either a b]) -> rights1 @ a @ b x) -} 39075b0896f5b6036d022994b88a19f9 rights1 :: [Either a b] -> [b] {- Arity: 1, HasNoCafRefs, Strictness: -} }}} Moreover, this, {{{#!hs import Data.Either main = print $ sum $ rights [ Right i | i <- [1..500] ] }}} exhibits a call to `rights1`. It seems we really do need an explicit `INLINABLE` here. Thanks for pointing this out, varosi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 15:17:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 15:17:49 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.42037b11a66134d62e9b2e0c3d8ba3f1@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): I'm expect "rights" to be inlined in Core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 15:18:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 15:18:56 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.bfd063d86880fa3f47aca5ffa4009d66@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Could you elaborate more why this happens? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 15:20:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 15:20:20 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.3174abe3cff1e5e757055c5ee804bf3d@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Should we not ask first why they do not have unfoldings? They seem quite small. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 15:21:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 15:21:42 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.64ff2ccdc4a4d1d77fd84bda55f906ef@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): They are defined in terms of list comprehensions, which does result in a rather large desugared core definition, {{{#!hs rights' :: forall t_aQz t_aQx. [Either t_aQz t_aQx] -> [t_aQx] [LclIdX, Str=DmdType] rights' = \ (@ t_aQz) (@ t_aQx) (xs_aPD :: [Either t_aQz t_aQx]) -> GHC.Base.build @ t_aQx (\ (@ a_d1An) (c_d1Ao [OS=OneShot] :: t_aQx -> a_d1An -> a_d1An) (n_d1Ap [OS=OneShot] :: a_d1An) -> GHC.Base.foldr @ (Either t_aQz t_aQx) @ a_d1An (\ (ds_d1Ar :: Either t_aQz t_aQx) (ds_d1Aq [OS=OneShot] :: a_d1An) -> case ds_d1Ar of _ [Occ=Dead] { __DEFAULT -> (\ _ [Occ=Dead, OS=OneShot] -> ds_d1Aq) GHC.Prim.void#; Right x_aPE -> c_d1Ao x_aPE ds_d1Aq }) n_d1Ap xs_aPD) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 15:29:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 15:29:13 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.a0301e097c064e837ff7ce8a0c672a0a@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 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 bgamari): * cc: nomeata (added) Comment: CCing Joachim who has thought a great deal about fusion. I think the simplest option here is to just to do as varosi suggests and add INLINEABLE pragmas. Yes, we could give `lefts` and `rights` the same treatment that we give `filter` and give it a "trivial" definition, alongside some fusible definitions with rules to map one to the other, but I think this is a lot of complexity for little pay-off. In general this does raise the point though of being careful about defining library functions in terms of list comprehensions as they make definitions look much smaller than they in fact are. If we make `lefts` and `rights` `INLINEABLE` then we also ought to look for other functions in `base` defined in terms of comprehensions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 15:34:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 15:34:46 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.b2e2cae52859c5752b20b695217016bc@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): `INLINEABLE` might be reasonable. Isn’t it the case that the unfolding stored in the interface will be the un-optimized one (i.e. not the large thing visible up there?) Or is the large code directly the result of the desugared list comprehension (instead of applying rules to the resulting code)? > Yes, we could give lefts and rights the same treatment that we give filter and give it a "naive" definition, alongside some fusible definitions with rules to map one to the other, but I think this is a lot of complexity for little pay-off. Probably not worth it. `lefts` and `rights` are already defined in terms of fusable things (list comprehensions) – this is different for `filter`, which has a recursive definition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 15:37:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 15:37:51 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.b7a802fca888d263b58c5e1e714cc16a@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D3576 Comment: > INLINEABLE might be reasonable. Isn’t it the case that the unfolding stored in the interface will be the un-optimized one . Yes. > (i.e. not the large thing visible up there?) No :) The large thing visible here is the desugared Core (`-ddump-ds`); no simplification has happened. It just so happens that list comprehensions are directly desugared into fusion primitives and consequently produce rather large Core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 15:38:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 15:38:44 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.806048578920336c1fb77b74371b0bda@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Probably not worth it. lefts and rights are already defined in terms of fusable things (list comprehensions) – this is different for filter, which has a recursive definition. Right; that is my view as well. The only difference would be the size of the interface file and how much work the simplifier needs to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 15:38:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 15:38:59 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.ea921d00d9c6af4984cc6d27323fd0be@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 15:41:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 15:41:36 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.17e142f31bf9c103b4374361a190849d@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > It just so happens that list comprehensions are directly desugared into fusion primitives and consequently produce rather large Core. Oh, annoying. What if the implementation was ``` lefts = concatMap go where go (Left x) = [x] go (Right _) = [] ``` That should result in the same code in terms of `foldr` and `buildr`, but maybe produce a smaller unfolding, and be inlinable by itself. (This is more out of curiosity, it is not too bad to have a large unfolding, I think). Although it would be desirable to use a single library defined definition of `lefts` when no fusion happens, instead of repeating the code at every use-site. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 15:44:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 15:44:21 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.2cb56f9b9bb7f0130bf3177198581b21@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'd rather not give special treatment to `rights` which is not a very special function. It's common to write functions like `rights` for ones own types for example. Instead could we perhaps give a bigger bonus to unfoldings headed by `build`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 17:09:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 17:09:50 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.9914c1aef740ab9ac424ab02fab7665a@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Instead could we perhaps give a bigger bonus to unfoldings headed by `build`? This sounds like a nice avenue to explore but it seems a bit ad-hoc. While `foldr/build` do enjoy some special treatment in the compiler, I suspect end-users may want to have this same bonus (e.g. `vector`'s `stream`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 18:19:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 18:19:43 -0000 Subject: [GHC] #13690: Running profiling tests in the GHCi way is extremely slow Message-ID: <045.fb69f1a6160438a1692ed4b6bf5047fa@haskell.org> #13690: Running profiling tests in the GHCi way is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running, e.g., `profinline001` in the GHCi way takes somewhere around eleven seconds. This seems pretty extreme. I noticed this when writing T12962 in the as-yet-unmerged Phab:D3550, which takes about the same amount of time. These are very small and very simple bits of code that don't do much at all, so it seems the problem must lie elsewhere. I have no idea where, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 18:27:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 18:27:37 -0000 Subject: [GHC] #13690: Running profiling tests in the GHCi way is extremely slow In-Reply-To: <045.fb69f1a6160438a1692ed4b6bf5047fa@haskell.org> References: <045.fb69f1a6160438a1692ed4b6bf5047fa@haskell.org> Message-ID: <060.24df49b3e1e77c108c51ba668b80bd42@haskell.org> #13690: Running profiling tests in the GHCi way is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Reproduction: Build GHC with `BuildFlavour = perf`. Change to the `testsuite` directory and run `make TEST=profinline001`. The compiled ways run in the blink of an eye, but the GHCi way (`--interactive`) takes around 11 seconds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 18:31:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 18:31:48 -0000 Subject: [GHC] #13690: Running profiling tests in the GHCi way is extremely slow In-Reply-To: <045.fb69f1a6160438a1692ed4b6bf5047fa@haskell.org> References: <045.fb69f1a6160438a1692ed4b6bf5047fa@haskell.org> Message-ID: <060.fe70049aec20a12c8f7536e24c1cf38c@haskell.org> #13690: Running profiling tests in the GHCi way is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dobenour (added) Comment: bgamari thought dobenour might consider these good test cases for a potential bytecode interpreter rework. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 18:36:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 18:36:38 -0000 Subject: [GHC] #13691: Bump time submodule Message-ID: <046.7033f0ecc0a7c3600b088ca823c99a67@haskell.org> #13691: Bump time submodule -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `time` version currently on the `ghc-8.2` branch is [[https://github.com/haskell/time/issues/74|broken]]. Make sure this gets fixed before the release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 18:38:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 18:38:38 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.1d0a4cbc6bdc75be3143dec1ddedc222@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Phab:D3550 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"ab91daf2cb8a4a8558727ebe30a662a2ddf290e1/ghc" ab91daf2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ab91daf2cb8a4a8558727ebe30a662a2ddf290e1" Automatically add SCCs to INLINABLE bindings Instead of excluding `isAnyInlinePragma`, just exclude `isInlinePragma`. This makes GHC behave as documented; the user's guide only indicates that GHC does not automatically add SCCs to `INLINE` bindings. Fixes #12962. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: DemiMarie, osa1, Mikolaj, simonpj, rwbarton, thomie GHC Trac Issues: #12962 Differential Revision: https://phabricator.haskell.org/D3550 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 18:42:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 18:42:50 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.0f18b86a1f5991635f5bd148806afe19@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: dfeuer Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Profiling | Version: 8.0.1 Resolution: fixed | Keywords: Inlining, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Phab:D3550 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 21:32:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 21:32:46 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.c683e1ad3e96bcffbbdef1331623832f@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:8 bgamari]: > In general this does raise the point though of being careful about defining library functions in terms of list comprehensions as they make definitions look much smaller than they in fact are. If we make `lefts` and `rights` `INLINEABLE` then we also ought to look for other functions in `base` defined in terms of comprehensions. I don't think the unfoldings are any bigger than they need to be, but you're right; we need to think about `INLINABLE` annotations when we might not otherwise. I believe the inliner gives a bonus when it sees things that are mentioned in `RULES`. If we don't do so already, we should surely give a similar bonus when deciding whether to export an unfolding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 21:37:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 21:37:29 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.05c6e7754ba3a35014d6d4c198409950@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): By the way, way back a few years ago when I was mucking about with list fusion, it always seemed that GHC was a lot better at deciding to inline `foldr` things than at deciding to inline `build` things. I'm not sure why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 21:49:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 21:49:35 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.88cc6c175c63b6a7abfce5fbef19e046@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 22:23:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 22:23:43 -0000 Subject: [GHC] #13492: -p option report much less time than actual on high intensity of FFI calls application In-Reply-To: <045.f50d3dd52e457f79de74acb0151c7b37@haskell.org> References: <045.f50d3dd52e457f79de74acb0151c7b37@haskell.org> Message-ID: <060.77262e0fa3f996aa00775c64a5431d42@haskell.org> #13492: -p option report much less time than actual on high intensity of FFI calls application -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The cost-center profiler only measures the time spent in the mutator (that is, actually doing Haskell evaluation). It will not report time spent in FFI calls. For that you will need to use your platform's native profiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 22:31:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 22:31:09 -0000 Subject: [GHC] #13591: "*** Exception: expectJust showModule" in ghci with hs-boot In-Reply-To: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> References: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> Message-ID: <063.447312322219c618a1f50db652e1ff87@haskell.org> #13591: "*** Exception: expectJust showModule" in ghci with hs-boot -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: ghci hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1edee7a8b5ca24156cb6e21bde6d611a0ba63882/ghc" 1edee7a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1edee7a8b5ca24156cb6e21bde6d611a0ba63882" Fix crash in isModuleInterpreted for HsBoot (fixes #13591) Rename isModuleInterpreted to moduleIsBootOrNotObjectLinkable because a) there already is a moduleIsInterpreted function in the same module b) I have no idea if the (new) semantic of the bool returned matches some understanding of "is interpreted". }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 22:31:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 22:31:09 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.cdedb600245a1781d6882a27ff1fdf5e@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3525 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3032ae81dd14c2eaefa9ecd8880dafa9bda104d9/ghc" 3032ae81/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3032ae81dd14c2eaefa9ecd8880dafa9bda104d9" Revert "Treat banged bindings as FunBinds" This partially reverts commit 372995364c52eef15066132d7d1ea8b6760034e6 as it doesn't actually fix #13594. Namely it does not revert the mkPrefixFunRhs refactoring since this is rather independent from the functional changes. Going to try again with a whole working patch }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 22:31:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 22:31:09 -0000 Subject: [GHC] #13664: Ill formatted warning about tabulators In-Reply-To: <046.b26a1d2020e1e5fb1578aa510b2685ff@haskell.org> References: <046.b26a1d2020e1e5fb1578aa510b2685ff@haskell.org> Message-ID: <061.0fa73f07ca3c7c8e811fcc56214d8618@haskell.org> #13664: Ill formatted warning about tabulators -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3549 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c068c38727b7bd7a1a75495167f7470abb7bf866/ghc" c068c387/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c068c38727b7bd7a1a75495167f7470abb7bf866" Render \t as 8 spaces in caret diagnostics Test Plan: validate Reviewers: austin, bgamari, rwbarton Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13664 Differential Revision: https://phabricator.haskell.org/D3549 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 22:31:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 22:31:54 -0000 Subject: [GHC] #13591: "*** Exception: expectJust showModule" in ghci with hs-boot In-Reply-To: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> References: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> Message-ID: <063.6d3e325f178532849078c79ae2fbccf0@haskell.org> #13591: "*** Exception: expectJust showModule" in ghci with hs-boot -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: ghci hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 12 22:32:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 May 2017 22:32:01 -0000 Subject: [GHC] #13664: Ill formatted warning about tabulators In-Reply-To: <046.b26a1d2020e1e5fb1578aa510b2685ff@haskell.org> References: <046.b26a1d2020e1e5fb1578aa510b2685ff@haskell.org> Message-ID: <061.1adf046dab3e56c9145e1b7ee81a276b@haskell.org> #13664: Ill formatted warning about tabulators -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3549 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 00:41:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 00:41:18 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.d611f19d61268744c7edbe25a7e2dae1@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomasjm): I just hit this problem in Ubuntu 16.04.2 LTS, with stack resolver lts-8.5 (GHC 8.0.2). Doing "setLocaleEncoding utf8" worked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 03:33:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 03:33:10 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.7b1c6bc81c3f3d5faa24dc5df5a8a7ab@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): JFTR: The definition {{{ lefts = concatMap go where go (Left x) = [x] go (Right _) = [] }}} results in the same code (GHC HEAD even CSE’s it with the other definition if defined in the same module), and also does not get an unfolding automatically, and with `INLINEABLE` the unfolding is the large one with `foldr` and `build`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 08:31:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 08:31:19 -0000 Subject: [GHC] #13492: -p option report much less time than actual on high intensity of FFI calls application In-Reply-To: <045.f50d3dd52e457f79de74acb0151c7b37@haskell.org> References: <045.f50d3dd52e457f79de74acb0151c7b37@haskell.org> Message-ID: <060.f21ef951b374f71b8f4d99b17bb28bb4@haskell.org> #13492: -p option report much less time than actual on high intensity of FFI calls application -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): It'll be great if there is some statistic that include FFI calls and give some FFI statistics, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 12:56:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 12:56:14 -0000 Subject: [GHC] #13607: Panic when shared object file is missing: Dynamic linker not initialised (was: Panic with profiled compiler: Dynamic linker not initialised) In-Reply-To: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> References: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> Message-ID: <065.785b1f09e3de14191814072491900c0b@haskell.org> #13607: Panic when shared object file is missing: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, you don't need a profiled compiler after all. You can reproduce this with an ordinary GHC with one extra step. As before, install some library, like `random-1.1`: {{{ $ cabal install random-1.1 -w /opt/ghc/head/bin/ghc }}} Then figure out its package ID: {{{ $ /opt/ghc/head/bin/ghc-pkg describe random name: random version: 1.1 id: random-1.1-Gnn89iTXDuaz90MEyLmyr ... }}} This time, however, you'll need to change the contents of `.cabal` (where `cabal-install` puts its shared object files). On Linux, this can be accomplished like so: {{{ $ cd ~/.cabal/lib/x86_64-linux-ghc-8.3.20170509/ $ mv libHSrandom-1.1-Gnn89iTXDuaz90MEyLmyr-ghc8.3.20170509.so libHSrandom-1.1-Gnn89iTXDuaz90MEyLmyr-ghc8.3.20170509-dummy.so }}} Now compile `Bar.hs` as before: {{{ $ /opt/ghc/head/bin/ghc -fforce-recomp Bar.hs -j2 -package-id random-1.1-Gnn89iTXDuaz90MEyLmyr [1 of 3] Compiling Foo ( Foo.hs, Foo.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170509 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [2 of 3] Compiling Foo2 ( Foo2.hs, Foo2.o ) : error: : can't load .so/.DLL for: libHSrandom-1.1-Gnn89iTXDuaz90MEyLmyr.so (libHSrandom-1.1-Gnn89iTXDuaz90MEyLmyr.so: cannot open shared object file: No such file or directory) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 12:58:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 12:58:08 -0000 Subject: [GHC] #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file In-Reply-To: <042.f97bf302ed95b0f9a174910a7d6a0986@haskell.org> References: <042.f97bf302ed95b0f9a174910a7d6a0986@haskell.org> Message-ID: <057.cce501445685ab3f18f0fdcaa5944563@haskell.org> #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13137, #9868, | Differential Rev(s): #10355, #13607 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Scratch that, #13607 doesn't require a profiled compiler at all. So at this point, I'd say that #13607 and #13531 are symptoms of the same issue (I'll leave this ticket open though, since I don't know if fixing #13531 would necessarily fix this issue as well, given the complexity of the code involved.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 13:34:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 13:34:45 -0000 Subject: [GHC] #13682: When printf "%g" with trailing 0 number, decial point be printed. In-Reply-To: <050.490573f64c08d47bec1fad0af5100e99@haskell.org> References: <050.490573f64c08d47bec1fad0af5100e99@haskell.org> Message-ID: <065.7c25a3d53f9e4e7788a26afe1de2748a@haskell.org> #13682: When printf "%g" with trailing 0 number, decial point be printed. -------------------------------------+------------------------------------- Reporter: nakaji_dayo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: invalid | Keywords: printf Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nakaji_dayo): * status: new => closed * resolution: => invalid Comment: Thank you for reply. Apologies for the noise. I had overlooked the document. I close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 17:59:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 17:59:14 -0000 Subject: [GHC] #12600: Overloaded method causes insufficient specialization In-Reply-To: <043.07cdd679c81a8644725c82782d392414@haskell.org> References: <043.07cdd679c81a8644725c82782d392414@haskell.org> Message-ID: <058.1b4be2c8572c1161fc0f7606855019f6@haskell.org> #12600: Overloaded method causes insufficient specialization -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3580 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D3580 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 19:54:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 19:54:52 -0000 Subject: [GHC] #13692: Constructors and such should be able to move around seq# sometimes Message-ID: <045.5e5b5898d37db35c3d84d20dedecbcbf@haskell.org> #13692: Constructors and such should be able to move around seq# sometimes -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code {{{#!hs module SeqCon where import Control.Exception (evaluate) blah :: Int -> IO Int blah x = (+2) <$> evaluate (x + 3) }}} compiled with `-O2 -ddump-prep -dsuppress-coercions` produces the following (and `-ddump-stg` doesn't change much of note): {{{ SeqCon.blah1 :: GHC.Types.Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] SeqCon.blah1 = \ (x_s1cz [Occ=Once!] :: GHC.Types.Int) (s_s1cA [Occ=Once] :: GHC.Prim.State# GHC.Prim.RealWorld) -> let { sat_s1cE [Occ=Once] :: GHC.Types.Int [LclId] sat_s1cE = case x_s1cz of { GHC.Types.I# x1_s1cC [Occ=Once] -> case GHC.Prim.+# x1_s1cC 3# of sat_s1cD { __DEFAULT -> GHC.Types.I# sat_s1cD } } } in case GHC.Prim.seq# @ GHC.Types.Int @ GHC.Prim.RealWorld sat_s1cE s_s1cA of { (# ipv_s1cG [Occ=Once], ipv1_s1cH [Occ=Once!] #) -> let { sat_s1cL [Occ=Once] :: GHC.Types.Int [LclId] sat_s1cL = case ipv1_s1cH of { GHC.Types.I# x1_s1cJ [Occ=Once] -> case GHC.Prim.+# x1_s1cJ 2# of sat_s1cK { __DEFAULT -> GHC.Types.I# sat_s1cK } } } in (# ipv_s1cG, sat_s1cL #) } -- RHS size: {terms: 5, types: 3, coercions: 5, joins: 0/0} SeqCon.blah :: GHC.Types.Int -> GHC.Types.IO GHC.Types.Int [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] SeqCon.blah = (\ (eta_B2 [Occ=Once] :: GHC.Types.Int) (eta_B1 [Occ=Once] :: GHC.Prim.State# GHC.Prim.RealWorld) -> SeqCon.blah1 eta_B2 eta_B1) `cast` }}} This builds a closure to build an `Int` and passes it to `seq#`. That seems a bit wasteful, since we don't actually need the `Int` box. I think what we'd really like to end up with is something like {{{#!hs blah1 = \ (x :: Int) (s :: State# RealWorld) -> case seq# x s of { (# s', x' #) -> case x' of { I# x# -> (# s', I# (x# +# 5#) #) }} }}} Here's one vague idea: when we analyse `x+3` (the argument to `seq#`) under a strict demand, we see it is strict in `x`. So we can transform `seq# (x + 3) s` into {{{#!hs case seq# x s of (# s', x' #) -> seq# (x' + 3) s' }}} We know that `x'` is in WHNF, so we should (I think) be able to see that `x' + 3` isn't bottom, so we can use {{{#!hs case seq# x s of {(# s', x' #) -> case x' + 3 of {!res -> s', res}} }}} Side note: the redundant eta-expansion in `blah` is a bit surprising. `blah1` already has arity 2, so I'd have expected `blah` to just coerce it directly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 20:09:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 20:09:09 -0000 Subject: [GHC] #11272: Overloaded state-monadic function is not specialised In-Reply-To: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> References: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> Message-ID: <067.a56494681e0d7879826bb6df4d885c7b@haskell.org> #11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3561 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"70191f59dd8990c6b1917954a087f4fad67e9c4f/ghc" 70191f5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="70191f59dd8990c6b1917954a087f4fad67e9c4f" Add a test for #11272 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #11272 Differential Revision: https://phabricator.haskell.org/D3561 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 20:10:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 20:10:52 -0000 Subject: [GHC] #12056: Too aggressive `-w` option In-Reply-To: <042.615977cbd760a0223c1133d5e2a0fac1@haskell.org> References: <042.615977cbd760a0223c1133d5e2a0fac1@haskell.org> Message-ID: <057.6cc2b70b5cbf989dc96d8ac33764c1c8@haskell.org> #12056: Too aggressive `-w` option -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11429, #11789 | Differential Rev(s): Phab:D3581 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgillespie): * differential: => Phab:D3581 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 20:14:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 20:14:10 -0000 Subject: [GHC] #11272: Overloaded state-monadic function is not specialised In-Reply-To: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> References: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> Message-ID: <067.69412bb1b01d6c261e3e68a39835bbd4@haskell.org> #11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 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:D3561 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 20:18:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 20:18:02 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.ef1abe270acc90179222028487631aef@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13016 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #13016 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 20:26:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 20:26:44 -0000 Subject: [GHC] #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function In-Reply-To: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> References: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> Message-ID: <061.031cb3661ca0ca7910e47be2ef5165dd@haskell.org> #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13014 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): mpickering, I don't think it's quite a duplicate. In particular, I believe we want `SPECIALIZE INLINE` to actually ''force'' the specialization, even if it makes a lot of code and even if it risks an infinite loop in the simplifier. The idea here seems pretty cool: it lets you get the guaranteed loop unrolling you'd get from the class-based definition I wrote above when the types are known, but falls back on recursion when they're not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 21:08:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 21:08:45 -0000 Subject: [GHC] #13390: Strict literal float-out during desugaring regresses T1969 at -O0 In-Reply-To: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> References: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> Message-ID: <061.4530ca93fc39a6d652dbf2a3f636bb74@haskell.org> #13390: Strict literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): All right. I took another look at what's going on in HEAD (without the string literal patch). It looks like I missed one piece: rules. So here's something more like the real story. We start out with {{{ $cc_aT4 :: A1 -> String $cc_aT4 = \ (ds_dUh :: A1) -> case ds_dUh of { A1 -> GHC.CString.unpackCString# "A1"# } T1969.$dme :: forall a. C a => a -> String T1969.$dme = \ (@ a_aog) ($dC_aSS :: C a_aog) (x_aoi :: a_aog) -> c @ a_aog $dC_aSS x_aoi T1969.$dmd :: forall a. C a => a -> String T1969.$dmd = \ (@ a_aog) ($dC_aSS :: C a_aog) (x_aoh :: a_aog) -> c @ a_aog $dC_aSS x_aoh Rec { T1969.$fCA1 :: C A1 T1969.$fCA1 = T1969.C:C @ A1 $cc_aT4 $cd_aT8 $ce_aTf $ce_aTf :: A1 -> String $ce_aTf = T1969.$dme @ A1 T1969.$fCA1 $cd_aT8 :: A1 -> String $cd_aT8 = T1969.$dmd @ A1 T1969.$fCA1 end Rec } }}} Then `$dme` inlines, producing {{{ $ce_aTf :: A1 -> String $ce_aTf = (\ (@ a_aog) ($dC_aSS :: C a_aog) (x_aoi :: a_aog) -> c @ a_aog $dC_aSS x_aoi) @ A1 T1969.$fCA1 }}} which reduces to {{{ $ce_aTf :: A1 -> String $ce_aTf = \ (x_aoi :: A1) -> c @ A1 T1969.$fCA1 x_aoi }}} Then the class op rule for `c @A1` fires, turning this into {{{ $ce_aTf :: A1 -> String $ce_aTf = \ (x_aoi :: A1) -> $cc_aT4 x_aoi }}} The same thing happens to `$dmd` and `$cd_aT8`. At some point, I believe both `ce_aTf` and `cd_aT8` must both get eta-reduced to `$cc_aT4` (which is perfectly legitimate because `$cc_aT4` is strict in its argument). `-ddump-inlinings` on its own doesn't show any further inlining, but `-dverbose-core2core` (if I'm reading it right) shows that the eta-reduced versions are indeed inlined into the constructor. These are trivial inlinings, replacing one binding with another, which should get around your statement that we don't (and don't want to) inline into constructor arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 22:10:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 22:10:12 -0000 Subject: [GHC] #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function In-Reply-To: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> References: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> Message-ID: <061.4e58e5d234141caf8ac482ec28474b26@haskell.org> #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13014 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I discussed this on IRC with David briefly. {{{ mpickering> dfeuer: I don't think SPECIALISE INLINE ever worked like you are suggesting. I think it just works like SPECIALISE and then marks the specialisation with an INLINE pragma 10:07 PM I was under the impression that SpecConstr allowed you to force this unrolling to happen 10:08 PM The manual states that "and applies even if the function is recursive." 10:09 PM but I don't know what this means or how it works as there is no special check in the simplifier to inline specialisations arising from SPECIALISE INLINE pragmas 10:09 PM mpickering: I'm just going off of the documentation that was added when SPECIALISE INLINE was. 10:09 PM The only way I know to push really hard for SpecConstr is using that funky pseudo-argument. 10:10 PM there is another deprecated way 10:10 PM but yes you have to use that argument or use a flag I think 10:11 PM mpickering: well, if the documentation is just wrong, and wasn't intended to be right, then we need to fix the documentation. 10:11 PM indeed, I've just been trying to work out the intention, implementation and documentation line up with each other 10:11 PM as they clearly don't at the moment 10:12 PM But I do think it's worth considering; the funny special argument is highly unlikely to appear in any other (future) Haskell implementation, so using it is screaming "GHC only forever". }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 22:12:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 22:12:08 -0000 Subject: [GHC] #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function In-Reply-To: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> References: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> Message-ID: <061.d48ad8fd14fac2c28155b7c66b91a124@haskell.org> #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13014 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I also confirmed that b61562feb87689a202118ca08ef270422c69dcc2 causes SpecConstr to fire on this example when it didn't before. Here is the snippet of the core which was produced *before* this patch. {{{ T13016.exampleMODULE2 :: Arr (Int, Int) [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] T13016.exampleMODULE2 = T13016.ArrPair @ (Int, Int) @ Int @ Int @~ <(Int, Int)>_N T13016.exampleMODULE4 T13016.exampleMODULE3 T13016.exampleMODULE1 :: Int [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] T13016.exampleMODULE1 = I# 5# exampleMODULE :: (Int, Int) [GblId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 50 30}] exampleMODULE = case T13016.$w$s!: @ Int @ Int T13016.exampleMODULE2 T13016.exampleMODULE1 of _ [Occ=Dead] { (# ww1_sAJ, ww2_sAK #) -> (ww1_sAJ, ww2_sAK) } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 22:57:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 22:57:14 -0000 Subject: [GHC] #9285: IO manager startup procedure somewhat odd In-Reply-To: <044.a7ab40532a3a20a4ca082f731e68f5e6@haskell.org> References: <044.a7ab40532a3a20a4ca082f731e68f5e6@haskell.org> Message-ID: <059.3d4fb649822861bb2d4ed8a33b4f3952@haskell.org> #9285: IO manager startup procedure somewhat odd -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: task | Status: patch Priority: low | Milestone: 8.4.1 Component: Runtime System | Version: 7.8.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 dfeuer): * milestone: => 8.4.1 Comment: Setting a milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 23:09:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 23:09:40 -0000 Subject: [GHC] #13693: RTS cannot be reinitialized reliably after hs_exit() Message-ID: <045.cd6e22a7682fc510f167ecc0250766a6@haskell.org> #13693: RTS cannot be reinitialized reliably after hs_exit() -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime | Version: 6.10.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: -------------------------------------+------------------------------------- #2863 added the FFI spec violation to the docs, but as far as I can tell, there is and was no ticket to actually fix the problems, which seem to be: 1. If the runtime is deinitialized by an `hs_exit()` matching the ''first'' `hs_init()`, then it cannot be reinitialized reliably using `hs_init()`. 2. This condition is not detected, and leads to unpredictable behavior. I'll add a link to ''this'' ticket to the user's guide; even if the ticket is ultimately closed as `WONTFIX`, it will be good to have a persistent reference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 23:11:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 23:11:24 -0000 Subject: [GHC] #13346: Run nofib with -fspec-constr-keen In-Reply-To: <045.dd33dfb272bb36064a8022d93fb903e2@haskell.org> References: <045.dd33dfb272bb36064a8022d93fb903e2@haskell.org> Message-ID: <060.461abfff2d8db5f0586f7b00388f2bcb@haskell.org> #13346: Run nofib with -fspec-constr-keen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Increased allocations could be due to reboxing as described in section 6.1 of the original paper. In a few experiments, it does seem that flag causes quite aggressive optimisation in the case of static arguments. For example: {{{ main = drop 2 [1,2,3] }}} leads to {{{ -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} Foo.main1 :: Integer [GblId, Caf=NoCafRefs, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 100 0}] Foo.main1 = 3 -- RHS size: {terms: 3, types: 2, coercions: 0, joins: 0/0} main :: [Integer] [GblId, Caf=NoCafRefs, Str=m2, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] main = GHC.Types.: @ Integer Foo.main1 (GHC.Types.[] @ Integer) }}} Notice that `drop` has been fully evaluated even though it is self- recursive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 23:11:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 23:11:38 -0000 Subject: [GHC] #13346: Run nofib with -fspec-constr-keen In-Reply-To: <045.dd33dfb272bb36064a8022d93fb903e2@haskell.org> References: <045.dd33dfb272bb36064a8022d93fb903e2@haskell.org> Message-ID: <060.867544c1032d1d8163dd103bcb0e430b@haskell.org> #13346: Run nofib with -fspec-constr-keen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SpecConstr Operating System: 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: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 23:26:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 23:26:32 -0000 Subject: [GHC] #12600: Overloaded method causes insufficient specialization In-Reply-To: <043.07cdd679c81a8644725c82782d392414@haskell.org> References: <043.07cdd679c81a8644725c82782d392414@haskell.org> Message-ID: <058.8d0f976a10f43d8d9bb1d053c155f9a0@haskell.org> #12600: Overloaded method causes insufficient specialization -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3580 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"56de2225fa5d22f38b93489a03d5c8b7301b759e/ghc" 56de2225/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="56de2225fa5d22f38b93489a03d5c8b7301b759e" Add a test for #12600 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #12600 Differential Revision: https://phabricator.haskell.org/D3580 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 23:37:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 23:37:00 -0000 Subject: [GHC] #13390: Strict literal float-out during desugaring regresses T1969 at -O0 In-Reply-To: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> References: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> Message-ID: <061.8c135909514f4290ebf78c5891859a13@haskell.org> #13390: Strict literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I finally built the patched version. As best I can tell, the story starts the same. That is, we get the same inlining of `$dme` and `$dmd`, and the same class op rules firing, but then `$cc_aT4` is getting inlined into `$ce_aTf` and `$cd_aT8` instead of allowing those functions to eta-reduce away. So I guess maybe we actually ''can'' make a useful change: perhaps we want to check for eta-reduction opportunities ''before'' considering inlining. There's not much point inlining a function application into the body of a lambda when we can instead eliminate the lambda (and the application) altogether. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 23:37:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 23:37:59 -0000 Subject: [GHC] #12600: Overloaded method causes insufficient specialization In-Reply-To: <043.07cdd679c81a8644725c82782d392414@haskell.org> References: <043.07cdd679c81a8644725c82782d392414@haskell.org> Message-ID: <058.bd330bad990abb67ad5787909a9ce101@haskell.org> #12600: Overloaded method causes insufficient specialization -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3580 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 13 23:47:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 May 2017 23:47:41 -0000 Subject: [GHC] #13694: CSE runs before SpecConstr Message-ID: <049.2cc02e2cd17495b57fd9446870e30156@haskell.org> #13694: CSE runs before SpecConstr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: SpecConstr, | Operating System: Unknown/Multiple cse | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- SpecConstr can lead to more CSE opportunities. Currently CSE is run only once after the full laziness transformation but then not again later in the pipeline. Running it again after the final clean-up simplification might lead to smaller programs. One example with `-fspec-constr-keen`. {{{ module Foo where main :: [Int] main = drop 1 [1,2] mainMODULE :: [Int] mainMODULE = mydrop 1 [1,2] mydrop :: Int -> [a] -> [a] mydrop 0 xs = xs mydrop n (x:xs) = mydrop (n-1) xs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 05:38:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 05:38:54 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic Message-ID: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> #13695: Highly nested UNPACKed data causes panic ----------------------------------------+--------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 3990 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- See attached source files. I get the following error: {{{ [3 of 3] Compiling Data.BigWord ( src/Data/BigWord.hs, .stack- work/dist/x86_64-linux/Cabal-2.0.0.0/build/Data/BigWord.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170505 for x86_64-unknown-linux): urk! lookup local fingerprint D:R:DoubleWordDoubleWord2 [cESifd :-> (BigWord2, acd0b93ce6ccc191df910f3c0527af52), cESife :-> (BigWord3, c2394bb5a6246cea8260b764c4645609), cESiqK :-> (BigWord4, dfeb99d5c409e91fe7084935101bb1a8), cESiqT :-> (R:DoubleWordDoubleWord3, 00000000000000000000000000000000), cESiqV :-> (D:R:DoubleWordDoubleWord4, 00000000000000000000000000000000), cESir1 :-> (D:R:BigWord4, 7d2736129b3a85c7e71bc1954bb41ec0), dESiqK :-> (BigWord4, d51a0117843c625086a534a6e4b47d85), iESiqK :-> (BigWord4, 139d5d98471af07fbafb30541b5ec225), iESiqX :-> ($WBigWord4, df51c2cc8c85fdd30898a16f2568c91a)] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/iface/MkIface.hs:508:37 in ghc:MkIface }}} I need to use ghc-8.2.1 because it seems to be the earliest version that contains the fixes in [https://ghc.haskell.org/trac/ghc/ticket/3990], without which the UNPACKs will be ignored. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 05:39:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 05:39:28 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.765f6b03ce2fdc5b3a034acef36f6a9e@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by ryanreich): * Attachment "BigWord.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 05:39:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 05:39:40 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.621ce88c954e129a5c2b282a70baa90a@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by ryanreich): * Attachment "BigWordUnpack.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 05:39:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 05:39:54 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.a92f89fee80155d381ef50f8ef978a2e@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by ryanreich): * Attachment "BigWordClass.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 08:55:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 08:55:18 -0000 Subject: [GHC] #13696: rts/linker/ElfTypes.h does not compile on most of UNREG arches (and some registerised arches) Message-ID: <045.a86fc79f1bbf5d280a0a8610fc6376e7@haskell.org> #13696: rts/linker/ElfTypes.h does not compile on most of UNREG arches (and some registerised arches) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Builds fail as: {{{ rts_dist_HC rts/dist/build/RtsStartup.o rts/linker/ElfTypes.h:23:4: error: error: #error "Unsupported arch!" }}} The code that fails in '''rts/linker/ElfTypes.h''': {{{#!c # define ELF_TARGET_AMD64 /* Used inside on Solaris 11 */ #if defined(powerpc64_HOST_ARCH) || defined(powerpc64le_HOST_ARCH) \ || defined(ia64_HOST_ARCH) || defined(aarch64_HOST_ARCH) \ || defined(x86_64_HOST_ARCH) # define ELF_64BIT #elif defined(sparc_HOST_ARCH) || defined(i386_HOST_ARCH) \ || defined(arm_HOST_ARCH) # define ELF_32BIT #else # error "Unsupported arch!" #endif }}} Note it's a whitelist of architectures. It fails at least on '''powerpc''' (arm_HOST_ARCH), '''hppa'' (hppa_HOST_ARCH), '''m68k''' (m68k_HOST_ARCH). '''mips''', '''mips64''', '''alpha''', '''s390x''', '''sparc64'''. It does not look like keeping a whitelist is scalable here. How about using {{{#!c #if defined(__LP64__) || defined (_LP64) }}} as a proxy for ELF64 and maintain a list of arches that are exception instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 08:55:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 08:55:49 -0000 Subject: [GHC] #13696: rts/linker/ElfTypes.h does not compile on most of UNREG arches (and some registerised arches) In-Reply-To: <045.a86fc79f1bbf5d280a0a8610fc6376e7@haskell.org> References: <045.a86fc79f1bbf5d280a0a8610fc6376e7@haskell.org> Message-ID: <060.21389c88196a11e92121e5fff6a7bb1b@haskell.org> #13696: rts/linker/ElfTypes.h does not compile on most of UNREG arches (and some registerised arches) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by slyfox: @@ -25,1 +25,1 @@ - '''powerpc''' (arm_HOST_ARCH), '''hppa'' (hppa_HOST_ARCH), '''m68k''' + '''powerpc''' (arm_HOST_ARCH), '''hppa''' (hppa_HOST_ARCH), '''m68k''' New description: Builds fail as: {{{ rts_dist_HC rts/dist/build/RtsStartup.o rts/linker/ElfTypes.h:23:4: error: error: #error "Unsupported arch!" }}} The code that fails in '''rts/linker/ElfTypes.h''': {{{#!c # define ELF_TARGET_AMD64 /* Used inside on Solaris 11 */ #if defined(powerpc64_HOST_ARCH) || defined(powerpc64le_HOST_ARCH) \ || defined(ia64_HOST_ARCH) || defined(aarch64_HOST_ARCH) \ || defined(x86_64_HOST_ARCH) # define ELF_64BIT #elif defined(sparc_HOST_ARCH) || defined(i386_HOST_ARCH) \ || defined(arm_HOST_ARCH) # define ELF_32BIT #else # error "Unsupported arch!" #endif }}} Note it's a whitelist of architectures. It fails at least on '''powerpc''' (arm_HOST_ARCH), '''hppa''' (hppa_HOST_ARCH), '''m68k''' (m68k_HOST_ARCH). '''mips''', '''mips64''', '''alpha''', '''s390x''', '''sparc64'''. It does not look like keeping a whitelist is scalable here. How about using {{{#!c #if defined(__LP64__) || defined (_LP64) }}} as a proxy for ELF64 and maintain a list of arches that are exception instead? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 09:01:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 09:01:10 -0000 Subject: [GHC] #13696: rts/linker/ElfTypes.h does not compile on most of UNREG arches (and some registerised arches) In-Reply-To: <045.a86fc79f1bbf5d280a0a8610fc6376e7@haskell.org> References: <045.a86fc79f1bbf5d280a0a8610fc6376e7@haskell.org> Message-ID: <060.4aeb6aa56c1ebdfcf48986a87662e02c@haskell.org> #13696: rts/linker/ElfTypes.h does not compile on most of UNREG arches (and some registerised arches) -------------------------------------+------------------------------------- Reporter: slyfox | 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 slyfox): Example output for toolchains I have (note mips64 is an ELFCLASS32 aka N32 ABI): {{{ for gcc in /usr/bin/*gcc /usr/bin/*clang; do echo "$gcc :"; $gcc -dM -E -x c /dev/null | egrep LP64; done }}} {{{ /usr/bin/aarch64-unknown-linux-gnu-gcc : #define __LP64__ 1 #define _LP64 1 /usr/bin/afl-gcc : afl-cc 2.39b by #define __LP64__ 1 #define _LP64 1 /usr/bin/alpha-unknown-linux-gnu-gcc : #define __LP64__ 1 #define _LP64 1 /usr/bin/armv5tel-softfloat-linux-gnueabi-gcc : /usr/bin/armv7a-hardfloat-linux-gnueabi-gcc : /usr/bin/armv7a-unknown-linux-gnueabi-gcc : /usr/bin/gcc : #define __LP64__ 1 #define _LP64 1 /usr/bin/hppa-unknown-linux-gnu-gcc : /usr/bin/i686-w64-mingw32-gcc : /usr/bin/ia64-unknown-linux-gnu-gcc : #define __LP64__ 1 #define _LP64 1 /usr/bin/m68k-unknown-linux-gnu-gcc : /usr/bin/mips64-unknown-linux-gnu-gcc : /usr/bin/powerpc-unknown-linux-gnu-gcc : /usr/bin/powerpc64-unknown-linux-gnu-gcc : #define __LP64__ 1 #define _LP64 1 /usr/bin/powerpc64le-unknown-linux-gnu-gcc : #define __LP64__ 1 #define _LP64 1 /usr/bin/s390x-unknown-linux-gnu-gcc : #define __LP64__ 1 #define _LP64 1 /usr/bin/sparc-unknown-linux-gnu-gcc : /usr/bin/sparc64-unknown-linux-gnu-gcc : #define __LP64__ 1 #define _LP64 1 /usr/bin/winegcc : /usr/bin/x86_64-pc-linux-gnu-gcc : #define __LP64__ 1 #define _LP64 1 /usr/bin/x86_64-w64-mingw32-gcc : /usr/bin/afl-clang : afl-cc 2.39b by #define _LP64 1 #define __LP64__ 1 /usr/bin/clang : #define _LP64 1 #define __LP64__ 1 /usr/bin/i686-pc-linux-gnu-clang : /usr/bin/x86_64-pc-linux-gnu-clang : #define _LP64 1 #define __LP64__ 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 09:37:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 09:37:24 -0000 Subject: [GHC] #13696: rts/linker/ElfTypes.h does not compile on most of UNREG arches (and some registerised arches) In-Reply-To: <045.a86fc79f1bbf5d280a0a8610fc6376e7@haskell.org> References: <045.a86fc79f1bbf5d280a0a8610fc6376e7@haskell.org> Message-ID: <060.a249ef9db1afc3c84bc9de9e1698903d@haskell.org> #13696: rts/linker/ElfTypes.h does not compile on most of UNREG arches (and some registerised arches) -------------------------------------+------------------------------------- Reporter: slyfox | 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): Phab:D3583 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * differential: => Phab:D3583 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 10:22:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 10:22:37 -0000 Subject: [GHC] #12610: Emit tab warning promptly In-Reply-To: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> References: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> Message-ID: <060.5925ba0babdf5fa34da014e1cd353ca0@haskell.org> #12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dalaing Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3584 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dalaing): * status: new => patch * differential: => Phab:D3584 Comment: I'm not 100% sure on where we should be printing these warnings versus ignoring them. I've generally gone with doing whatever happens to the warnings in the case of a successful pass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 15:31:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 15:31:34 -0000 Subject: [GHC] #13697: Teach GHCi to deduplicate history Message-ID: <046.c52d80a53f320e24383a13d460949030@haskell.org> #13697: Teach GHCi to deduplicate history -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCi's (or rather, Haskeline's) history functionality tends to duplicate entries, even when the user used history to enter an entry. This is quite annoying and an issue I've not noticed in other command line libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 15:31:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 15:31:42 -0000 Subject: [GHC] #13697: Teach GHCi to deduplicate history In-Reply-To: <046.c52d80a53f320e24383a13d460949030@haskell.org> References: <046.c52d80a53f320e24383a13d460949030@haskell.org> Message-ID: <061.f90efc96c847de8e641ae163a7501123@haskell.org> #13697: Teach GHCi to deduplicate history -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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): * component: Compiler => GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 15:35:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 15:35:14 -0000 Subject: [GHC] #605: Optimisation: strict enumerations In-Reply-To: <047.930f12dd9816334e7bac59b319734f38@haskell.org> References: <047.930f12dd9816334e7bac59b319734f38@haskell.org> Message-ID: <062.85c4f0f862b2e4236eb544189a12a04c@haskell.org> #605: Optimisation: strict enumerations -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: #6135 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 15:40:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 15:40:52 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.2feb4813a043283795436f5264e9a480@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * priority: normal => high * related: 3990 => #3990 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 18:05:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 18:05:47 -0000 Subject: [GHC] #13698: Add a more complete example for the special SPEC argument to the user guide Message-ID: <049.23ffcb4436185135f464d56fa8cf6959@haskell.org> #13698: Add a more complete example for the special SPEC argument to the user guide -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: SpecConstr Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the section for `-fspec-constr` in the user guide there is an example of how to use `SPEC` to force a loop to be unrolled by spec constr. However, this argument doesn't do anything until `foldl` is called with a specific argument. It wasn't clear to me exactly how this worked as the example was incomplete. Below is a complete file which shows how the optimisation unrolls the list completely such that `res2 = 6` in core. {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE ExistentialQuantification #-} module Foo where import GHC.Types data Stream a = forall s. Stream !(s -> Step a s) -- a stepper function !s -- an initial state data Step a s = Yield a !s | Skip !s | Done s2 = Stream s [1,2,3] s [] = Done s (x:xs) = Yield x xs res2 = Foo.foldl (+) 0 s2 foldl :: (a -> b -> a) -> a -> Stream b -> a {-# INLINE foldl #-} foldl f z (Stream step s) = foldl_loop SPEC z s where foldl_loop !sPEC z s = case step s of Yield x s' -> foldl_loop sPEC (f z x) s' Skip s' -> foldl_loop sPEC z s' Done -> z }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 19:11:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 19:11:09 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.cb20a5a587888b7b75942f0e443f5361@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): with ghc 8.2.1-rc2 on a Mac, succeeds in less than 4gb , watching Activity Monitor, Memory max usage seems between 3.5 and 4gb: {{{ ulimit -v 4000000; cabal test ... Preprocessing test suite 'vector-tests-O2' for vector-0.12.0.1... ... [4 of 7] Compiling Tests.Vector ( tests/Tests/Vector.hs, dist/build /vector-tests-O2/vector-tests-O2-tmp/Tests/Vector.o ) ... tests/Tests/Vector.hs:438:5: warning: [-Wname-shadowing] This binding for ‘limitUnfolds’ shadows the existing binding imported from ‘Utilities’ at tests/Tests/Vector.hs:5:1-24 (and originally defined at tests/Utilities.hs:347:1-12) | 438 | limitUnfolds f (theirs, ours) | ^^^^^^^^^^^^ [5 of 7] Compiling Tests.Move ( tests/Tests/Move.hs, dist/build /vector-tests-O2/vector-tests-O2-tmp/Tests/Move.o ) ... [7 of 7] Compiling Main ( tests/Main.hs, dist/build/vector- tests-O2/vector-tests-O2-tmp/Main.o ) Linking dist/build/vector-tests-O2/vector-tests-O2 ... Running 2 test suites... Test suite vector-tests-O0: RUNNING... Test suite vector-tests-O0: PASS Test suite logged to: dist/test/vector-0.12.0.1-vector-tests-O0.log Test suite vector-tests-O2: RUNNING... Test suite vector-tests-O2: PASS Test suite logged to: dist/test/vector-0.12.0.1-vector-tests-O2.log 2 of 2 test suites (2 of 2 test cases) passed. bash-3.2$ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.0.20170507 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 19:23:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 19:23:19 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.2219c713aa6ae620367c040349e31903@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): 4 GB was a somewhat arbitrary number I picked. On my machine, compiling the tests on GHC 8.0.2 took about 1.6 GB, whereas with GHC 8.2.1, it took about 6.7 GB. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 19:26:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 19:26:46 -0000 Subject: [GHC] #13699: Pretty printing: Strict record fields are not parenthesized properly Message-ID: <043.b6fa972648fe3f86984213baf3e59df6@haskell.org> #13699: Pretty printing: Strict record fields are not parenthesized properly -------------------------------------+------------------------------------- Reporter: zyla | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.0.1 Keywords: pretty-print | Operating System: Unknown/Multiple bang record | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I type in GHCi: {{{ λ> data Foo = Foo { x :: !(Maybe Int) } λ> :i Foo data Foo = Foo {x :: !Maybe Int} -- Defined at :71:1 }}} But this is not legal Haskell syntax: {{{ λ> data Foo = Foo {x :: !Maybe Int} :73:22: error: • Unexpected strictness annotation: !Maybe • In the type ‘!Maybe Int’ In the definition of data constructor ‘Foo’ In the data declaration for ‘Foo’ }}} I think it should be pretty printed with parens: {{{ λ> :i Foo data Foo = Foo {x :: !(Maybe Int)} -- Defined at :71:1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 19:34:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 19:34:37 -0000 Subject: [GHC] #13696: rts/linker/ElfTypes.h does not compile on most of UNREG arches (and some registerised arches) In-Reply-To: <045.a86fc79f1bbf5d280a0a8610fc6376e7@haskell.org> References: <045.a86fc79f1bbf5d280a0a8610fc6376e7@haskell.org> Message-ID: <060.402a635c65b64cd75136e8fa4ff00c51@haskell.org> #13696: rts/linker/ElfTypes.h does not compile on most of UNREG arches (and some registerised arches) -------------------------------------+------------------------------------- Reporter: slyfox | 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): Phab:D3583 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"d5414dd61b540be3b3945c321065a1c70c7962ac/ghc" d5414dd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d5414dd61b540be3b3945c321065a1c70c7962ac" rts/linker/ElfTypes.h: restore powerps (and others) support GHC build fails for powerpc-unknown-linux-gnu and hppa-unknown-linux-gnu targets as: rts_dist_HC rts/dist/build/RtsStartup.o rts/linker/ElfTypes.h:23:4: error: error: #error "Unsupported arch!" Before the change code tried to whitelist architectures and classify them into ELF32/ELF64. It does not work for UNREG arches like 'hppa', 'sparc64', 'm68k', 'mips'. It is nuanced for things like mips64 and x86_64: 'mips64-unknown-linux-gnu-gcc -mabi=64' is ELFCLASS64 'mips64-unknown-linux-gnu-gcc' is ELFCLASS32 'x86_64-pc-linux-gnu-gcc' is ELFCLASS64 'x86_64-pc-linux-gnu-gcc -mx32' is ELFCLASS32 Here it's not enough to know HOST_ARCH. We really need to know ABI. The change uses '__LP64__' as a proxy for ELFCLASS64. Signed-off-by: Sergei Trofimovich Reviewers: angerman, simonmar, austin, bgamari, erikd Reviewed By: angerman, bgamari, erikd Subscribers: rwbarton, thomie GHC Trac Issues: #13696 Differential Revision: https://phabricator.haskell.org/D3583 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 19:37:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 19:37:49 -0000 Subject: [GHC] #13696: rts/linker/ElfTypes.h does not compile on most of UNREG arches (and some registerised arches) In-Reply-To: <045.a86fc79f1bbf5d280a0a8610fc6376e7@haskell.org> References: <045.a86fc79f1bbf5d280a0a8610fc6376e7@haskell.org> Message-ID: <060.28e36bedac51ae4c7619d901bee6bed9@haskell.org> #13696: rts/linker/ElfTypes.h does not compile on most of UNREG arches (and some registerised arches) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3583 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * status: new => closed * version: 8.0.1 => 8.3 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 19:41:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 19:41:29 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.02c7665ae28dc3d505b9f18217098bb7@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by RyanGlScott): I can't reproduce this error with GHC 8.2.1 or HEAD: {{{ $ /opt/ghc/8.2.1/bin/ghc -fforce-recomp -O2 BigWord.hs [1 of 3] Compiling BigWordClass ( BigWordClass.hs, BigWordClass.o ) [2 of 3] Compiling BigWordUnpack ( BigWordUnpack.hs, BigWordUnpack.o ) [3 of 3] Compiling BigWord ( BigWord.hs, BigWord.o ) }}} Is there something in particular I need to do to trigger this panic? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 19:53:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 19:53:49 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.dfa36b382cd1e9d05c9e8c9481bef35b@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Is there a way to see if this code is part of inner-cycle/fold/map so it's better to be inlined? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 20:08:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 20:08:12 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.99a23e769e5e6bd9bf254c00b46f4545@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by ryanreich): That's odd; it should "work" as-is. I wonder if I got the ghc version wrong? It's shown in the panic message, though: 8.2.0.20170505. Just in case this is an issue of some more obscure environment, let me post my stack.yaml and bigint.cabal as well. Also, here's my system info: {{{ ryan at thermophile $ uname -a Linux thermophile 4.8.0-49-generic #52-Ubuntu SMP Thu Apr 20 09:38:39 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux ryan at thermophile $ free -h total used free shared buff/cache available Mem: 7.7G 2.3G 1.9G 321M 3.5G 4.7G Swap: 3.7G 0B 3.7G ryan at thermophile $ cat /proc/cpuinfo processor : 3 (and 0, 1, 2) vendor_id : GenuineIntel cpu family : 6 model : 142 model name : Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz stepping : 9 microcode : 0x3c cpu MHz : 799.871 cache size : 4096 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp bugs : bogomips : 5800.00 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 20:08:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 20:08:40 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.e974fdb9f79819931a0e0857e82f0579@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by ryanreich): * Attachment "stack.yaml" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 20:08:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 20:08:53 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.6719a01d6ef98b00cf1a013bfd811965@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by ryanreich): * Attachment "bigint.cabal" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 20:29:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 20:29:41 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.a0a79877a8707acf457eda1ee84de84f@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by RyanGlScott): I wasn't able to reproduce this using `cabal build` or `stack build` either. Note that I obtained GHC 8.2.1: {{{ $ /opt/ghc/8.2.1/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.0.20170505 }}} and GHC HEAD: {{{ $ /opt/ghc/head/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 8.3.20170509 }}} from https://launchpad.net/~hvr/+archive/ubuntu/ghc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 20:54:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 20:54:37 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.17183ad8f756698fdb954548b90af617@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by ryanreich): I'm using exactly the same builds myself. I went and tried it with HEAD and it seemed to have the same failure, but after switching the version back and forth a few times it started actually working (!). I was doing `stack clean` in between, so the runs should have been independent. I can't make it happen at all anymore, so I wonder if it was an issue of the dynamic libraries with the same version having been mapped into memory, and now replaced with the correct one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 14 22:31:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 May 2017 22:31:08 -0000 Subject: [GHC] #7897: MakeTypeRep fingerprints be proper, robust fingerprints In-Reply-To: <046.71438f4eb0adc834d5130a615d3ff9d8@haskell.org> References: <046.71438f4eb0adc834d5130a615d3ff9d8@haskell.org> Message-ID: <061.d8c966749e041842057ec04363d3e469@haskell.org> #7897: MakeTypeRep fingerprints be proper, robust fingerprints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cdupont): I have a real use case for this bug in Hint: https://github.com/mvdan/hint/issues/31 Having proper fingerprints would allow to check the run time type representation and prevent the segfault. Is there a workaround? How to check the structure of a type at run-time? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 01:48:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 01:48:06 -0000 Subject: [GHC] #13699: Pretty printing: Strict record fields are not parenthesized properly In-Reply-To: <043.b6fa972648fe3f86984213baf3e59df6@haskell.org> References: <043.b6fa972648fe3f86984213baf3e59df6@haskell.org> Message-ID: <058.1a9cac2c54db26bf6fdff272baa21f16@haskell.org> #13699: Pretty printing: Strict record fields are not parenthesized properly -------------------------------------+------------------------------------- Reporter: zyla | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: pretty-print | bang record Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3587 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3587 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 02:52:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 02:52:50 -0000 Subject: [GHC] #7897: MakeTypeRep fingerprints be proper, robust fingerprints In-Reply-To: <046.71438f4eb0adc834d5130a615d3ff9d8@haskell.org> References: <046.71438f4eb0adc834d5130a615d3ff9d8@haskell.org> Message-ID: <061.3158d038b61290aebda63dbba96748dc@haskell.org> #7897: MakeTypeRep fingerprints be proper, robust fingerprints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): We don't currently offer a way to view the runtime representation of a type at runtime (other than I suppose `Generic`). That being said, we do generate Typeable evidence for promoted data constructors, so we already do much of the work necessary to do so. That being said, it's not clear that this would be a useful enough feature to justify the cost. As far as making the hash more precise is concerned, the data family issue is enough of am argument against rocking the boat without very good reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 06:10:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 06:10:59 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.9c1182d4a8701ff14f2c5d68ef12c713@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by ryanreich): Okay, I did another test and found that changing the 4 to a 5 in BigWord.hs causes the panic again. I don't know what number will "work" for you, but try increasing it until it does panic. Weirdly, switching between 8.2.1 and HEAD causes that to work, but changing it to 6 breaks it again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 08:34:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 08:34:07 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.a35d57ee6e76fd1dede61b57dda34c72@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): simonpj: I've added two examples that use IO. After a bit of work I managed to make a big improvement on `x2n1`: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- bspt -0.1% +0.1% 0.007 0.007 0.0% cacheprof -0.1% +0.1% +28.4% +28.4% +0.9% grep -0.1% -0.2% 0.000 0.000 0.0% maillist -0.1% -0.3% 0.053 0.053 0.0% hpg -0.1% -0.4% 0.205 0.205 0.0% pic -0.1% -0.6% 0.007 0.007 0.0% compress2 +0.2% -0.9% 0.196 0.196 -19.2% infer -0.1% -1.2% 0.069 0.069 0.0% sphere -0.1% -1.7% 0.049 0.049 0.0% solid -0.1% -6.6% 0.127 0.169 0.0% x2n1 -0.1% -84.7% 0.006 0.006 0.0% -------------------------------------------------------------------------------- Min -0.1% -84.7% -37.7% -35.7% -19.2% Max +0.2% +0.1% +34.3% +34.2% +0.9% Geometric Mean -0.1% -1.9% -2.6% -1.3% -0.2% }}} I wonder if this improvement justifies the added complexity to the compiler (about 400 lines of code added under `compiler/`). Right now I don't see any way to make the analysis/transformation more effective. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 08:38:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 08:38:11 -0000 Subject: [GHC] #13700: GHCi command listing possible type class instances Message-ID: <051.87a39f033f8a52ca51433d465661fe5a@haskell.org> #13700: GHCi command listing possible type class instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a reminder ticket, I want to be able to list possible instances, {{{ >>> :insts Product (Functor f, Functor g) => Functor (Product f g) (Applicative f, Applicative g) => Applicative (Product f g) ... >>> :insts Product Identity Functor g => Functor (Product Identity g) Applicative g => Applicative (Product Identity g) Monad g => Monad (Product Identity g) MonadFix g => MonadFix (Product Identity g) MonadZip g => MonadZip (Product Identity g) ... >>> :insts Product Identity Identity Functor (Product Identity Identity) Applicative (Product Identity Identity) Monad (Product Identity Identity) MonadFix (Product Identity Identity) MonadZip (Product Identity Identity) }}} Would be so useful for `GeneralizedNewtypeDeriving` {{{#!hs newtype Pair a = P (Product Identity Identity a) deriving (Functor, Applicative, Monad, MonadFix, MonadZip, ...) -- pattern (:#) :: a -> a -> Pair a -- pattern a1 :# a2 = P (Identity a1 `Pair` Identity a2) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 08:38:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 08:38:31 -0000 Subject: [GHC] #13700: GHCi command listing possible type class instances In-Reply-To: <051.87a39f033f8a52ca51433d465661fe5a@haskell.org> References: <051.87a39f033f8a52ca51433d465661fe5a@haskell.org> Message-ID: <066.4366a591b324321a09749fc30e5815d5@haskell.org> #13700: GHCi command listing possible type class instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack 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: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * owner: (none) => Iceland_jack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 12:15:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 12:15:47 -0000 Subject: [GHC] #13701: GHCi 2x slower without -keep-tmp-files Message-ID: <046.5313c8330fb56c9723008f1f4396a25a@haskell.org> #13701: GHCi 2x slower without -keep-tmp-files -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In D3562, I've observed that -keep-tmp-files makes :load 3x faster on my test case. I can't share my test case, but I've found a way to approximate it with `MultiLayerModules` I just added in D3575. Here are the steps: {{{ # in ghc top dir $ mkdir tmp $ cd tmp $ cp ../testsuite/tests/perf/compiler/genMultiLayerModules . # edit genMultiLayerModules to say DEPTH=0, WIDTH=5000 $ ./genMultiLayerModules $ echo ':load MultiLayerModules' | ../inplace/bin/ghc-stage2 --interactive +RTS -s 11,132,224,952 bytes allocated in the heap 1,004,238,408 bytes copied during GC 185,091,216 bytes maximum residency (14 sample(s)) 2,813,504 bytes maximum slop 365 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 706 colls, 0 par 0.907s 0.906s 0.0013s 0.0125s Gen 1 14 colls, 0 par 0.607s 0.606s 0.0433s 0.2244s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.000s elapsed) MUT time 20.219s ( 20.493s elapsed) GC time 1.514s ( 1.513s elapsed) EXIT time 0.000s ( 0.005s elapsed) Total time 21.733s ( 22.010s elapsed) Alloc rate 550,585,275 bytes per MUT second Productivity 93.0% of total user, 93.1% of total elapsed $ echo ':load MultiLayerModules' | ../inplace/bin/ghc-stage2 --interactive -keep-tmp-files +RTS -s 4,603,831,672 bytes allocated in the heap 971,623,904 bytes copied during GC 184,019,808 bytes maximum residency (14 sample(s)) 2,262,680 bytes maximum slop 365 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 448 colls, 0 par 0.724s 0.723s 0.0016s 0.0321s Gen 1 14 colls, 0 par 0.621s 0.620s 0.0443s 0.2242s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.000s elapsed) MUT time 7.966s ( 8.202s elapsed) GC time 1.345s ( 1.344s elapsed) EXIT time 0.000s ( 0.004s elapsed) Total time 9.312s ( 9.550s elapsed) Alloc rate 577,938,762 bytes per MUT second Productivity 85.5% of total user, 85.9% of total elapsed }}} So it's 2x slower and allocates 2.5x more. Profiling pointed to https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/main/SysTools.hs;8bf50d5026f92eb5a6768eb2ac38479802da1411$1074 We're creating `dont_delete_set` a lot. Looks like this was improved in D3111 recently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 12:22:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 12:22:50 -0000 Subject: [GHC] #13701: GHCi 2x slower without -keep-tmp-files In-Reply-To: <046.5313c8330fb56c9723008f1f4396a25a@haskell.org> References: <046.5313c8330fb56c9723008f1f4396a25a@haskell.org> Message-ID: <061.c1c664d76db22e0e636b335b0b5fd6ff@haskell.org> #13701: GHCi 2x slower without -keep-tmp-files -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Douglas Wilson (new contributor) was interested in looking at this. I've created this to coordinate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 13:32:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 13:32:58 -0000 Subject: [GHC] #13697: Teach GHCi to deduplicate history In-Reply-To: <046.c52d80a53f320e24383a13d460949030@haskell.org> References: <046.c52d80a53f320e24383a13d460949030@haskell.org> Message-ID: <061.7e74d76aaeed61488e1e7b34759eeee9@haskell.org> #13697: Teach GHCi to deduplicate history -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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): My command prompt (Mac's `Terminal`) doesn't do this (that is, deduplicate). It's not behavior I would expect. Where can I witness this in action? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 15:45:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 15:45:33 -0000 Subject: [GHC] #13697: Teach GHCi to deduplicate history In-Reply-To: <046.c52d80a53f320e24383a13d460949030@haskell.org> References: <046.c52d80a53f320e24383a13d460949030@haskell.org> Message-ID: <061.34de69ed825ba338192fbee36dd87156@haskell.org> #13697: Teach GHCi to deduplicate history -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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): Here's a quick reproducer, 1. Start `ghci`. 2. Enter a command: `putStrLn "hello" ` 3. Enter another command; `putStrLn "hi again" ` 4. Press `` once to select the `hi again` command, press `` 5. You will now need `` three times to get back to the `hello` command as the `hi again` command appears twice in history. This is in contrast to, e.g. `bash`, where it will only appear once. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 15:48:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 15:48:30 -0000 Subject: [GHC] #13697: Teach GHCi to deduplicate history In-Reply-To: <046.c52d80a53f320e24383a13d460949030@haskell.org> References: <046.c52d80a53f320e24383a13d460949030@haskell.org> Message-ID: <061.eb4f5049f41c080402ebd579f086e1c5@haskell.org> #13697: Teach GHCi to deduplicate history -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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 nomeata): What I observe in bash (and miss in ghci as well) is that {{{ $ ls $ ls $ history |tail -n 3 4992 man bash 4993 ls 4994 history |tail -n 3 }}} i.e. there are no *successive* duplicated entries. But {{{ $ ls $ echo hi $ ls $ history |tail -n 4 4995 ls 4996 echo hi 4997 ls 4998 history |tail -n 4 }}} so there is no duplication of everything. I believe the OP asks for the former (and I support this.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 15:57:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 15:57:18 -0000 Subject: [GHC] #13697: Teach GHCi to deduplicate history In-Reply-To: <046.c52d80a53f320e24383a13d460949030@haskell.org> References: <046.c52d80a53f320e24383a13d460949030@haskell.org> Message-ID: <061.498a262fe323693e4e48dcdea219cafb@haskell.org> #13697: Teach GHCi to deduplicate history -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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): > so there is no duplication of everything. I believe the OP asks for the former (and I support this.) Exactly; I should have been more clear about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 16:23:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 16:23:06 -0000 Subject: [GHC] #13692: Constructors and such should be able to move around seq# sometimes In-Reply-To: <045.5e5b5898d37db35c3d84d20dedecbcbf@haskell.org> References: <045.5e5b5898d37db35c3d84d20dedecbcbf@haskell.org> Message-ID: <060.9e9f51a07e4593d26542668ceecf53ab@haskell.org> #13692: Constructors and such should be able to move around seq# sometimes -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good point. Is it a performance-critical point? Or just an observation. `seq#` seems poorly documented in GHC's source code. It should really be called `evaluate#` for a start. I think it's important that it is ''not'' strict because I think the idea is that no earlier code should evaluate its argument. I guess this transformation would be sound {{{ seq (case e of p -> r) s --> seq e s of (# s', v #) -> case v of p -> seq r s' }}} which I think is more or less what you are suggesting. I have no idea if it'd be worth it; but I suppose it could be if it removed allocation from some inner loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 16:25:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 16:25:35 -0000 Subject: [GHC] #13697: Teach GHCi to deduplicate history In-Reply-To: <046.c52d80a53f320e24383a13d460949030@haskell.org> References: <046.c52d80a53f320e24383a13d460949030@haskell.org> Message-ID: <061.6523a56000d110e22acd4af32eac1fd7@haskell.org> #13697: Teach GHCi to deduplicate history -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm very confused. The following is on a Linux machine: {{{ 12:22:05 at powerpuff ~> echo $0 -bash 12:22:27 at powerpuff ~> echo "hello" hello 12:22:33 at powerpuff ~> echo "hello" hello 12:22:35 at powerpuff ~> history | tail -n 4 510 echo $0 511 echo "hello" 512 echo "hello" 513 history | tail -n 4 12:22:41 at powerpuff ~> }}} I have no recollection of ever considering this issue, so I don't believe I've set a configuration somewhere to change it. (And I looked at my `.bashrc` and see nothing working in this direction.) It's not that I'm opposed to the feature as proposed, exactly, but I feel like I'm missing some small superpower that the rest of you share... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 17:29:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 17:29:25 -0000 Subject: [GHC] #13697: Teach GHCi to deduplicate history In-Reply-To: <046.c52d80a53f320e24383a13d460949030@haskell.org> References: <046.c52d80a53f320e24383a13d460949030@haskell.org> Message-ID: <061.1a7ee3aefd4ee85c39e7f65974429e87@haskell.org> #13697: Teach GHCi to deduplicate history -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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): Ahh, indeed, it seems that I, long ago in a place far far away, added this incantation to my `bashrc`, {{{#!bash export HISTCONTROL=ignoredups ignorespace }}} I suspect this is responsible. In this case we may want to keep Haskeline's current behavior as-is, but it would be nice if `~/.haskeline` would have a similar option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 17:32:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 17:32:19 -0000 Subject: [GHC] #13697: Teach GHCi to deduplicate history In-Reply-To: <046.c52d80a53f320e24383a13d460949030@haskell.org> References: <046.c52d80a53f320e24383a13d460949030@haskell.org> Message-ID: <061.9bd0015ef90c4b0a9a4ed828ba2ab217@haskell.org> #13697: Teach GHCi to deduplicate history -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: Ahhh, [[https://github.com/judah/haskeline/wiki/UserPreferences|it seems]] that this already exists. Just, {{{#!bash echo "historyDuplicates: IgnoreConsecutive" >> ~/.haskeline }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 18:47:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 18:47:40 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.631ecf5aecca058c3d97a7d4902e08ff@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): varosi, the problem is that GHC considers the definitions of `lefts` and `rights` to be too large to inline and consequently doesn't produce unfoldings for them when compiling `GHC.Eithers`. This means that by the time we get to compiling your code we couldn't inline `lefts` and `rights` even if we wanted to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 21:53:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 21:53:15 -0000 Subject: [GHC] #13702: GHC can't produce position independent executables Message-ID: <046.3c2d010e4ff43df6076d32ac62165117@haskell.org> #13702: GHC can't produce position independent executables -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Due to #12759 we unconditionally pass `-no-pie` to GCC. However, there are legitimate reasons to want a PIE. We should have a `-fPIE` flag to match `-fPIC`, requesting that the compiler produce a position-independent executable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 22:06:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 22:06:25 -0000 Subject: [GHC] #13702: GHC can't produce position independent executables In-Reply-To: <046.3c2d010e4ff43df6076d32ac62165117@haskell.org> References: <046.3c2d010e4ff43df6076d32ac62165117@haskell.org> Message-ID: <061.5c4d47e17ffe745a6f58b612eacbdcd9@haskell.org> #13702: GHC can't produce position independent executables -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3589 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3589 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 15 22:12:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 May 2017 22:12:19 -0000 Subject: [GHC] #12610: Emit tab warning promptly In-Reply-To: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> References: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> Message-ID: <060.e9289bedf4a8f04e4d9aae2905d6a1d2@haskell.org> #12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dalaing Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3584 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"49012ebc9ed44a0b1f8de3781e15c8115d3074f8/ghc" 49012ebc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="49012ebc9ed44a0b1f8de3781e15c8115d3074f8" Print warnings on parser failures (#12610). Test Plan: validate Reviewers: austin, bgamari, simonmar, mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, thomie GHC Trac Issues: #12610 Differential Revision: https://phabricator.haskell.org/D3584 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 00:19:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 00:19:02 -0000 Subject: [GHC] #13658: Assertion failure on HEAD: "optCoercion changed types!" In-Reply-To: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> References: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> Message-ID: <061.c5ebca0aa575443011c8366d8d725801@haskell.org> #13658: Assertion failure on HEAD: "optCoercion changed types!" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T13658 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3545 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => simplCore/should_compile/T13658 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 01:12:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 01:12:50 -0000 Subject: [GHC] #13658: Assertion failure on HEAD: "optCoercion changed types!" In-Reply-To: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> References: <046.01a78cf6f092e4736f5fb456fb2d6ab4@haskell.org> Message-ID: <061.62ad3b7c8383ddc8bfc11268e0997c10@haskell.org> #13658: Assertion failure on HEAD: "optCoercion changed types!" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T13658 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3545 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with ca76ae071d9ffb4f36fc4b59ef9fa3bf3dfe2b8a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 01:13:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 01:13:49 -0000 Subject: [GHC] #13591: "*** Exception: expectJust showModule" in ghci with hs-boot In-Reply-To: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> References: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> Message-ID: <063.0f29b71a75b14b3d3c01564ed3f0a506@haskell.org> #13591: "*** Exception: expectJust showModule" in ghci with hs-boot -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: fixed | Keywords: ghci hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with f3ce36846bd3da3d957810f05d387d7699cd23e1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 01:17:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 01:17:09 -0000 Subject: [GHC] #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound In-Reply-To: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> References: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> Message-ID: <065.6fef997fda563188383f5954eedc1625@haskell.org> #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3572 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 72015aba0af37e0547150299049591e2a0ced270. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 01:17:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 01:17:46 -0000 Subject: [GHC] #13568: Name is reported as ambiguous and not in scope In-Reply-To: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> References: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> Message-ID: <064.635a48a5c775815d4f2ae4a9a2c7473b@haskell.org> #13568: Name is reported as ambiguous and not in scope -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3547 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Fixed with 343cb32d0983f576d344a2d04a35c3fd6eecf2c5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 01:18:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 01:18:21 -0000 Subject: [GHC] #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. In-Reply-To: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> References: <049.6d36839cc39a54658f3a94bca3b3e0fb@haskell.org> Message-ID: <064.ed57e84c1f93119a84d1b040a34b5463@haskell.org> #13649: RebindableSyntax causes type errors when 'fail' is not defined, even if not used. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: fixed | Keywords: | RebindableSyntax Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3553 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 56a4863b25687319a07db596bd47d724456317a5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 01:19:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 01:19:16 -0000 Subject: [GHC] #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... In-Reply-To: <046.97ac1572178bf3067f644135fab3a749@haskell.org> References: <046.97ac1572178bf3067f644135fab3a749@haskell.org> Message-ID: <061.f1d06963d24de4bae56a7966d167332d@haskell.org> #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T13662 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with b6f73dd7bacec13a7a8898fb0843efc10d4405e5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 01:20:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 01:20:06 -0000 Subject: [GHC] #13664: Ill formatted warning about tabulators In-Reply-To: <046.b26a1d2020e1e5fb1578aa510b2685ff@haskell.org> References: <046.b26a1d2020e1e5fb1578aa510b2685ff@haskell.org> Message-ID: <061.6bc819136d92f7e1397f0dd23b66527e@haskell.org> #13664: Ill formatted warning about tabulators -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3549 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with cd59db5a0dfb3b26a615036bcfdfd1c35d1e5e1d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 01:20:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 01:20:37 -0000 Subject: [GHC] #13677: Incorrect parenthesization of type in error message In-Reply-To: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> References: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> Message-ID: <065.939fb672ceaca2f0951e01c3add62da7@haskell.org> #13677: Incorrect parenthesization of type in error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3570 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 66d5e8015bed91fd0e2091641fe855c433c24b6c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 01:57:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 01:57:45 -0000 Subject: [GHC] #12056: Too aggressive `-w` option In-Reply-To: <042.615977cbd760a0223c1133d5e2a0fac1@haskell.org> References: <042.615977cbd760a0223c1133d5e2a0fac1@haskell.org> Message-ID: <057.655710c136ef327a8d71809f2287abef@haskell.org> #12056: Too aggressive `-w` option -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11429, #11789 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgillespie): * differential: Phab:D3581 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 02:08:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 02:08:38 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.fa073db47f04bc6acbbc544cf80eece7@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bollu Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12143 Related Tickets: #13309 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AaronFriel): @ekmett, @simonpj, @bgamari I am working on this issue and have a preliminary patch that explores the design space for this. For the exploring implementation, I added a new constructor of `ApplicativeArg`, `ApplicativeArgNil`, which lacks a pattern. To explore the design space and verify my type checking, I modified the renamer to use `<$` and `<*` (in place of `fmap` and `<*>`) if and only if every statement in the segment was an `ApplicativeArgNil`: {{{#!hs mkApplicativeStmt ctxt args need_join body_stmts | all isAppArgNil args = do { (replace_op, fvs1) <- lookupStmtName ctxt replaceFName ; (but_op, fvs2) <- lookupStmtName ctxt butAName ... }}} For the sake of faithfully implementing your proposed desugaring, I need to ask about this: {{{#!hs -- Example: f = do foo;bar;baz; x <- quux; y <- quaffle; return (xyzzy x y) -- Desugaring: f' = foo *> bar *> baz *> (xyzzy <$> quux <*> quaffle) }}} Is there a reason that desugaring is strictly better than: {{{#!hs -- Desugaring: f'' = xyzzy <$> (foo *> bar *> baz *> quux) <*> quaffle }}} I don't think it'd be too difficult to move the `*>` "then" operators to the beginning, but it would involve changing more of the existing applicative code to do so. I think that this style is more suited to addressing #13309. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 03:54:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 03:54:38 -0000 Subject: [GHC] #13703: Internal libraries regression in GHC 8.2 (ghc-pkg handling) Message-ID: <045.0eb24a47df9920808d8c257fd8ac90fc@haskell.org> #13703: Internal libraries regression in GHC 8.2 (ghc-pkg handling) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I register two internal libraries from the same package, they clobber each other. They should not do this. This regression was probably introduced by 579bb7669f40ed01841dd197ee535cf26fa19580. Working on a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 04:36:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 04:36:29 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.9e4ab7e0f73657061a99be5179da9ce8@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by RyanGlScott): * Attachment "BigWordClass2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 04:36:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 04:36:39 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.1dd58ed8b3695afce06d08ad168ba3cc@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by RyanGlScott): * Attachment "BigWordUnpack2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 04:36:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 04:36:51 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.14e2bc6dfaa6e260c244120e7be51674@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by RyanGlScott): * Attachment "BigWord2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 04:39:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 04:39:48 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.59969152214486bb13935d434261b9c1@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by RyanGlScott): Ah, it seems that rebuilding with slight changes is crucial to triggering this bug. I've attached simplified versions of your original programs that remove the Template Haskell stuff and make clear what specific change is needed to make GHC panic. In particular, to reproduce this bug, do the following with either GHC 8.2.1 or HEAD: 1. Run `/opt/ghc/8.2.1/bin/ghc BigWord2.hs -O2` 2. Edit `BigWord2.hs`, and uncomment the block of code at the bottom (the one that starts with `type instance BigWord 5 = BigWord5` and ends with `instance LowHigh BigWord4 where ...`) 3. Run `/opt/ghc/8.2.1/bin/ghc BigWord2.hs -O2` again: {{{ $ /opt/ghc/8.2.1/bin/ghc BigWord2.hs -O2 [3 of 3] Compiling BigWord2 ( BigWord2.hs, BigWord2.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170505 for x86_64-unknown-linux): urk! lookup local fingerprint D:R:DoubleWordDoubleWord4 [cESeWE :-> (BigWord2, 34dc4d50eaf3c3f1fec88a99dae21850), cESfxE :-> (BigWord3, 2b1c1772a861f399344dc06c29e7e7c0), cESfxF :-> (BigWord4, df345db7e7bc5c1dd0c73d6b038bc339), cESfxY :-> (BigWord5, 2b3cbb09e91bec36a2a2c359191139d2), cESg1l :-> (R:DoubleWordDoubleWord5, 00000000000000000000000000000000), cESg1n :-> (D:R:DoubleWordDoubleWord6, 00000000000000000000000000000000), cESg1v :-> (D:R:BigWord5, 560a80c635c7dd211457b5d4dab86d51), dESfxY :-> (BigWord5, 775d4a6ae2e1194445cb6e4252de8b91), iESfxY :-> (BigWord5, fc430fea13ebb9a94e051713cccf16ee), iESg1p :-> ($WBigWord5, c95ed7d25584a6ae4abaf9ae169cd259)] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/iface/MkIface.hs:508:37 in ghc:MkIface 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 May 16 04:42:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 04:42:57 -0000 Subject: [GHC] #13390: Strict literal float-out during desugaring regresses T1969 at -O0 In-Reply-To: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> References: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> Message-ID: <061.fd88eaa34ef9f804476bf5f0fc45f50b@haskell.org> #13390: Strict literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): bgamari asked me to summarize my current best guess very briefly, so here goes. I believe the basic problem when the string floating patch is applied is that we're seeing something like {{{#!hs \x -> c x }}} and deciding to inline `c` into the body of the lambda. In this case, at least, it would be better to eta reduce instead. I'm not sure that it would ever be advantageous to inline a function into such a removable lambda. I can't think of such a situation myself, but that doesn't mean much. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 05:44:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 05:44:58 -0000 Subject: [GHC] #13704: -main-is flag should change exports in default module header Message-ID: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> #13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The -main-is option to GHC should probably change the export list for the default module header. It doesn't. {{{ $ cat Main.hs program = return () $ ghc -main-is Main.program Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:1:1: error: Not in scope: ‘main’ Perhaps you meant ‘min’ (imported from Prelude) Main.hs:1:1: error: The main IO action ‘program’ is not exported by module ‘Main’ }}} I cannot imagine any possible use case for a feature that changes the entry point name to something else, and then deliberately fails to export the symbol by that name. This seems like an obvious thing to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 07:11:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 07:11:29 -0000 Subject: [GHC] #13309: Use liftA2 in ApplicativeDo In-Reply-To: <045.0874e12bcfabf449003f3d4de58526a5@haskell.org> References: <045.0874e12bcfabf449003f3d4de58526a5@haskell.org> Message-ID: <060.5b9fdee961212784a3dcb56d0f842d94@haskell.org> #13309: Use liftA2 in ApplicativeDo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: AaronFriel Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10892 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: (none) => AaronFriel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 07:50:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 07:50:25 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.0f9c6715840131e234e36c61c8a49668@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Here's a weird thing (possibly a separate bug?): if I `cabal clean; cabal configure --with-ghc=...; cabal build`, I get the failure. If I then `cabal build` again without cleaning, it works. Reid thinks this has something to do with a bug causing different info to pass from phase to phase through `.hi` files than otherwise; I haven't yet checked if it's been fixed. I'm currently bisecting this panic, and have narrowed it down to somewhere between d5518f72f3033ceaadc9b56a5d9012425b3a8956 and the 8.0.2 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 07:56:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 07:56:07 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.3a2e8fc9ef72cfbef2238e0c499ad7fb@haskell.org> #8657: -fregs-graph still has a limit on spill slots -------------------------------------+------------------------------------- Reporter: simonmar | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #7679 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): bgamari, can we close this ticket? The performance issue remains open as #7679. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 08:05:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 08:05:50 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.fa17f44268af14f4afa31fcb8b31befe@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by dfeuer): * cc: ezyang (added) Comment: It looks like ezyang was the last one to work in this general area; he may not be responsible, but it seems somewhat likely that he may still remember something about how this code works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 10:39:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 10:39:49 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.84e5deedccf3d95838a4109c6bcc648f@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bollu Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12143 Related Tickets: #13309 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Simon Marlow is the one who should respond here. Let's await his response. Meanwhile, I would ''strongly'' urge you to make a careful description of what you intend to do, using the language and notation of the paper. You could put the result as a sub-page of [wiki:ApplicativeDo]. Thanks for working on this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 11:14:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 11:14:43 -0000 Subject: [GHC] #13694: CSE runs before SpecConstr In-Reply-To: <049.2cc02e2cd17495b57fd9446870e30156@haskell.org> References: <049.2cc02e2cd17495b57fd9446870e30156@haskell.org> Message-ID: <064.579a411baef16be6ce39980bc942591e@haskell.org> #13694: CSE runs before SpecConstr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SpecConstr, | 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: SpecConstr, cse => SpecConstr, CSE Comment: Good plan. Would you like to try it out? (Certainly with -O2.) CSE is pretty cheap. It'd need a before-and-after nofib run to confirm any effects. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 11:18:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 11:18:20 -0000 Subject: [GHC] #13698: Add a more complete example for the special SPEC argument to the user guide In-Reply-To: <049.23ffcb4436185135f464d56fa8cf6959@haskell.org> References: <049.23ffcb4436185135f464d56fa8cf6959@haskell.org> Message-ID: <064.92dce576ec9a989b52c4e9012dc76935@haskell.org> #13698: Add a more complete example for the special SPEC argument to the user guide -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | 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: SpecConstr | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well the manual does say "After GHC inlines the body of `foldl` to a call site...". But I agree that the entire description is unclear; hardly a specification of the SPEC business. Could you improve it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 11:59:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 11:59:41 -0000 Subject: [GHC] #13705: Failure of improvement for type-family dependencies Message-ID: <046.9cec5d52ff4c5a82be0bc369e309b746@haskell.org> #13705: Failure of improvement for type-family dependencies -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE TypeFamilyDependencies #-} data D x type family F t = s | s -> t type instance F (D t) = D (F t) f :: F s -> () f _ = () g :: D (F t) -> () g x = f x }}} which was presented in [https://mail.haskell.org/pipermail/haskell- cafe/2016-October/125375.html this email] from Clinton Mead. It yields {{{ Tx.hs:14:9: error: • Couldn't match expected type ‘F s0’ with actual type ‘D (F t)’ The type variable ‘s0’ is ambiguous }}} But it should work fine -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 12:03:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 12:03:21 -0000 Subject: [GHC] #13705: Failure of improvement for type-family dependencies In-Reply-To: <046.9cec5d52ff4c5a82be0bc369e309b746@haskell.org> References: <046.9cec5d52ff4c5a82be0bc369e309b746@haskell.org> Message-ID: <061.1a144bba9b772046bdec030f9ddae2ac@haskell.org> #13705: Failure of improvement for type-family dependencies -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This program shows up a bug in the pure unifier in `Unify.hs`. Look at {{{ unify_ty ty1 (TyVarTy tv2) kco = do { unif <- amIUnifying ; if unif then umSwapRn $ uVar tv2 ty1 (mkSymCo kco) else surelyApart } -- non-tv on left; tv on right: can't match. }}} If we are matching {{{ F a ~ b }}} where `F` is a type function, we want to ''succeed'', not return `SurelyApart`, because in Algorithm U/M from the paper, type function applications are treated like wildcards. And indeed a later equation deals with that case {{{ unify_ty ty1 _ _ | Just (tc1, _) <- splitTyConApp_maybe ty1 , not (isGenerativeTyCon tc1 Nominal) = maybeApart }}} It's just that the type-variable case was too eager. Easy to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 12:03:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 12:03:47 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.559d2b6dac8c60e77a86d7f7e1482190@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_runt/T13623 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by choenerzs): With ghc 8.2.-rc2 my original program is now fast again. However, compared to ghc-8.0.1 it is now necessary to explicitly give {{{-fspec-constr- count=100}}} as otherwise I end up with insufficient specializations. (The {{{100}}} is rather arbitrary, but the default is definitely not enough) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 12:29:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 12:29:09 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.40a0fb6ec8b718cd4ceecbdb75ed7753@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bollu Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12143 Related Tickets: #13309 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I think they're both equivalent. Can you write down the desugaring rule? It seems to me we can use `*>` for *initial* ApplicativeArgNils in the group, and `<*` for *trailing* ApplicativeArgNils in the group. Anything in the middle will just need to behave like a wildcard pattern. Does that seem reasonable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 12:36:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 12:36:45 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.bd6f585c36cb5448aa462ee223bad7b9@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bollu Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12143 Related Tickets: #13309 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Well, I suppose we can do better than that (looking at the example in the description), it should be possible to handle ApplicativeArgNil anywhere in the group. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 13:33:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 13:33:00 -0000 Subject: [GHC] #13705: Failure of improvement for type-family dependencies In-Reply-To: <046.9cec5d52ff4c5a82be0bc369e309b746@haskell.org> References: <046.9cec5d52ff4c5a82be0bc369e309b746@haskell.org> Message-ID: <061.1e1255856e75a6b79f50dd8f63b9698e@haskell.org> #13705: Failure of improvement for type-family dependencies -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): For the record, I agree with comment:1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 14:03:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 14:03:21 -0000 Subject: [GHC] #13704: -main-is flag should change exports in default module header In-Reply-To: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> References: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> Message-ID: <061.ecaa3cbd609f7af7eb076c0365a8f897@haskell.org> #13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | 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 nomeata): Just giving a bit more context: The report specifies in https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-990005.1 that > An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be `module Main(main) where`. One could argue that the `-main-is`’s intention is to change *all* aspects of `Main.main`, i.e. not only the entry point, but also the default module header. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 14:16:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 14:16:07 -0000 Subject: [GHC] #13706: ghci messages like "Ok, modules loaded: ..." are impractical for large sets of modules Message-ID: <049.ea180dc159da65b4270e906a17cf9067@haskell.org> #13706: ghci messages like "Ok, modules loaded: ..." are impractical for large sets of modules -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ghci (in the default config) wants to show me all the modules that are currently loaded. If I have a great many of these (think: hundreds) then this is impractical, because I have to scroll back to see what actually interests me (output of last command). I can change the prompt (`:set prompt "> "`), but I don't see how to switch off the display of all module names in `:r` command. I have to scroll back (several screenfulls) to even find out whether the reload was successful, since the status (OK/Failed) is at the very beginning - and the reason for the Failure is before that. Cf. https://mail.haskell.org/pipermail/haskell-cafe/2017-May/126983.html (but there was no reaction) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 14:22:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 14:22:51 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.b9d6d7d15345342216f1c2584007f01e@haskell.org> #8657: -fregs-graph still has a limit on spill slots -------------------------------------+------------------------------------- Reporter: simonmar | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #7679 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I don't believe so, the limit is still present in the graph coloring allocator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 14:47:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 14:47:02 -0000 Subject: [GHC] #13679: Kill eqIfaceType In-Reply-To: <046.77537b9b11d93850811e91290669da0c@haskell.org> References: <046.77537b9b11d93850811e91290669da0c@haskell.org> Message-ID: <061.4265ec7b9ddc0acbda3dafde88a66beb@haskell.org> #13679: Kill eqIfaceType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2c21d74cb1778eb390ee8d71465136fcd8289f4a/ghc" 2c21d74/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2c21d74cb1778eb390ee8d71465136fcd8289f4a" Kill off unused IfaceType.eqIfaceType Edward implemented these functions, but they aren't used any more. Trac #13679 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 14:47:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 14:47:02 -0000 Subject: [GHC] #13705: Failure of improvement for type-family dependencies In-Reply-To: <046.9cec5d52ff4c5a82be0bc369e309b746@haskell.org> References: <046.9cec5d52ff4c5a82be0bc369e309b746@haskell.org> Message-ID: <061.ee8fd4ef911a1800943623cb260729f9@haskell.org> #13705: Failure of improvement for type-family dependencies -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"cec7d580c2c033c3aaeba093752328d8f3635cd0/ghc" cec7d58/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cec7d580c2c033c3aaeba093752328d8f3635cd0" Fix the pure unifier This patch fixes Trac #13705, by fixing a long-standing outright bug in the pure unifier. I'm surprised this hasn't caused more trouble before now! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 14:56:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 14:56:06 -0000 Subject: [GHC] #13705: Failure of improvement for type-family dependencies In-Reply-To: <046.9cec5d52ff4c5a82be0bc369e309b746@haskell.org> References: <046.9cec5d52ff4c5a82be0bc369e309b746@haskell.org> Message-ID: <061.fa1f4206eda7a7ff34f7e23880a99d6e@haskell.org> #13705: Failure of improvement for type-family dependencies -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The reason this hasn't caused chaos sooner is that the pure unifier should never really see type functions. The only place it does, I believe, is in checking injectivity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 14:57:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 14:57:34 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.0c3b8f89758e0217dad570ea40a181ea@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 14:58:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 14:58:12 -0000 Subject: [GHC] #13679: Kill eqIfaceType In-Reply-To: <046.77537b9b11d93850811e91290669da0c@haskell.org> References: <046.77537b9b11d93850811e91290669da0c@haskell.org> Message-ID: <061.bd92ee1f2dc562bf0f04e1aa406a594c@haskell.org> #13679: Kill eqIfaceType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 14:58:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 14:58:13 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.5cdd7d15392f00a90056bdc18f7d20d1@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3569 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 14:58:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 14:58:30 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.c5bc3c1bf27f98015ef78dcdea56f151@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 14:59:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 14:59:09 -0000 Subject: [GHC] #13703: Internal libraries regression in GHC 8.2 (ghc-pkg handling) In-Reply-To: <045.0eb24a47df9920808d8c257fd8ac90fc@haskell.org> References: <045.0eb24a47df9920808d8c257fd8ac90fc@haskell.org> Message-ID: <060.d0231b51e8c86c764efadc4f32faa381@haskell.org> #13703: Internal libraries regression in GHC 8.2 (ghc-pkg handling) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3590 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3590 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 15:45:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 15:45:24 -0000 Subject: [GHC] #13705: Failure of improvement for type-family dependencies In-Reply-To: <046.9cec5d52ff4c5a82be0bc369e309b746@haskell.org> References: <046.9cec5d52ff4c5a82be0bc369e309b746@haskell.org> Message-ID: <061.7b180b2ccd07b74a85e34506802a8b45@haskell.org> #13705: Failure of improvement for type-family dependencies -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: merge 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: indexed- | types/should_compile/T13705 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => indexed-types/should_compile/T13705 Comment: Might be worth merging, but definitely not essential. I ended up refactoring the unifer to make the environment an explicit parameter, so that it's easier to use in guards. So the patch is bigger than it "needs" to be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 18:19:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 18:19:12 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? Message-ID: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@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 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: -------------------------------------+------------------------------------- Markus Trippelsdorf on `ghc-devs` reports that 8.2.1-rc2 produces crashing `xmobar` executables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 18:20:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 18:20:40 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.16d04f0a2c7f275f2adce9ceb8c51c2c@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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -3,0 +3,14 @@ + {{{ + Program received signal SIGSEGV, Segmentation fault. + 0x0000000000873aa8 in ghczmprim_GHCziClasses_eqChar_info () + }}} + or: + {{{ + Program received signal SIGSEGV, Segmentation fault. + 0x0000000000873f98 in ghczmprim_GHCziClasses_zdfEqModulezuzdszdczeze_info + () + (gdb) bt + #0 0x0000000000873f98 in + ghczmprim_GHCziClasses_zdfEqModulezuzdszdczeze_info () + #1 0x0000000000000000 in ?? () + }}} New description: Markus Trippelsdorf on `ghc-devs` reports that 8.2.1-rc2 produces crashing `xmobar` executables. {{{ Program received signal SIGSEGV, Segmentation fault. 0x0000000000873aa8 in ghczmprim_GHCziClasses_eqChar_info () }}} or: {{{ Program received signal SIGSEGV, Segmentation fault. 0x0000000000873f98 in ghczmprim_GHCziClasses_zdfEqModulezuzdszdczeze_info () (gdb) bt #0 0x0000000000873f98 in ghczmprim_GHCziClasses_zdfEqModulezuzdszdczeze_info () #1 0x0000000000000000 in ?? () }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 18:20:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 18:20:56 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.5f74436231e8325019cdce64f525b442@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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -3,0 +3,1 @@ + @@ -7,1 +8,3 @@ - or: + + or: + New description: Markus Trippelsdorf on `ghc-devs` reports that 8.2.1-rc2 produces crashing `xmobar` executables. {{{ Program received signal SIGSEGV, Segmentation fault. 0x0000000000873aa8 in ghczmprim_GHCziClasses_eqChar_info () }}} or: {{{ Program received signal SIGSEGV, Segmentation fault. 0x0000000000873f98 in ghczmprim_GHCziClasses_zdfEqModulezuzdszdczeze_info () (gdb) bt #0 0x0000000000873f98 in ghczmprim_GHCziClasses_zdfEqModulezuzdszdczeze_info () #1 0x0000000000000000 in ?? () }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 18:29:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 18:29:34 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.e395e48f1ef76b96901380a8530a413d@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): hm, strange. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 18:38:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 18:38:50 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.2f7249da4cb13d5939c40a41a72be0df@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 trippels): Not sure if it matters, but I built the latest xmobar git tree with -O2. {{{ ~ % cat .xmobarrc Config { font = "xft:Consolas:size=8" , bgColor = "#fafafa" , fgColor = "#606060" , position = BottomSize C 100 0 , lowerOnStart = True , hideOnStart = False , persistent = False , commands = [ Run Weather "EDDT" ["-t","°C %"] 18000 , Run Network "eth0" ["-t"," ","-w","4"] 10 , Run Cpu ["-t","%","-L","3","-H","50","-- normal","blue","--high","red"] 10 , Run Date "%a %b %_d %H:%M" "date" 10 , Run Com "/home/markus/cputemp" [] "temp" 100 , Run Com "/home/markus/loadav" [] "loadav" 100 , Run StdinReader ] , sepChar = "%" , alignSep = "}{" , template = "%StdinReader% }{%cpu% | %loadav% | %temp%°C | %eth0% | %EDDT% | %date%" } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 18:45:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 18:45:00 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.23e275b9337789e770e16200894a80c2@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 trippels): {{{ markus at x4 xmobar % cat /home/markus/cputemp cat /sys/bus/pci/drivers/k10temp/0000:00:18.3/hwmon/hwmon1/temp1_input | awk '{printf "%.1f", $1/1000}' markus at x4 xmobar % cat /home/markus/loadav cat /proc/loadavg | cut -d " " -f 1,2,3 markus at x4 xmobar % cabal install --flags="with_xft with_utf8" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 18:49:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 18:49:58 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.39f23ff4a446da76054c27139920a8c6@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bollu Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12143 Related Tickets: #13309 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AaronFriel): Yes, I was wondering about that too. Edward writes: "`(*>)` is typically a little cheaper than `(<*)`.", which suggests using the `*>` everywhere except in the tail, where we would use `<*`. Thus: {{{ do x <- foo bar y <- baz return ... ⇕ (\x y -> ...) <$> foo <*> (bar *> baz) }}} That is, we can merge any `ApplicativeArgNil lhsExpr` with a following `ApplicativeArg? rhsExpr`, by omitting the `ApplicativeArgNil` and creating a new `ApplicativeArg? rhsExpr'`, where `rhsExpr' = lhsExpr *> rhsExpr`. In cases where there is no subsequent statement, we use `<*`. This rewriting has the benefit of neatly addressing adding `liftA2`, as `ApplicativeArgNil` statements will be folded into `ApplicativeArgOne`/`ApplicativeArgMany`. e.g.: {{{ do foo x <- bar baz y <- quux quaffle return (xyzzy x y) ⇕ (\x y -> xyzzy x y) <$> (foo *> bar) <*> (baz *> quux) <* quaffle ⇕ liftAt (\x y -> xyzzy x y) (foo *> bar) (baz *> quux) <* quaffle }}} I'm working on the syntax and desugaring rules to address this and #13309. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 20:59:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 20:59:50 -0000 Subject: [GHC] #13706: ghci messages like "Ok, modules loaded: ..." are impractical for large sets of modules In-Reply-To: <049.ea180dc159da65b4270e906a17cf9067@haskell.org> References: <049.ea180dc159da65b4270e906a17cf9067@haskell.org> Message-ID: <064.142f91929c7d5e7dc1dc08b5047c51a7@haskell.org> #13706: ghci messages like "Ok, modules loaded: ..." are impractical for large sets of modules -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: JaffaCake (added) Comment: CCing Simon, who also uses GHCi with large numbers of modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 21:07:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 21:07:05 -0000 Subject: [GHC] #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 Message-ID: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The bug can be reproduced but it does take some setup. Here's the error report in case it's familiar: {{{ ... [1 of 2] Compiling Valuators ( .stack- work/dist/x86_64-linux/Cabal-2.0.0.0/build/fltkhs-fluid-valuators/fltkhs- fluid-valuators-tmp/Valuators.hs, .stack- work/dist/x86_64-linux/Cabal-2.0.0.0/build/fltkhs-fluid-valuators/fltkhs- fluid-valuators-tmp/Valuators.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-unknown-linux): idInfo a_ad4D Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The bug is a GUI binding. Reproducing is reliable but unfortunately takes some setup. To reproduce: {{{ # Install the FLTK GUI toolkit from source. > wget http://fltk.org/pub/fltk/1.3.4/fltk-1.3.4-1-source.tar.gz > tar -zxf fltk-1.3.4-1-source.tar.gz > cd fltk-1.3.4-1 > ./configure --enable-gl --enable-shared --enable-localjpeg --enable- localzlib --enable-localpng > make > sudo make install > fltk-config --version 1.3.4-1 # Install the bindings from source > git clone -b 8.2.1-rc2 https://github.com/deech/fltkhs > cd fltkhs > cabal install # Install the package causing the bug from source > git clone -b 8.2.1-rc2 https://github.com/deech/fltkhs-fluid-demos > cd fltkhs-fluid-demos > cabal install }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 21:20:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 21:20:17 -0000 Subject: [GHC] #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 In-Reply-To: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> References: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> Message-ID: <059.939ef2b59106fe9a045bb3fa0e11cccc@haskell.org> #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by deech: @@ -26,2 +26,1 @@ - The bug is a GUI binding. Reproducing is reliable but unfortunately takes - some setup. To reproduce: + The bug is in a demo for a GUI binding. To reproduce: New description: The bug can be reproduced but it does take some setup. Here's the error report in case it's familiar: {{{ ... [1 of 2] Compiling Valuators ( .stack- work/dist/x86_64-linux/Cabal-2.0.0.0/build/fltkhs-fluid-valuators/fltkhs- fluid-valuators-tmp/Valuators.hs, .stack- work/dist/x86_64-linux/Cabal-2.0.0.0/build/fltkhs-fluid-valuators/fltkhs- fluid-valuators-tmp/Valuators.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-unknown-linux): idInfo a_ad4D Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The bug is in a demo for a GUI binding. To reproduce: {{{ # Install the FLTK GUI toolkit from source. > wget http://fltk.org/pub/fltk/1.3.4/fltk-1.3.4-1-source.tar.gz > tar -zxf fltk-1.3.4-1-source.tar.gz > cd fltk-1.3.4-1 > ./configure --enable-gl --enable-shared --enable-localjpeg --enable- localzlib --enable-localpng > make > sudo make install > fltk-config --version 1.3.4-1 # Install the bindings from source > git clone -b 8.2.1-rc2 https://github.com/deech/fltkhs > cd fltkhs > cabal install # Install the package causing the bug from source > git clone -b 8.2.1-rc2 https://github.com/deech/fltkhs-fluid-demos > cd fltkhs-fluid-demos > cabal install }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 21:24:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 21:24:26 -0000 Subject: [GHC] #13709: Drop GCC Driver Message-ID: <044.530378a7ad6f5c3b791a9c874c84177d@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 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The original reason for the Windows GCC driver was to correct hard-coded paths in the GCC build from the `msys` project. The `msys2` builds we now exclusively use no longer have these issues. Which means 90% of the reason for the driver is gone. Given the recent issues with the driver. We can/should simplify things and drop it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 21:34:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 21:34:36 -0000 Subject: [GHC] #13709: Drop GCC Driver In-Reply-To: <044.530378a7ad6f5c3b791a9c874c84177d@haskell.org> References: <044.530378a7ad6f5c3b791a9c874c84177d@haskell.org> Message-ID: <059.ef438934fdb72802ede47d1ad93d82f0@haskell.org> #13709: Drop GCC Driver ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3592 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * differential: => Phab:D3592 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 21:34:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 21:34:47 -0000 Subject: [GHC] #13709: Drop GCC Driver In-Reply-To: <044.530378a7ad6f5c3b791a9c874c84177d@haskell.org> References: <044.530378a7ad6f5c3b791a9c874c84177d@haskell.org> Message-ID: <059.e7e60ce4e8940f53df040adae34a2ac0@haskell.org> #13709: Drop GCC Driver ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: patch 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: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 21:40:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 21:40:49 -0000 Subject: [GHC] #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 In-Reply-To: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> References: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> Message-ID: <059.5f65ec862ea7bf9c02ea03a987f8bb0d@haskell.org> #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by deech: @@ -1,2 +1,3 @@ - The bug can be reproduced but it does take some setup. Here's the error - report in case it's familiar: + The following causes a panic in GHC 8.2.1 rc2: + {{{ + module Main where @@ -4,18 +5,5 @@ - {{{ - ... - [1 of 2] Compiling Valuators ( .stack- - work/dist/x86_64-linux/Cabal-2.0.0.0/build/fltkhs-fluid-valuators/fltkhs- - fluid-valuators-tmp/Valuators.hs, .stack- - work/dist/x86_64-linux/Cabal-2.0.0.0/build/fltkhs-fluid-valuators/fltkhs- - fluid-valuators-tmp/Valuators.o ) - ghc: panic! (the 'impossible' happened) - (GHC version 8.2.0.20170507 for x86_64-unknown-linux): - idInfo - a_ad4D - Call stack: - CallStack (from HasCallStack): - prettyCurrentCallStack, called at - compiler/utils/Outputable.hs:1134:58 in ghc:Outputable - callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in - ghc:Outputable - pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var + indexOr :: a -> Int -> [a] -> a + indexOr fallback idx xs = + if (idx < length xs) + then xs !! idx + else fallback @@ -23,1 +11,2 @@ - Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug + main :: IO () + main = undefined @@ -26,1 +15,17 @@ - The bug is in a demo for a GUI binding. To reproduce: + When compiling I get: + {{{ + [1 of 1] Compiling Main ( src/Examples/table-sort.hs, + .stack-work/dist/x86_64-linux/Cabal-2.0.0.0/build/fltkhs-table-sort + /fltkhs-table-sort-tmp/Main.o ) + ghc: panic! (the 'impossible' happened) + (GHC version 8.2.0.20170507 for x86_64-unknown-linux): + idInfo + a_a2ws + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at + compiler/utils/Outputable.hs:1134:58 in ghc:Outputable + callStackDoc, called at compiler/utils/Outputable.hs:1138:37 + in ghc:Outputable + pprPanic, called at compiler/basicTypes/Var.hs:526:34 in + ghc:Var @@ -28,21 +33,2 @@ - {{{ - # Install the FLTK GUI toolkit from source. - > wget http://fltk.org/pub/fltk/1.3.4/fltk-1.3.4-1-source.tar.gz - > tar -zxf fltk-1.3.4-1-source.tar.gz - > cd fltk-1.3.4-1 - > ./configure --enable-gl --enable-shared --enable-localjpeg --enable- - localzlib --enable-localpng - > make - > sudo make install - > fltk-config --version - 1.3.4-1 - - # Install the bindings from source - > git clone -b 8.2.1-rc2 https://github.com/deech/fltkhs - > cd fltkhs - > cabal install - - # Install the package causing the bug from source - > git clone -b 8.2.1-rc2 https://github.com/deech/fltkhs-fluid-demos - > cd fltkhs-fluid-demos - > cabal install + Please report this as a GHC bug: + http://www.haskell.org/ghc/reportabug New description: The following causes a panic in GHC 8.2.1 rc2: {{{ module Main where indexOr :: a -> Int -> [a] -> a indexOr fallback idx xs = if (idx < length xs) then xs !! idx else fallback main :: IO () main = undefined }}} When compiling I get: {{{ [1 of 1] Compiling Main ( src/Examples/table-sort.hs, .stack-work/dist/x86_64-linux/Cabal-2.0.0.0/build/fltkhs-table-sort /fltkhs-table-sort-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-unknown-linux): idInfo a_a2ws Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var 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 May 16 21:44:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 21:44:58 -0000 Subject: [GHC] #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 In-Reply-To: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> References: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> Message-ID: <059.b2761f7f9132b1f1384f22f5bb2aca59@haskell.org> #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I can't reproduce this, what exact command are you using to compile? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 22:08:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 22:08:48 -0000 Subject: [GHC] #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 In-Reply-To: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> References: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> Message-ID: <059.165c78cb54eff044e05d0925936885c3@haskell.org> #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by deech): The problem is possibly being caused by some ghc options I'm using. I've created a self contained repo [1] that reproduces the bug on my machine when building with 'stack build'. It should work for 'cabal install' as well. [1] https://github.com/deech/821rc2-panic-bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 22:56:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 22:56:33 -0000 Subject: [GHC] #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 In-Reply-To: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> References: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> Message-ID: <059.8455fe85f930b84d2239021c751ae4c2@haskell.org> #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I can reproduce this now with {{{ /usr/local/bin/ghc-8.2.0.20170507 -O src/821rc2-panic-bug.hs '-fmax- simplifier-iterations=0' -fforce-recomp }}} The `-O` and `-fmax-simplifier-iterations` are both necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 23:00:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 23:00:31 -0000 Subject: [GHC] #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 In-Reply-To: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> References: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> Message-ID: <059.1b9ee1b3eb170f1571ab6992a9202097@haskell.org> #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by deech): Does one of these other flags [1] imply `-O` because I don't explicitly use it in the example? [1] https://github.com/deech/821rc2-panic-bug/blob/master/821rc2-panic- bug.cabal#L22 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 16 23:02:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 May 2017 23:02:07 -0000 Subject: [GHC] #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 In-Reply-To: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> References: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> Message-ID: <059.7efb9062ed1338e5d029fe193bbf8a18@haskell.org> #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I pasted the command line which cabal runs (which you can find by using `-v`) and removed arguments. Cabal compiles executables with -O by default I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 02:00:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 02:00:04 -0000 Subject: [GHC] #13703: Internal libraries regression in GHC 8.2 (ghc-pkg handling) In-Reply-To: <045.0eb24a47df9920808d8c257fd8ac90fc@haskell.org> References: <045.0eb24a47df9920808d8c257fd8ac90fc@haskell.org> Message-ID: <060.2738063d5c83b9861b8e396206e10f08@haskell.org> #13703: Internal libraries regression in GHC 8.2 (ghc-pkg handling) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3590 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"d9e9a9b3016a05e6153de3803998877f91c6cdf4/ghc" d9e9a9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d9e9a9b3016a05e6153de3803998877f91c6cdf4" Fix #13703 by correctly using munged names in ghc-pkg. Summary: Cabal internal libraries are implemented using a trick, where the 'name' field in ghc-pkg registration file is munged into a new form to keep each internal library looking like a distinct package to ghc-pkg and other tools; e.g. the internal library q from package p is named z-p-z-q. Later, Cabal library got refactored so that we made a closer distinction between these "munged" package names and the true package name of a package. Unfortunately, this is an example of a refactor for clarity in the source code which ends up causing problems downstream, because the point of "munging" the package name was to make it so that ghc-pkg and similar tools transparently used MungedPackageName whereever they previously used PackageName (in preparation for them learning proper syntax for package name + component name). Failing to do this meant that internal libraries from the same package (but with different names) clobber each other. This commit search-replaces most occurrences of PackageName in ghc-pkg and turns them into MungedPackageName. Otherwise there shouldn't be any functional differenes. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: bgamari, austin Subscribers: rwbarton, thomie GHC Trac Issues: #13703 Differential Revision: https://phabricator.haskell.org/D3590 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 02:16:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 02:16:01 -0000 Subject: [GHC] #13703: Internal libraries regression in GHC 8.2 (ghc-pkg handling) In-Reply-To: <045.0eb24a47df9920808d8c257fd8ac90fc@haskell.org> References: <045.0eb24a47df9920808d8c257fd8ac90fc@haskell.org> Message-ID: <060.92e090cb70a95cbedec9a5604d7f1a91@haskell.org> #13703: Internal libraries regression in GHC 8.2 (ghc-pkg handling) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3590 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 02:42:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 02:42:55 -0000 Subject: [GHC] #13701: GHCi 2x slower without -keep-tmp-files In-Reply-To: <046.5313c8330fb56c9723008f1f4396a25a@haskell.org> References: <046.5313c8330fb56c9723008f1f4396a25a@haskell.org> Message-ID: <061.876f814e5e1310ef68ce2c72a0d50393@haskell.org> #13701: GHCi 2x slower without -keep-tmp-files -------------------------------------+------------------------------------- Reporter: niteria | Owner: duog Type: task | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * cc: duog (added) * owner: (none) => duog Comment: Thanks niteria, I'll look at this soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 02:50:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 02:50:49 -0000 Subject: [GHC] #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 In-Reply-To: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> References: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> Message-ID: <059.f6f36d5459ac933669728ba5d61a42c9@haskell.org> #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): FWIW, commit 8d5cf8bf584fd4849917c29d82dcf46ee75dd035 (Join points) is the culprit here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 04:17:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 04:17:24 -0000 Subject: [GHC] #13710: panic with boot and -jX Message-ID: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ % cat A.hs module A where }}} {{{ % cat A.hs-boot module A ( A ) where type A = Maybe () yay :: A -> IO () }}} {{{ % cat B.hs module B where import {-# SOURCE #-} A }}} This panics: {{{ % rm -rf o ; ghc -j2 -outputdir o B [1 of 3] Compiling A[boot] ( A.hs-boot, o/A.o-boot ) [2 of 3] Compiling A ( A.hs, o/A.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170503 for x86_64-unknown-linux): tcIfaceGlobal (local): not found You are in a maze of twisty little passages, all alike. While forcing the thunk for TyThing A which was lazily initialized by initIfaceCheck typecheckLoop, I tried to tie the knot, but I couldn't find A in the current type environment. If you are developing GHC, please read Note [Tying the knot] and Note [Type-checking inside the knot]. Consider rebuilding GHC with profiling for a better stack trace. Contents of current type environment: [r15J :-> Identifier ‘$trModule’] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/iface/TcIface.hs:1689:23 in ghc:TcIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This works: {{{ % rm -rf o ; ghc -j1 -outputdir o B [1 of 3] Compiling A[boot] ( A.hs-boot, o/A.o-boot ) [2 of 3] Compiling A ( A.hs, o/A.o ) A.hs-boot:3:1: error: ‘A.A’ is exported by the hs-boot file, but not exported by the module | 3 | type A = Maybe () | ^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 04:37:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 04:37:31 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.1433e8f56f809bd8f87a9347f98551e1@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): works as expected in 8.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 05:53:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 05:53:26 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.572828881f855c62f90e0289d768b596@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 trippels): Also happens when build with -O1. Unfortunately, it can take several hours to hit the crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 07:52:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 07:52:26 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.40d6570f4041ac3f09aaa5ea3e7a94c4@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ezyang (added) Comment: I think this is Edward's error message. Edward might you look? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 08:52:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 08:52:36 -0000 Subject: [GHC] #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 In-Reply-To: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> References: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> Message-ID: <059.d4dd8c60035fa054ce8f1411767c7a38@haskell.org> #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Patch incoming -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 10:10:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 10:10:17 -0000 Subject: [GHC] #13711: uname: illegal option -- o when running make clean in nofib Message-ID: <049.88cdc224335cf1541b7c50c6988ce9ec@haskell.org> #13711: uname: illegal option -- o when running make clean in nofib -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib | Version: 8.0.1 benchmark suite | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When running `make clean` in nofib, there are lots of warnings/errors like the following. I don't know if this is serious or not. I am on OS X. {{{ uname: illegal option -- o usage: uname [-amnprsv] rm -f Main.o *.CKP *.ln *.BAK *.bak .*.bak *.o core a.out errs ,* *.a .emacs_* tags TAGS *.ind *.ilg *.idx *.idx-prev *.aux *.aux-prev *.dvi *.log *.toc *.lot *.lof *.blg *.cb *_stub.c *_stub.h *.raw_s *.a.list a.out ./*.hi Main.hc reverse-complement Finished making clean in reverse-complement: 0 ------------------------------------------------------------------------ == /Applications/Xcode.app/Contents/Developer/usr/bin/make clean - --no- print-directory; in /Users/matt/Documents/haskell/ghc/nofib/shootout/spectral-norm ------------------------------------------------------------------------ uname: illegal option -- o usage: uname [-amnprsv] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 12:48:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 12:48:06 -0000 Subject: [GHC] #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 In-Reply-To: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> References: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> Message-ID: <059.07373404dbaef8bebe0d7db384bfab6e@haskell.org> #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d6461f9684f6f758320a5e5afbf0634fcc2996a5/ghc" d6461f96/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d6461f9684f6f758320a5e5afbf0634fcc2996a5" Handle type-lets better Core allows non-recursive type-lets, thus let a = TYPE ty in ... They are substituted away very quickly, but it's convenient for some passes to produce them (rather than to have to substitute immediately). Trac #13708 tried the effect of not running the simplifer at all (a rather bizarre thing to do, but still). That showed that some passes crashed because they always treated a let-bounder binder as an Id. This patch adds some easy fixes. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 12:50:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 12:50:37 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.c5d5873d7bbcd99163dafc85631e4227@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_runt/T13623 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, it's hard for GHC to predict what "sufficient specialisation" is, and its heuristics are a bit ad hoc. Improvements there would be welcome. I'm not quite sure what changed since 8.0, but it's a squishy area so I'm not surprised that something has. Seeing where and why GHC 8.2 stopped sort of doing the full job, and what heuristic might help it continue, would be a useful piece of work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 12:51:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 12:51:18 -0000 Subject: [GHC] #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 In-Reply-To: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> References: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> Message-ID: <059.80fa7bc428ae30e877f599b2647f9bc5@haskell.org> #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T13708 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => simplCore/should_compile/T13708 * resolution: => fixed Comment: Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 13:12:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 13:12:14 -0000 Subject: [GHC] #13711: uname: illegal option -- o when running make clean in nofib In-Reply-To: <049.88cdc224335cf1541b7c50c6988ce9ec@haskell.org> References: <049.88cdc224335cf1541b7c50c6988ce9ec@haskell.org> Message-ID: <064.d7663ca7dfc54ec8ab73f09818bf5b51@haskell.org> #13711: uname: illegal option -- o when running make clean in nofib -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.0.1 suite | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * os: Unknown/Multiple => MacOS X Comment: Hmm, indeed the only `uname` options defined by the POSIX specification are `mnrsva`. There are two mentions of `uname -o` in `nofib`, {{{ mk/boilerplate.mk:ifeq ($(shell uname -o), Msys) runstdtest/runstdtest.prl:if ( `uname -o | grep Msys` ) { }}} I suppose we should replace these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 13:19:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 13:19:20 -0000 Subject: [GHC] #7395: DefaultSignatures conflict with default implementations In-Reply-To: <046.54ca5ac835e551d0591e9f443e8deba3@haskell.org> References: <046.54ca5ac835e551d0591e9f443e8deba3@haskell.org> Message-ID: <061.263c7581e956f44184921522e1a83571@haskell.org> #7395: DefaultSignatures conflict with default implementations -------------------------------------+------------------------------------- Reporter: cgaebel | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: | DefaultSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 7346 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aspiwack): I found myself, today, in a situation where I wanted to have two default signatures, something like: {{{#!haskell {-# LANGUAGE DefaultSignatures #-} module Test where class Foo a where foo :: a default foo :: (a~Int) => a foo = 0 default foo :: (a~Bool) => a foo = False }}} The practical situation was that the second default implementation requires an extra `MonadIO m` constraint and is more efficient. My proposal is to resolve default implementation like overlapping instances: the default with the most specific type amongst the well-typed ones is used. The compiler can check, when creating the class that default implementations of a same method either don't unify or are strictly ordered with the specialisation order. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 13:37:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 13:37:53 -0000 Subject: [GHC] #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 In-Reply-To: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> References: <044.2693b478252b11f06ab341e229ae44a3@haskell.org> Message-ID: <059.6676013094745ee5f8e38e538c14ea0e@haskell.org> #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T13708 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge * milestone: => 8.2.1 @@ -2,1 +2,1 @@ - {{{ + {{{#!hs New description: The following causes a panic in GHC 8.2.1 rc2: {{{#!hs module Main where indexOr :: a -> Int -> [a] -> a indexOr fallback idx xs = if (idx < length xs) then xs !! idx else fallback main :: IO () main = undefined }}} When compiling I get: {{{ [1 of 1] Compiling Main ( src/Examples/table-sort.hs, .stack-work/dist/x86_64-linux/Cabal-2.0.0.0/build/fltkhs-table-sort /fltkhs-table-sort-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-unknown-linux): idInfo a_a2ws Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Comment: I suspect we should merge this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 13:47:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 13:47:27 -0000 Subject: [GHC] #11439: Request for comments: Allow duplicate type signatures In-Reply-To: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> References: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> Message-ID: <066.206266db0f68ef777a53f5e7e222a26c@haskell.org> #11439: Request for comments: Allow duplicate type signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Collect uses in [https://gist.github.com/Icelandjack/f5247a4d7d29e76a364f2073efe9928c gist]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 13:55:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 13:55:41 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.062ef814b5d0ef8438717790342c2116@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => hs-boot -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 13:57:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 13:57:31 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.a247a9e721b1cd4256ed570350033f22@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): This bug is kind of similar to #12063, in that the panic is induced when we attempt to use interfaces prior to having checked that everything is squared away. The interface usage is probably related to parallel mode. I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 14:02:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 14:02:35 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.622bdb04a1c74d624722e6efbd5ab806@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): It might be slightly different from the bug you mentioned - it was minimized from code that compiles fine with 8.0 and panics with r 2, but before minimization it wanted like a half of hackage to compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 14:18:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 14:18:50 -0000 Subject: [GHC] #7395: DefaultSignatures conflict with default implementations In-Reply-To: <046.54ca5ac835e551d0591e9f443e8deba3@haskell.org> References: <046.54ca5ac835e551d0591e9f443e8deba3@haskell.org> Message-ID: <061.0bf8c41dafff544a3898c9a6b2198a56@haskell.org> #7395: DefaultSignatures conflict with default implementations -------------------------------------+------------------------------------- Reporter: cgaebel | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: | DefaultSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 7346 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:19 aspiwack]: > I found myself, today, in a situation where I wanted to have two default signatures, something like: You might be interested in [https://gist.github.com/Icelandjack/e1ddefb0d5a79617a81ee98c49fbbdc4 an idea] I'm developing, {{{#!hs newtype WrapInt = WrapInt Int newtype WrapBool = WrapBool Bool instance Foo WrapInt where foo :: WrapInt foo = WrapInt 0 instance Foo WrapBool where foo :: WrapBool foo = WrapBool False }}} and you should be able to derive {{{#!hs newtype I = MkI Int deriving as WrapInt (Foo) newtype B = MkB Bool deriving as WrapBool (Foo) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 15:05:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 15:05:10 -0000 Subject: [GHC] #13711: uname: illegal option -- o when running make clean in nofib In-Reply-To: <049.88cdc224335cf1541b7c50c6988ce9ec@haskell.org> References: <049.88cdc224335cf1541b7c50c6988ce9ec@haskell.org> Message-ID: <064.6906358942101c3bfd42318bac80b972@haskell.org> #13711: uname: illegal option -- o when running make clean in nofib -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.0.1 suite | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3594 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3594 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 15:48:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 15:48:46 -0000 Subject: [GHC] #13712: Attach size to ForeignPtr Message-ID: <046.23d4c0b80844f5be3e781f289fa29c54@haskell.org> #13712: Attach size to ForeignPtr -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In some types of programs the dominant memory consumer is foreign objects whose lifetime is controlled by `ForeignPtr`s. In these cases the heuristics used by the GC don't reflect the true heap size of the process, meaning that garbage collection doesn't happen as often as it should. One suggested approach to alleviating this is to allow users to tell the GC about the size of the object represented by a `ForeignPtr`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 19:45:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 19:45:03 -0000 Subject: [GHC] #13713: fdefer-type-errors makes missing import errors disappear Message-ID: <042.0ad32ccb64ceb3f2b98fb4c703f0e392@haskell.org> #13713: fdefer-type-errors makes missing import errors disappear -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12529 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have this code {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} import Data.Type.Equality ((:~:)(Refl)) import GHC.TypeLits import qualified Numeric.LinearAlgebra as LA import Numeric.LinearAlgebra.Static toVec :: forall n . (KnownNat n) => LA.Vector Double -> R n toVec vec = withVector vec $ \(v :: R n2) -> case sameNat (Proxy @n) (Proxy @n2) of Just Refl -> v Nothing -> error "wrong dimensions" }}} Notably I forgot to import `Proxy`. Without `-fdefer-type-errors` I get this error: {{{ ➤ nix-shell -p "haskellPackages.ghcWithPackages (pkgs:[pkgs.hmatrix])" --pure --run 'ghci ghc-8.0.2-proxy-confusing-error.hs' GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ghc-8.0.2-proxy-confusing-error.hs, interpreted ) ghc-8.0.2-proxy-confusing-error.hs:12:60: error: Data constructor not in scope: Proxy ghc-8.0.2-proxy-confusing-error.hs:12:60: error: * Cannot apply expression of type `t1' to a visible type argument `n' * In the first argument of `sameNat', namely `(Proxy @n)' In the expression: sameNat (Proxy @n) (Proxy @n2) In the expression: case sameNat (Proxy @n) (Proxy @n2) of { Just Refl -> v Nothing -> error "wrong dimensions" } Failed, modules loaded: none. }}} but with `-fdefer-type-errors` the `Data constructor not in scope: Proxy` is gone! {{{ ➤ nix-shell -p "haskellPackages.ghcWithPackages (pkgs:[pkgs.hmatrix])" --pure --run 'ghci ghc-8.0.2-proxy-confusing-error.hs -fdefer-type-errors' GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ghc-8.0.2-proxy-confusing-error.hs, interpreted ) ghc-8.0.2-proxy-confusing-error.hs:12:60: error: * Cannot apply expression of type `t1' to a visible type argument `n' * In the first argument of `sameNat', namely `(Proxy @n)' In the expression: sameNat (Proxy @n) (Proxy @n2) In the expression: case sameNat (Proxy @n) (Proxy @n2) of { Just Refl -> v Nothing -> error "wrong dimensions" } Failed, modules loaded: none. }}} This is probably related to #12529. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 20:31:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 20:31:53 -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.de0ec04879fa9bbdc9f2c1450e2038de@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Comment (by jberryman): In case it's interesting or helpful, this same issue appears to have surfaced independently here: https://www.reddit.com/r/haskell/comments/6bojlj/inlineing_a_case_study/ (see my comment at bottom of thread). It also might be interesting to look at the conclusions being drawn and questions being raised in the original blog post and in that discussion thread. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 20:34:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 20:34:27 -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.b0602bbce6de552bd616f36839a6dc44@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Comment (by jberryman): I forgot to add: I haven't checked out a build with the fix here to see if it fixes this other performance issue, but their test case seems to be very similar to mine and I assume suffering from the same issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 21:00:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 21:00:14 -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.39cb6a189a8b1f76d442e33c623c3fde@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Comment (by simonpj): As far as I can see it's not the same issue as this ticket. In the blog post, as I read it, there is a function that * Is fairly small in source code terms * Calls several moderately large combinators * But finally optimises to something small again This function is called quite a bit, so the cost of optimising it is paid many times, rather than once for all at the defintion site. Nothing exponential happens. Thus motivated the author asks for a pragma to say "please inline the optimised code for this function". Maybe. The gain would be in compliation time, not in the quality of the resulting code. Is that worth another pragma. Maybe, but it does not seem compelling to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 21:01:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 21:01:04 -0000 Subject: [GHC] #12001: RFC: Add pattern synonyms to base In-Reply-To: <051.a75667959d8601b2c7daa93e0c0a6683@haskell.org> References: <051.a75667959d8601b2c7daa93e0c0a6683@haskell.org> Message-ID: <066.9dad0db2a4f439e41862ab16d4471117@haskell.org> #12001: RFC: Add pattern synonyms to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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 Iceland_jack): Examples added to [https://gist.github.com/Icelandjack/dc50599550545cb53857bcb6622cf270 gist]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 21:18:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 21:18: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.aad585b4755f32ba117f3589bf6bb083@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): I left your xmobar configuration (build with `-O1` from git) running under gdb for around 24 hours and I never observed a crash. Perhaps you could cite the dependency versions you are using? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 21:19:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 21:19:55 -0000 Subject: [GHC] #13714: Guard pages instead of Heap/Stack limit checks in Cmm Message-ID: <045.8c6aabf7bd6cb60a81106c518b7a03d1@haskell.org> #13714: Guard pages instead of Heap/Stack limit checks in Cmm -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Recently I have debugged a small program and I saw that there are a lot of Heap/Stack limit checks on function entrances ([https://ghc.haskell.org/trac/ghc/browser/ghc/rts/HeapStackCheck.cmm]). This is not cheap and introduce more branch mispredictions and instructions. What you think if we use guard OS pages (that trigger exceptions when someone try to read/write on them) around Stack and Heap? Stack and Heap sizes should be aligned on page size (usually 4K) and with sizes that fits 4K pages. We could handle such exceptions so we could do GC if needed. This trick is usually found in some memory managers for finding out-of- bounds bugs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 21:48:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 21:48:53 -0000 Subject: [GHC] #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted Message-ID: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: simplifier | Operating System: Unknown/Multiple ticks | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: dynamic-paper | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- on ghc 8.2.1-rc2 on a mac running the latest Xcode and os {{{ make TEST=dynamic-paper WAY=profasm fails with ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone delta ... Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad it also fails with 1000 ticks make TEST=dynamic-paper WAY=profasm EXTRA_HC_OPTS='-fsimpl-tick- factor=1000' so there may be an infinite loop -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 22:02:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 22:02:24 -0000 Subject: [GHC] #13713: fdefer-type-errors makes missing import errors disappear In-Reply-To: <042.0ad32ccb64ceb3f2b98fb4c703f0e392@haskell.org> References: <042.0ad32ccb64ceb3f2b98fb4c703f0e392@haskell.org> Message-ID: <057.f8c7d5a588bc2e2ac961f1350920c139@haskell.org> #13713: fdefer-type-errors makes missing import errors disappear -------------------------------------+------------------------------------- Reporter: nh2 | 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: #12529 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Simpler example {{{ {-# LANGUAGE TypeApplications #-} module T13713 where toVec = withVector (Proxy @Int) }}} The trouble is this: * The out-of-scope variables become deferred errors, which are reported as warnings * The "Cannot apply..." error is an error that we can't defer, so it stays as an error * When we have errors and warnings we report only the errors. So the out of scope variables are suppressed when (and only when) they are turned into warnings by `-fdefer-type-errors`. I'm not quite sure what to do here. I suppose the errors-that-become- warnings (via the defer mechanism) could somehow be made immune to suppression by errors that don't become warnings. That seems like the most plausible path to me, but someone would need to do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 22:12:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 22:12:34 -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.763e23e9055617c78afb4f1bd42907bf@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Comment (by jberryman): My thought was that the issue (long compilation times) was not actually primarily due to the linear extra simplifying of each unoptimized callsite, but rather the bug here. At least this seems consistent with the test case phadej posted to me (runtime quadratic in occrrences of "char7 <>"). I don't have any other context for the issue though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 22:46:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 22:46:31 -0000 Subject: [GHC] #13716: Move CI to Jenkins Message-ID: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> #13716: Move CI to Jenkins -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently we use Harbormaster to build Differentials and commits. While this works, it leaves much to be desired, * job scheduling is (literally) random: this means that some patch authors end up waiting literally ways for their patches to be built * there is little support for automatic provisioning of builders: this means we can't scale to meet demand and make poor use of our computational resources * periodic builds (e.g. nightlies) are not supported. Ideally we would not only provide * it doesn't have a sensible interface for integration with external tools: this means that efforts like CI-before-merge have been pushed off * status reporting is poor: even answering the question of what a given builder is currently working on is surprisingly difficult * maintenance is a byzantine: Adding a new builder requires adding at least six different objects (a Harbormaster Build Plan, a Drydock Working Copy, a Drydock Blueprint, an Almanac Service, an Almanac Device, and an Almanac Binding) in various Phabricator applications. None of this configuration can be tracked under version control nor can most of it be cloned from an existing builder's configuration. * Design assumptions don't match GHC's constraints: Harbormaster was designed under the assumption that builds are cheap and computation plentiful. The maintainers have stated that they have little interest in supporting environments where this doesn't hold. Jenkins, while far from perfect, seems a bit better suited to our needs, more mature, and far more flexible. This ticket will serve as the checklist for our move to Jenkins. In the end we want, * Builders (static or dynamically-provisioned, as appropriate) for * x86-64, i386 Linux * x86-64, i386 Windows * x86-64 Darwin * x86-64 OpenBSD * Cross compile from x86-64 to ARM * Native ARM * Differential builds with sensible scheduling (e.g. first build on 64-bit Linux where machines are cheap, then build on the others) * Per-commit builds on all * Nightly builds on all, including * Collection of binary distribution for user download * Update of `master` documentation mirror on downloads.haskell.org * Slow validation (including tests requiring Hackage packages) * nofib run on some platforms? * Test-before-merge-to-master -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 22:56:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 22:56:16 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.dfa7f0f3513db75e27e6ad6dbd4274aa@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): In original code there's no effect from -j1 - it still panics. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 23:21:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 23:21:53 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.9af0f9d27d6b3e163ed2bae1aa03c71d@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): `text` is used nearly everywhere at this point; the fact that it gets this wrong is a rather scary revelation; we really need to make this expectation better known. However, I am a bit worried that the inability to pass `ByteArray#`s to foreign calls may put us in a bit of a pickle performance-wise. For instance, currently `text` uses a C helper, `hs_text_decode_utf8`, to implement equality on `Text` (see `Data.Text.Array.equal`). Not only would it be harder to write the equivalent C-- implementation, but you would also be limited to the optimisation capabilities of the GHC backend, which might hurt for a tight loop such as this. What is the rationale for allowing GHC to implement `unsafe` calls as a `safe` call? It seems like this puts library authors is a tough spot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 23:25:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 23:25:27 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.38a44e8c67e2f9fdde40cfa4ade03d73@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): So, I think this particular repro case may have been minimized too much. It's known that we have some bugs handling hs-boot typechecking when the typechecking would ultimately fail (as it would in this example, since the implementer doesn't implement enough), but if the original test case was code that "should" compile, then it would be better if we had a test case which similarly should compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 17 23:33:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 May 2017 23:33:29 -0000 Subject: [GHC] #13390: String literal float-out during desugaring regresses T1969 at -O0 (was: Strict literal float-out during desugaring regresses T1969 at -O0) In-Reply-To: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> References: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> Message-ID: <061.ee543a37f4096977e23c820019e2b89b@haskell.org> #13390: String literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 02:16:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 02:16:45 -0000 Subject: [GHC] #13713: fdefer-type-errors makes missing import errors disappear In-Reply-To: <042.0ad32ccb64ceb3f2b98fb4c703f0e392@haskell.org> References: <042.0ad32ccb64ceb3f2b98fb4c703f0e392@haskell.org> Message-ID: <057.734c3c6ae92b67d4701d18e7f8c85b53@haskell.org> #13713: fdefer-type-errors makes missing import errors disappear -------------------------------------+------------------------------------- Reporter: nh2 | 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: #12529 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I seem to recall a conversation about not suppressing warnings when there are errors. I don't know where this was, however. gcc reports warnings alongside errors, for example, and I'd personally prefer to get all diagnostics instead of waiting only until I've fixed all the errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 04:54:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 04:54:03 -0000 Subject: [GHC] #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase Message-ID: <045.5d7e7d9a3f395b637d10b22da7ba85f9@haskell.org> #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, | PatternMatchWarnings | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In #8779, mpickering added a `COMPLETE` pragma to allow exhaustiveness checking for matches involving pattern synonyms. Unfortunately, there is still one piece missing: the interaction with `EmptyCase`. Suppose I write {{{#!hs newtype Fin (n :: Nat) = Fin Natural -- constructor not exported pattern FZ :: () => forall m. n ~ 'S m => Fin n pattern FS :: () => n ~ 'S m => Fin m -> Fin n {-# COMPLETE FZ, FS #-} }}} I would very much like to be able to write {{{#!hs finZAbsurd :: Fin 'Z -> Void finZAbsurd x = case x of }}} but this gives me a pattern coverage warning! That's certainly not what we want. I believe what we actually want is this: When checking empty case, check that ''at least one'' complete pattern set is impossible. In this case, it would see two complete pattern sets: the built-in `{Fin}` and the user-decreed `{FZ, FS}`. Since neither `FZ` nor `FS` have matching types, we should conclude that the empty case is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 05:01:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 05:01:18 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.4168a95a8fe5f4acaeb45aab5666cb4f@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): Panic in rc2, successfull compilation in 8.0 and 7.10 {{{ % cat A.hs {-# LANGUAGE RecordWildCards #-} module A where import B type E = () yay :: Maybe () yay = do H{..} <- undefined undefined }}} {{{ % cat A.hs-boot module A ( E ) where type E = () }}} {{{ % cat B.hs module B where import {-# SOURCE #-} A data F a = F a type G = F (Maybe E) data H = H { h :: {-# UNPACK #-} !G } }}} rc2, -j1 {{{ % rm *.hi* *.o* ; ghc -j1 -O2 A.hs [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling A ( A.hs, A.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170503 for x86_64-unknown-linux): tcIfaceGlobal (local): not found You are in a maze of twisty little passages, all alike. While forcing the thunk for TyThing E which was lazily initialized by initIfaceCheck typecheckLoop, I tried to tie the knot, but I couldn't find E in the current type environment. If you are developing GHC, please read Note [Tying the knot] and Note [Type-checking inside the knot]. Consider rebuilding GHC with profiling for a better stack trace. Contents of current type environment: [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/iface/TcIface.hs:1689:23 in ghc:TcIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} rc2, -j2 - note - error message is slightly different + it's in color {{{ % rm *.hi* *.o* ; ghc -j2 -O2 A.hs [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling A ( A.hs, A.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170503 for x86_64-unknown-linux): tcIfaceGlobal (local): not found You are in a maze of twisty little passages, all alike. While forcing the thunk for TyThing E which was lazily initialized by initIfaceCheck typecheckLoop, I tried to tie the knot, but I couldn't find E in the current type environment. If you are developing GHC, please read Note [Tying the knot] and Note [Type-checking inside the knot]. Consider rebuilding GHC with profiling for a better stack trace. Contents of current type environment: [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/iface/TcIface.hs:1689:23 in ghc:TcIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} ghc 8.0: {{{ % rm *.hi* *.o* ; ghc -j1 -O2 A.hs [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling A ( A.hs, A.o ) }}} {{{ % rm *.hi* *.o* ; ghc -j2 -O2 A.hs [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling A ( A.hs, A.o ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 05:01:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 05:01:40 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.0de2c90d97724ca16af07092f005ca18@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 trippels): {{{ markus at x4 xmobar % cabal install --flags="with_xft with_utf8" --dry-run --allow-newer Resolving dependencies... In order, the following would be installed (use -v for more details): data-default-class-0.1.2.0 data-default-instances-containers-0.0.1 dlist-0.8.0.2 data-default-instances-dlist-0.0.1 mtl-2.2.1 network-2.6.3.1 old-locale-1.0.0.7 data-default-instances-old-locale-0.0.1 data-default-0.7.1.1 X11-1.8 regex-base-0.93.2 regex-posix-0.95.2 regex-compat-0.95.1 stm-2.4.4.1 text-1.2.2.1 parsec-3.1.11 network-uri-2.6.1.0 HTTP-4000.3.6 utf8-string-1.0.1.1 X11-xft-0.3.1 xmobar-0.24.4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 05:48:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 05:48:22 -0000 Subject: [GHC] #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase In-Reply-To: <045.5d7e7d9a3f395b637d10b22da7ba85f9@haskell.org> References: <045.5d7e7d9a3f395b637d10b22da7ba85f9@haskell.org> Message-ID: <060.21746425f9e0e95647431e0ce8d11405@haskell.org> #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: @@ -8,1 +8,1 @@ - pattern FZ :: () => forall m. n ~ 'S m => Fin n + pattern FZ :: () => n ~ 'S m => Fin n New description: In #8779, mpickering added a `COMPLETE` pragma to allow exhaustiveness checking for matches involving pattern synonyms. Unfortunately, there is still one piece missing: the interaction with `EmptyCase`. Suppose I write {{{#!hs newtype Fin (n :: Nat) = Fin Natural -- constructor not exported pattern FZ :: () => n ~ 'S m => Fin n pattern FS :: () => n ~ 'S m => Fin m -> Fin n {-# COMPLETE FZ, FS #-} }}} I would very much like to be able to write {{{#!hs finZAbsurd :: Fin 'Z -> Void finZAbsurd x = case x of }}} but this gives me a pattern coverage warning! That's certainly not what we want. I believe what we actually want is this: When checking empty case, check that ''at least one'' complete pattern set is impossible. In this case, it would see two complete pattern sets: the built-in `{Fin}` and the user-decreed `{FZ, FS}`. Since neither `FZ` nor `FS` have matching types, we should conclude that the empty case is fine. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 07:32:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 07:32:23 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.b13ba651e2c9c7c9a3f48d89170df47a@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): @bgamari I understand the concerns and I agree. To answer your question about the rationale, the idea is that "safe" is the default and "unsafe" relaxes the compiler's obligations only. It doesn't add new obligations (such as the requirement not to interrupt the call with a GC). Implementing that obligation in GHCi might be possible, but we haven't done it. One way around this would be to add a new annotation to foreign calls that requires the call not to be interrupted by GC, e.g. `foreign import unsafenogc ...` or something. This would not be implemented by GHCi (yet?) so compilation would fail if you tried to load text into GHCi. Incidentally it's a bad idea to make one of these calls that might run for an arbitrarily long time, because if a GC strikes everything is blocked until the call returns. This has been a rich source of performance bugs in our system at Facebook. I don't think we've encountered problems with text, but we've had to fix other libraries (e.g. regex-pcre) to turn unsafe calls into safe calls. It's possible that the unsafe calls in Text would cause problems when working with very long strings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 07:46:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 07:46:39 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.e78f46f09ff2d0ffc1b0c8934b99077d@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I see that the docmentation on `foreign import unsafe` is thin in the extreme. The [http://downloads.haskell.org/~ghc/master/users-guide/ffi- chap.html user manual section] does not mention `unsafe`; while the [https://www.haskell.org/onlinereport/haskell2010/haskellch8.html#x15-1490008 relevant section of the Haskell 2010 report] has only a single cryptic sentence about "call backs into the Haskell system". It would be good to document it better, perhaps in the user manual. A good example is this thread: can you pass an unpinned bytearry to a foreign call? I don't think we have a shred of documentation about this. At one point we thought of unsafe foreign calls as a "fat machine instruction". GHC's obligations are simpler because GC cannot be invoked by the call, or thread-switching. Nor, I think, should it block (because then GC might happen while it was blocked). So it could be used for things like `cosine` that might be implemented out of line, but morally are like a machine instruction. I think Simon's `unsafenogc` gets closer to the "fat machine instruction" idea. It really must be used only for short-running calls. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 07:47:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 07:47:57 -0000 Subject: [GHC] #13713: fdefer-type-errors makes missing import errors disappear In-Reply-To: <042.0ad32ccb64ceb3f2b98fb4c703f0e392@haskell.org> References: <042.0ad32ccb64ceb3f2b98fb4c703f0e392@haskell.org> Message-ID: <057.713f30a444a6171006ac562fc8cae650@haskell.org> #13713: fdefer-type-errors makes missing import errors disappear -------------------------------------+------------------------------------- Reporter: nh2 | 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: #12529 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, it'd also be possible just to stop suppressing warnings when there are errors. What do people think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 09:02:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 09:02:17 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.601f17a440a98472cb4bb0739b097be0@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): This is a very important technique to write high performance array code(we can't put everything related to ByteArray into ghc-prim after all). I'd like to get it fixed in GHCi and document it(include caveats) . what is stopping GHCi supporting unsafe FFI calls? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 09:04:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 09:04:18 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.e625a519acd94d6c36cea02ec0231964@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): This is a very important technique to write high performance array code(we can't put everything related to ByteArray into ghc-prim after all). I'd like to get it fixed in GHCi and document it(include caveats) . what is stopping GHCi supporting unsafe FFI calls? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 09:06:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 09:06:20 -0000 Subject: [GHC] #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase In-Reply-To: <045.5d7e7d9a3f395b637d10b22da7ba85f9@haskell.org> References: <045.5d7e7d9a3f395b637d10b22da7ba85f9@haskell.org> Message-ID: <060.362f581475101a792b976544b0ade807@haskell.org> #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 10:06:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 10:06:10 -0000 Subject: [GHC] #13713: fdefer-type-errors makes missing import errors disappear In-Reply-To: <042.0ad32ccb64ceb3f2b98fb4c703f0e392@haskell.org> References: <042.0ad32ccb64ceb3f2b98fb4c703f0e392@haskell.org> Message-ID: <057.d5f70fea09b13adfaafe070172e122b7@haskell.org> #13713: fdefer-type-errors makes missing import errors disappear -------------------------------------+------------------------------------- Reporter: nh2 | 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: #12529 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): It would seem logical that all the errors are reported if the flag {{{fdefer-type-errors}}} is active and the errors must be mentioned before the warning because they are superior to them without the flag or with the flag.\\ 1 - Show all errors , and after correction\\ 2 - Show warnings If an error can not be deffered, it must be reported first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 10:46:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 10:46:22 -0000 Subject: [GHC] #13718: diagnostic colors: differentiate between message head and message body Message-ID: <044.d0c2ce3e08b76e30b998d2f85762a984@haskell.org> #13718: diagnostic colors: differentiate between message head and message body -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13444 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When a diagnostic message is printed, currently the whole message is colored by the "message" color (bold by default). I'd find it useful if the message body and the header could be differentiated (I do like the idea that the header stands out). Motivation: Consider the following error message, {{{ GHCi, version 8.2.0.20170508: http://www.haskell.org/ghc/ :? for help Prelude> () () :1:1: error: • Couldn't match expected type ‘() -> t’ with actual type ‘()’ • The function ‘()’ is applied to one argument, but its type ‘()’ has none In the expression: () () In an equation for ‘it’: it = () () • Relevant bindings include it :: t (bound at :1:1) }}} which by default is all bold, with the {{{error:}}} part in red. I want the message body to use normal text. Thanks to #13444 I can achieve that by setting {{{GHC_COLORS="message=0"}}}. However, that setting also affects the initial {{{:1:1}}} part of the headline, which now looks odd because normal and bold text are mixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 11:57:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 11:57:17 -0000 Subject: [GHC] #13666: The gcc wrapper can't handle trailing backslashes In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <061.6f040f207f5428635f6a037570bf9fe5@haskell.org> #13666: The gcc wrapper can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Driver | 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): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): Unless I'm misunderstanding, is it not sufficient to add `|| *src == '\\'` to line 62? https://github.com/ghc/ghc/blob/master/driver/utils/cwrapper.c#L62, that would be logically more consistent because it means you're adding a character to the list of characters that need escaping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 12:01:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 12:01:08 -0000 Subject: [GHC] #13666: The gcc wrapper can't handle trailing backslashes In-Reply-To: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> References: <046.48bb815bdf014d4f8613c4501cc5c3f5@haskell.org> Message-ID: <061.9dd26ec7e446f06357e5598a1acf5e43@haskell.org> #13666: The gcc wrapper can't handle trailing backslashes ---------------------------------+---------------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Driver | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13709 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * related: => #13709 Comment: Also I'm dropping the driver all together (see #13709), but this change would still be useful as this file is used for other things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 12:04:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 12:04:46 -0000 Subject: [GHC] #13719: checkFamInstConsistency dominates compile time Message-ID: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> #13719: checkFamInstConsistency dominates compile time -------------------------------------+------------------------------------- Reporter: niteria | 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: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #13092, #13099, | #12191 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm looking into compile time issues on our internal code base. `checkFamInstConsistency` takes 50% of all compile time for `:load` in `ghci` for us. I've created a synthetic test case that approximates the issue and in which compiling 300 modules with one small data type each takes 65s total, and `checkFamInstConsistency` is 87% of that and 94.1% of allocations. `checkFamInstConsistency` is run to ensure consistency of a type family associated with Generics, but that's only semi-relevant. To reproduce: {{{ ./gen.sh ./inplace/bin/ghc-stage2 -keep-tmp-files DummyLevel3M100.hs }}} Profile with some relevant cost centres: https://phabricator.haskell.org/P150 The next step is to look into implementing: https://ghc.haskell.org/trac/ghc/ticket/13092#comment:14 I also plan to add this test case to the codebase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 12:13:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 12:13:16 -0000 Subject: [GHC] #13719: checkFamInstConsistency dominates compile time In-Reply-To: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> References: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> Message-ID: <061.c3481a16569c67a46b1d3ab23baef92d@haskell.org> #13719: checkFamInstConsistency dominates compile time -------------------------------------+------------------------------------- Reporter: niteria | 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: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13092, #13099, | Differential Rev(s): #12191 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * Attachment "gen.sh" added. gen.sh -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 13:26:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 13:26:58 -0000 Subject: [GHC] #13720: INLINE pragma semantics changed since 8.0.2 Message-ID: <049.7908e52fa1c75d7628d10b8b19ba0d16@haskell.org> #13720: INLINE pragma semantics changed since 8.0.2 -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It now seems that unfoldings for INLINE things are optimised slightly. This causes different interactions with `RULES` than before. {{{#!hs module A where {-# INLINE f #-} f x = h x h x = x {-# RULES "h x" forall x . h x = error "REWRITE" #-} }}} {{{#!hs module B where import A qux = f 5 }}} Then running {{{ > ghc-8.0.2 B.hs -O2 -fforce-recomp -ddump-simpl | grep qux -A5 qux :: Integer [GblId, Str=DmdType x] qux = error .... }}} {{{ > ghc-8.2.0.20170507 B.hs -O2 -fforce-recomp -ddump-simpl | grep qux -A5 qux :: Integer [GblId, Caf=NoCafRefs, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 100 0}] qux = 5 }}} Inspecting the unfoldings, we see that 8.2 optimises the unfoldings to inline `h` before the rule can apply. {{{ d61439f58ce9c5a268304423a43b9b44 f :: p -> p {- Arity: 1, HasNoCafRefs, Strictness: , Inline: (sat-args=1), Unfolding: InlineRule (1, False, True) (\ @ p (x :: p) -> x) -} }}} Is this new behaviour intentional? It seems possible that it will break some programs which use rewrite rules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 14:50:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 14:50:44 -0000 Subject: [GHC] #13714: Guard pages instead of Heap/Stack limit checks in Cmm In-Reply-To: <045.8c6aabf7bd6cb60a81106c518b7a03d1@haskell.org> References: <045.8c6aabf7bd6cb60a81106c518b7a03d1@haskell.org> Message-ID: <060.0a85f9e90f3764c745d6ea8d2d9cb056@haskell.org> #13714: Guard pages instead of Heap/Stack limit checks in Cmm -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8703 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => duplicate * related: => #8703 Comment: This is a duplicate of #8703. I am curious as to whether this would be easier under Linux now that we pre-allocate a contiguous heap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 15:36:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 15:36:34 -0000 Subject: [GHC] #13714: Guard pages instead of Heap/Stack limit checks in Cmm In-Reply-To: <045.8c6aabf7bd6cb60a81106c518b7a03d1@haskell.org> References: <045.8c6aabf7bd6cb60a81106c518b7a03d1@haskell.org> Message-ID: <060.a0e58e6c9cd246dbb978c844f5e76008@haskell.org> #13714: Guard pages instead of Heap/Stack limit checks in Cmm -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8703 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): I'll write to other issue. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 15:38:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 15:38:09 -0000 Subject: [GHC] #13650: Implement KPush in types In-Reply-To: <047.e26721ad30e2e3d90c01c9e924788439@haskell.org> References: <047.e26721ad30e2e3d90c01c9e924788439@haskell.org> Message-ID: <062.587bccda34db17ae2619c0c173b0538e@haskell.org> #13650: Implement KPush in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): One wrinkle (at least until #11715 is fixed): which `eqType` do we wish to respect here? `eqType` or `tcEqType`? I think it might be best to wait until after #11715. Or it's possible that it doesn't matter which `eqType` we're thinking of. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 15:38:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 15:38:16 -0000 Subject: [GHC] #13714: Guard pages instead of Heap/Stack limit checks in Cmm In-Reply-To: <045.8c6aabf7bd6cb60a81106c518b7a03d1@haskell.org> References: <045.8c6aabf7bd6cb60a81106c518b7a03d1@haskell.org> Message-ID: <060.6f235bf2412bf22fe8deb58d3fd306bf@haskell.org> #13714: Guard pages instead of Heap/Stack limit checks in Cmm -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8703 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): We could just try first to realloc to extend memory blocks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 15:54:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 15:54:40 -0000 Subject: [GHC] #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase In-Reply-To: <045.5d7e7d9a3f395b637d10b22da7ba85f9@haskell.org> References: <045.5d7e7d9a3f395b637d10b22da7ba85f9@haskell.org> Message-ID: <060.f6613ad4c60365214ec9886c5a8ac1bc@haskell.org> #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I tried to reproduce this error, but I couldn't. I don't know what implementations for `FZ` and `FS` you had in mind, so I tried whipping up my own example from scratch: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# OPTIONS_GHC -Wall #-} module T (T(TInt, TBool), tCharAbsurd1) where import Data.Void data T a where MkTInt :: T Int MkTBool :: T Bool pattern TInt :: () => n ~ Int => T n pattern TInt = MkTInt pattern TBool :: () => n ~ Bool => T n pattern TBool = MkTBool {-# COMPLETE TInt, TBool #-} tCharAbsurd1 :: T Char -> Void tCharAbsurd1 x = case x of {} }}} This, however, compiles without any warnings. I even tried using `T` in another module: {{{#!hs {-# LANGUAGE EmptyCase #-} {-# OPTIONS_GHC -Wall #-} module Bug where import Data.Void import T tCharAbsurd2 :: T Char -> Void tCharAbsurd2 x = case x of {} }}} This too compiles without warning: {{{ $ ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 2] Compiling T ( T.hs, interpreted ) [2 of 2] Compiling Bug ( Bug.hs, interpreted ) Ok, modules loaded: Bug, T. }}} How did you get this supposed pattern coverage warning? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 15:59:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 15:59:51 -0000 Subject: [GHC] #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase In-Reply-To: <045.5d7e7d9a3f395b637d10b22da7ba85f9@haskell.org> References: <045.5d7e7d9a3f395b637d10b22da7ba85f9@haskell.org> Message-ID: <060.b9860213a053e364e955aee6c80a570c@haskell.org> #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Here's a full reproduction: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ViewPatterns #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE Trustworthy #-} module Fin (Nat (..), Fin (FZ, FS), FinView (..), viewFin) where import Numeric.Natural import Unsafe.Coerce data Nat = Z | S Nat -- Fin *must* be exported abstractly (or placed in an Unsafe -- module) to maintain type safety. newtype Fin (n :: Nat) = Fin Natural deriving instance Show (Fin n) data FinView n where VZ :: FinView ('S n) VS :: !(Fin n) -> FinView ('S n) viewFin :: Fin n -> FinView n viewFin (Fin 0) = unsafeCoerce VZ viewFin (Fin n) = unsafeCoerce (VS (Fin (n - 1))) pattern FZ :: () => n ~ 'S m => Fin n pattern FZ <- (viewFin -> VZ) where FZ = Fin 0 pattern FS :: () => n ~ 'S m => Fin m -> Fin n pattern FS m <- (viewFin -> VS m) where FS (Fin m) = Fin (1 + m) {-# COMPLETE FZ, FS #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 16:03:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 16:03:53 -0000 Subject: [GHC] #13718: diagnostic colors: differentiate between message head and message body In-Reply-To: <044.d0c2ce3e08b76e30b998d2f85762a984@haskell.org> References: <044.d0c2ce3e08b76e30b998d2f85762a984@haskell.org> Message-ID: <059.88b8438bbb6e5d6989dbd869411a994f@haskell.org> #13718: diagnostic colors: differentiate between message head and message body -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: Rufflewind (added) Comment: Since I had trouble visualizing this, let me try to format what you're seeing. With the default `GHC_COLORS`, this is what you see: {{{ #!html
 Prelude> () ()

 <interactive>:1:1: error:
     • Couldn't match expected type ‘() -> t’ with actual type ‘()’
     • The function ‘()’ is applied to one argument,
       but its type ‘()’ has none
       In the expression: () ()
       In an equation for ‘it’: it = () ()
     • Relevant bindings include it :: t (bound at
 <interactive>:1:1)
}}} With `GHC_COLORS="message=0"`, this is what you see: {{{ #!html
 Prelude> () ()

 <interactive>:1:1: error:
     • Couldn't match expected type ‘() -> t’ with actual type ‘()’
     • The function ‘()’ is applied to one argument,
       but its type ‘()’ has none
       In the expression: () ()
       In an equation for ‘it’: it = () ()
     • Relevant bindings include it :: t (bound at
 <interactive>:1:1)
}}} And this is what you'd prefer to see with `GHC_COLORS="message=0"`: {{{ #!html
 Prelude> () ()

 <interactive>:1:1: error:
     • Couldn't match expected type ‘() -> t’ with actual type ‘()’
     • The function ‘()’ is applied to one argument,
       but its type ‘()’ has none
       In the expression: () ()
       In an equation for ‘it’: it = () ()
     • Relevant bindings include it :: t (bound at
 <interactive>:1:1)
}}} Is that correct? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 16:11:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 16:11:17 -0000 Subject: [GHC] #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase In-Reply-To: <045.5d7e7d9a3f395b637d10b22da7ba85f9@haskell.org> References: <045.5d7e7d9a3f395b637d10b22da7ba85f9@haskell.org> Message-ID: <060.4a7df9cdc74b3f7448c8e140888e3aad@haskell.org> #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): For the record, I can implement `finZAbsurd` in a messier way that the pattern checker accepts: {{{#!hs finZAbsurd :: Fin 'Z -> a finZAbsurd = finZAbsurd' Refl where finZAbsurd' :: n :~: 'Z -> Fin n -> a finZAbsurd' pf FZ = case pf of finZAbsurd' pf (FS _) = case pf of }}} but that's a lot uglier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 16:14:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 16:14:41 -0000 Subject: [GHC] #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase In-Reply-To: <045.5d7e7d9a3f395b637d10b22da7ba85f9@haskell.org> References: <045.5d7e7d9a3f395b637d10b22da7ba85f9@haskell.org> Message-ID: <060.2152b5424dde28d9b6406f45124f68f0@haskell.org> #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): dfeuer, thanks. Now I see why my example didn't trigger any warnings: the definition of the `T` type itself (i.e., the fact that it was a GADT) was what ruled out the possibility of matching on any of its constructors in `tCharAbsurd`. On the other hand, `Fin` does not have this property, and you're relying on the types of the conlikes in its `COMPLETE` set to rule out the possibility of matching anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 16:18:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 16:18:22 -0000 Subject: [GHC] #13718: diagnostic colors: differentiate between message head and message body In-Reply-To: <044.d0c2ce3e08b76e30b998d2f85762a984@haskell.org> References: <044.d0c2ce3e08b76e30b998d2f85762a984@haskell.org> Message-ID: <059.a86175909931772b138fb3f4130cf870@haskell.org> #13718: diagnostic colors: differentiate between message head and message body -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:1 RyanGlScott]: > Since I had trouble visualizing this, let me try to format what you're seeing. Thanks for the effort! Yes, that is correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 16:47:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 16:47:52 -0000 Subject: [GHC] #13720: INLINE pragma semantics changed since 8.0.2 In-Reply-To: <049.7908e52fa1c75d7628d10b8b19ba0d16@haskell.org> References: <049.7908e52fa1c75d7628d10b8b19ba0d16@haskell.org> Message-ID: <064.2c85c747a19c3a78628ea6a0fe679c63@haskell.org> #13720: INLINE pragma semantics changed since 8.0.2 -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: Commit 2effe18ab51d66474724d38b20e49cc1b8738f60 (The Early Inline Patch) caused this. From that commit, I see a Note was added, which might explain why this behavior was adopted: {{{#!hs {- Note [Inline in InitialPhase] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In GHC 8 and earlier we did not inline anything in the InitialPhase. But that is confusing for users because when they say INLINE they expect the function to inline right away. So now we do inlining immediately, even in the InitialPhase, assuming that the Id's Activation allows it. This is a surprisingly big deal. Compiler performance improved a lot when I made this change: perf/compiler/T5837.run T5837 [stat too good] (normal) perf/compiler/parsing001.run parsing001 [stat too good] (normal) perf/compiler/T12234.run T12234 [stat too good] (optasm) perf/compiler/T9020.run T9020 [stat too good] (optasm) perf/compiler/T3064.run T3064 [stat too good] (normal) perf/compiler/T9961.run T9961 [stat too good] (normal) perf/compiler/T13056.run T13056 [stat too good] (optasm) perf/compiler/T9872d.run T9872d [stat too good] (normal) perf/compiler/T783.run T783 [stat too good] (normal) perf/compiler/T12227.run T12227 [stat too good] (normal) perf/should_run/lazy-bs-alloc.run lazy-bs-alloc [stat too good] (normal) perf/compiler/T1969.run T1969 [stat too good] (normal) perf/compiler/T9872a.run T9872a [stat too good] (normal) perf/compiler/T9872c.run T9872c [stat too good] (normal) perf/compiler/T9872b.run T9872b [stat too good] (normal) perf/compiler/T9872d.run T9872d [stat too good] (normal) -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 16:51:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 16:51:27 -0000 Subject: [GHC] #13720: INLINE pragma semantics changed since 8.0.2 In-Reply-To: <049.7908e52fa1c75d7628d10b8b19ba0d16@haskell.org> References: <049.7908e52fa1c75d7628d10b8b19ba0d16@haskell.org> Message-ID: <064.a2f70d809094ed7801579fedc03e792d@haskell.org> #13720: INLINE pragma semantics changed since 8.0.2 -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): BTW, there's a warning you get when compiling `A`: {{{ A.hs:9:11: warning: [-Winline-rule-shadowing] Rule "h x" may never fire because ‘h’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ‘h’ | 9 | {-# RULES "h x" forall x . h x = error "REWRITE" #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} If you follow GHC's advice: {{{#!hs module A where {-# INLINE f #-} f x = h x {-# INLINE[0] h #-} h x = x {-# RULES "h x" forall x . h x = error "REWRITE" #- }}} Then you get back the pre-8.2 behavior: {{{ $ /opt/ghc/8.2.1/bin/ghc B.hs -O2 -fforce-recomp -ddump-simpl | grep qux -A5 qux :: Integer [GblId, Str=x] qux = error .... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 17:07:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 17:07:56 -0000 Subject: [GHC] #8721: Testsuite not reporting errors for DYN way on OS X In-Reply-To: <046.8af9e017e06f897fefadc3e624641754@haskell.org> References: <046.8af9e017e06f897fefadc3e624641754@haskell.org> Message-ID: <061.abea69f2b21134d1df45a848aa25ed6f@haskell.org> #8721: Testsuite not reporting errors for DYN way on OS X -------------------------------+---------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: | Keywords: dynamic linking Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Test Case: 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 Thu May 18 17:35:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 17:35:57 -0000 Subject: [GHC] #13720: INLINE pragma semantics changed since 8.0.2 In-Reply-To: <049.7908e52fa1c75d7628d10b8b19ba0d16@haskell.org> References: <049.7908e52fa1c75d7628d10b8b19ba0d16@haskell.org> Message-ID: <064.f878351f1f6eda7080d1852d6f4cf450@haskell.org> #13720: INLINE pragma semantics changed since 8.0.2 -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Yes, and the warning is spot on target. Without the pragma there is no reason to suppose that the rule would ever fire; that it did so before is a happy accident. So I think GHC is behaving as advertised. Re-open if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 17:37:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 17:37:06 -0000 Subject: [GHC] #12468: GADTs don't refine hole types In-Reply-To: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> References: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> Message-ID: <070.b5a0efcb84b2778486111c9c84e771d4@haskell.org> #12468: GADTs don't refine hole types -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 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: #11325 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * os: MacOS X => Unknown/Multiple * related: => #11325 Comment: As noted in #11325, this is actually a regression from GHC 7.10 to 8.0. In GHC 7.10.3, you get the behavior that you seek: {{{ $ /opt/ghc/7.10.3/bin/ghci Bug.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:7:7: Found hole ‘_’ with type: Int Relevant bindings include f :: T a -> a (bound at Bug.hs:7:1) In the expression: _ In an equation for ‘f’: f I = _ Failed, modules loaded: none. }}} As opposed to the current behavior: {{{ $ /opt/ghc/8.0.1/bin/ghci Bug.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:7:7: error: • Found hole: _ :: a Where: ‘a’ is a rigid type variable bound by the type signature for: f :: forall a. T a -> a at Bug.hs:6:6 • In the expression: _ In an equation for ‘f’: f I = _ • Relevant bindings include f :: T a -> a (bound at Bug.hs:7:1) Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 17:39:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 17:39:37 -0000 Subject: [GHC] #11325: Type of hole does not get refined after pattern matching on [GADT] constructors In-Reply-To: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> References: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> Message-ID: <066.06c1fa1a850a1362c3ddf790b1d0864b@haskell.org> #11325: Type of hole does not get refined after pattern matching on [GADT] constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: GADTs Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: #12468 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12468 Comment: See #12468, where SPJ argues that the current behavior is not necessarily wrong, and proposes that we should instead report something to the effect of: {{{ • Found hole: _ :: ty ... • NB: ty ~ Maybe a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 17:50:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 17:50:50 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.2778e1e055fb9f3cb44d072dff5351a2@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13122 Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906,#13670 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by ntc2): * cc: ntc2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 17:52:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 17:52:44 -0000 Subject: [GHC] #13720: INLINE pragma semantics changed since 8.0.2 In-Reply-To: <049.7908e52fa1c75d7628d10b8b19ba0d16@haskell.org> References: <049.7908e52fa1c75d7628d10b8b19ba0d16@haskell.org> Message-ID: <064.e1741f375504d6ddb6c9392ad244ddc9@haskell.org> #13720: INLINE pragma semantics changed since 8.0.2 -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I feel that the user guide should be updated then to precisely state which optimisations will be performed on `INLINE` bindings. https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #inline-pragma It currently states that "GHC guarantees to inline precisely the code that you wrote, no more and no less." which doesn't seem to be true. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 18:16:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 18:16:35 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.a5c7396940ee58bc3930339c7823b056@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bollu Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12143 Related Tickets: #13309 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Yes, seems like a good plan. Don't forget that you can do this rewriting in the desugarer, but not before that, so getting the typing rules right might be a little tricky. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 19:58:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 19:58:18 -0000 Subject: [GHC] #8703: Use guard pages rather than heap checks In-Reply-To: <046.cc8df1f4c44d21b3204aafaf538413fa@haskell.org> References: <046.cc8df1f4c44d21b3204aafaf538413fa@haskell.org> Message-ID: <061.ba56954ee1b2e6b5be221ee726f89fe9@haskell.org> #8703: Use guard pages rather than heap checks -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 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 varosi): hm, it's not a hackery, but platform specific. Is it needed all pages to be linked in a linked list? I mean that it is possible to realloc() current page until it is possible to resize it. That way we'll have less jumps and guard pages. So we'll have linked list, but from larger memory chunks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 20:47:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 20:47:01 -0000 Subject: [GHC] #8703: Use guard pages rather than heap checks In-Reply-To: <046.cc8df1f4c44d21b3204aafaf538413fa@haskell.org> References: <046.cc8df1f4c44d21b3204aafaf538413fa@haskell.org> Message-ID: <061.437ad6f100ef443be6eb413e2408ef20@haskell.org> #8703: Use guard pages rather than heap checks -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 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 simonmar): Go ahead and try it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 21:10:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 21:10:44 -0000 Subject: [GHC] #13720: INLINE pragma semantics changed since 8.0.2 In-Reply-To: <049.7908e52fa1c75d7628d10b8b19ba0d16@haskell.org> References: <049.7908e52fa1c75d7628d10b8b19ba0d16@haskell.org> Message-ID: <064.966c4e3280e655e4ba912dc16c11133b@haskell.org> #13720: INLINE pragma semantics changed since 8.0.2 -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good point. But what it's doing is indistinguishable from that! If you optimise and then inline, it's the same as if you inline and the optimise -- provided you respect the phases, which GHC does. So I supose we could say "GHC guarantees to behave as if it had inlined precisely the code that you wrote, no more and no less". The "as if" is the important bit! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 21:32:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 21:32:40 -0000 Subject: [GHC] #13721: posix004 test succeeds but then I get an Apple problem report window that says: "posix004 quit unexpectedly" Message-ID: <045.e64b01f82b2b9930ca9fd77ec2ca9e69@haskell.org> #13721: posix004 test succeeds but then I get an Apple problem report window that says: "posix004 quit unexpectedly" -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1-rc2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- make TEST=posix004 {{{ results in ... cd "../../libraries/unix/tests/libposix/posix004.run" && ./posix004 SUMMARY for test run started at Thu May 18 18:21:52 2017 ADT 0:00:03 spent to go through 1 total tests, which gave rise to 10 test cases, of which 9 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures }}} but then I get an Apple problem report window that says: "posix004 quit unexpectedly" Problem details and system configuration attached. This my be Mac specifc but leaving as unknown for now until we have more details -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 21:35:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 21:35:42 -0000 Subject: [GHC] #13721: posix004 test succeeds but then I get an Apple problem report window that says: "posix004 quit unexpectedly" In-Reply-To: <045.e64b01f82b2b9930ca9fd77ec2ca9e69@haskell.org> References: <045.e64b01f82b2b9930ca9fd77ec2ca9e69@haskell.org> Message-ID: <060.abbaa1131cb04ed3eaac010f8dcea564@haskell.org> #13721: posix004 test succeeds but then I get an Apple problem report window that says: "posix004 quit unexpectedly" -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc2 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 George): * Attachment "details.txt" added. problem details and system configuration -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 21:40:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 21:40:15 -0000 Subject: [GHC] #13719: checkFamInstConsistency dominates compile time In-Reply-To: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> References: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> Message-ID: <061.f79de138f87fa2178cb104da885ac262@haskell.org> #13719: checkFamInstConsistency dominates compile time -------------------------------------+------------------------------------- Reporter: niteria | 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: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13092, #13099, | Differential Rev(s): #12191 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That does seem terrible. Thanks for continuing to investiate and explore solutions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 21:53:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 21:53:23 -0000 Subject: [GHC] #13722: intermittent abort crash from make TEST=hs_try_putmvar003 WAY=threaded2 Message-ID: <045.bb28832cb63a983cae54dd44e66caaaf@haskell.org> #13722: intermittent abort crash from make TEST=hs_try_putmvar003 WAY=threaded2 -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- in a bash shell type for i in {1..10}; do make TEST=hs_try_putmvar003 WAY=threaded2 ; done if you look at the output you will probably see at least one instance of {{{ cd "./concurrent/should_run/hs_try_putmvar003.run" && ./hs_try_putmvar003 +RTS -N2 -ls -RTS 1 16 32 100 Wrong exit code for hs_try_putmvar003(threaded2)(expected 0 , actual 134 ) Stderr ( hs_try_putmvar003 ): /bin/sh: line 1: 45386 Abort trap: 6 ./hs_try_putmvar003 +RTS -N2 -ls -RTS 1 16 32 100 *** unexpected failure for hs_try_putmvar003(threaded2) }}} This was on a Mac running the latest OS and Xcode. I can attach the Apple problem report if that helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 21:54:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 21:54:51 -0000 Subject: [GHC] #13722: intermittent abort crash from make TEST=hs_try_putmvar003 WAY=threaded2 In-Reply-To: <045.bb28832cb63a983cae54dd44e66caaaf@haskell.org> References: <045.bb28832cb63a983cae54dd44e66caaaf@haskell.org> Message-ID: <060.b8302e7d9524befcd4b09eba349ed0fc@haskell.org> #13722: intermittent abort crash from make TEST=hs_try_putmvar003 WAY=threaded2 -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc2 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 George): * version: 8.0.1 => 8.2.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 22:28:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 22:28:55 -0000 Subject: [GHC] #13722: intermittent abort crash from make TEST=hs_try_putmvar003 WAY=threaded2 In-Reply-To: <045.bb28832cb63a983cae54dd44e66caaaf@haskell.org> References: <045.bb28832cb63a983cae54dd44e66caaaf@haskell.org> Message-ID: <060.57441089416496fa54ad094ef6dd0dd1@haskell.org> #13722: intermittent abort crash from make TEST=hs_try_putmvar003 WAY=threaded2 -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc2 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 George): It seems that one may go into an infinite loop consuming a very high amount of system time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 18 22:51:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 May 2017 22:51:04 -0000 Subject: [GHC] #13723: Recover gracefully from simplifier tick exhaustion Message-ID: <045.8e6fc95b352c306d9dc1135bc0739e5f@haskell.org> #13723: Recover gracefully from simplifier tick exhaustion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- Currently, we have just one tick limit. If the simplifier runs out of ticks, GHC simply gives up and exits. But that shouldn't ''really'' be necessary. In a more ideal world, we'd have two or even three tick limits for different kinds of transformations. For example, there are === Transformations that must be performed before `CorePrep` === I hope that we can give a hard upper bound on how many ticks we need to perform these for a given program size. If that limit is exceeded, then we should report a bug. === Transformations that always reduce program size === If a transformation always reduces program size, we can always perform it, even if we're otherwise out of ticks. This includes, at least, beta reduction without duplication. While `RULES` are generally wild, it should be safe to apply rules that reduce code size ''immediately''. For example, {{{#!hs foldr c n (build f) ==> f c n }}} is always fine. These transformations can share a tick limit with the mandatory transformations mentioned above. === Transformations that never increase program size === We can be generous with these, but need some limit. === Transformations that may increase program size === These need the harshest limit, of course, but probably not (much?) harsher than what we currently have. ---- The idea is that even if one tick limit is exceeded, the "higher priority" transformations can be allowed to continue anyway. Exceeding tick limits for most transformations would lead to a warning, rather than an error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 00:33:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 00:33:57 -0000 Subject: [GHC] #13722: intermittent abort crash from make TEST=hs_try_putmvar003 WAY=threaded2 In-Reply-To: <045.bb28832cb63a983cae54dd44e66caaaf@haskell.org> References: <045.bb28832cb63a983cae54dd44e66caaaf@haskell.org> Message-ID: <060.f74edfb7d5238a7b117c024d413a59c0@haskell.org> #13722: intermittent abort crash from make TEST=hs_try_putmvar003 WAY=threaded2 -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: 13434 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate * blockedby: => 13434 Comment: Pretty sure this is the same one as #13434. I can reproduce it on my machine and promised Simon I'd investigate but haven't had a chance yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 01:12:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 01:12:42 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.2925fc3dc8bd2685e39d04784b19db61@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): This is a record wild cards problem. Here is a further reduced test case: {{{ -- A.hs {-# LANGUAGE RecordWildCards #-} module A where import B data E = MkE p (H{..}) = () -- A.hs-boot module A ( E ) where data E -- B.hs module B where import {-# SOURCE #-} A data H = H { h :: E } }}} Probably what is happening is that record wildcards is forcing the thunk for E during renaming, which is far before it is ready. Workaround should be to replace the record wildcard with explicitly listed out fields. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 01:14:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 01:14:52 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.a53206546bdd551739fc92d7f4efe56a@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bollu Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12143 Related Tickets: #13309 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AaronFriel): Given the size and substance of this change, where should I best submit the proposal? To GHC RFCs on GitHub, Phab, or elsewhere? As well, how formal should the documentation be? Is the EBNF and functional description at the page ApplicativeDo sufficient, or should I write up a paper with a more formal description? (I lack even have undergrad degrees yet - to be completed this summer - so I've little experience actually writing and submitting papers.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 01:27:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 01:27:07 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.9e04504337116ba0ab9626eac49953c0@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): Workaround works on real code, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 01:58:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 01:58:18 -0000 Subject: [GHC] #13724: Clamping of llvm llc to -O1 and -O2 Message-ID: <047.d48b0e89728a8ea310f720588810c39a@haskell.org> #13724: Clamping of llvm llc to -O1 and -O2 -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We currently clamp the optimization level of llvm llc (3.9 and 4.0) within `[1,2]`. The reason is that with `-O0`, the naive register allocator can topple over with {{{ Error while trying to spill R1 from class GPR: Cannot scavenge register without an emergency spill slot! }}} and with `-O3` the `llvm::SelectionDAGISel::LowerArguments` may break, when compiling `rts/HeapStackCheck.cmm` with the stage1 ghc. {{{ 0 llc 0x0000000102ae63e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 1 llc 0x0000000102ae69a6 SignalHandler(int) + 358 2 libsystem_platform.dylib 0x00007fffc23f4b3a _sigtramp + 26 3 libsystem_c.dylib 0x00007fffc226498b __vfprintf + 17876 4 llc 0x00000001029d5123 llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) + 5699 5 llc 0x0000000102a21a35 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3381 6 llc 0x0000000102a202b1 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1457 7 llc 0x0000000101bdc474 (anonymous namespace)::ARMDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 20 8 llc 0x00000001025573a6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 134 9 llc 0x000000010274fb12 llvm::FPPassManager::runOnFunction(llvm::Function&) + 498 10 llc 0x000000010274fd23 llvm::FPPassManager::runOnModule(llvm::Module&) + 67 11 llc 0x00000001027501b8 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 920 12 llc 0x000000010195f075 compileModule(char**, llvm::LLVMContext&) + 12133 13 llc 0x000000010195bf0b main + 491 14 libdyld.dylib 0x00007fffc21e5235 start + 1 Stack dump: 0. Program arguments: llc -O3 -mtriple=arm-unknown-linux-gnueabihf -enable-tbaa /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc -o /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_7.lm_s 1. Running pass 'Function Pass Manager' on module '/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc'. 2. Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"' }}} `opt` and `llc` should respect `-opt_lo` and `-opt_lc`, such that `-opt_lc=-O3` can be used to validate the behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 02:26:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 02:26:08 -0000 Subject: [GHC] #13724: Clamping of llvm llc to -O1 and -O2 In-Reply-To: <047.d48b0e89728a8ea310f720588810c39a@haskell.org> References: <047.d48b0e89728a8ea310f720588810c39a@haskell.org> Message-ID: <062.010ca75e38c5f2002b2a8a5e9b6dee03@haskell.org> #13724: Clamping of llvm llc to -O1 and -O2 -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): Note that you can pass `-debug-pass=Structure` and `-debug-pass=Arguments` as arguments to `opt` and `llc. as in {{{ llc -O1 -debug-pass=Structure < /dev/null >/dev/nulll }}} or with a triple: {{{ llc -mtriple=arm-unknown-linux-gnueabihf -O1 -debug-pass=Structure < /dev/null >/dev/nulll }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 03:42:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 03:42:29 -0000 Subject: [GHC] #13725: Remove false dependency on the destination of the popcnt instruction Message-ID: <046.04b5f92966bfece727224b94b7efbe9b@haskell.org> #13725: Remove false dependency on the destination of the popcnt instruction -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D3539 | Wiki Page: -------------------------------------+------------------------------------- fryguybob writes in Phab:D3539, > Some Intel processors appear to have a false dependency on the destination of the popcnt instruction. This could lead to poor performance. A simple way to prevent this is to clear the destination register immediately before the popcnt instruction. Currently I can't produce code from GHC where the source and destination registers are not the same (perhaps someone is interested in producing a test case that does). I'm putting this here in case anyone is interested in investigating further. I'm opening this ticket so I can bump the diff out of the review queue, in hopes that someone might some day pick it up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 04:36:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 04:36:34 -0000 Subject: [GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.6c3a2d877672eb01913174b81bb68bd4@haskell.org> #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by liyang): * cc: liyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 07:14:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 07:14:21 -0000 Subject: [GHC] #13726: Declaring GADT constructor and associated data family with the same name gives weird error Message-ID: <046.d3912534e6b0f207167735f40f0f6a2a@haskell.org> #13726: Declaring GADT constructor and associated data family with the same name gives weird error -------------------------------------+------------------------------------- Reporter: mrkgnao | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The code this is from is really messy. I'll submit a minimal example in a short while if this isn't a known bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 07:14:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 07:14:45 -0000 Subject: [GHC] #13726: Declaring GADT constructor and associated data family with the same name gives weird error In-Reply-To: <046.d3912534e6b0f207167735f40f0f6a2a@haskell.org> References: <046.d3912534e6b0f207167735f40f0f6a2a@haskell.org> Message-ID: <061.de5bae3917dcd07607a62babe3153cb2@haskell.org> #13726: Declaring GADT constructor and associated data family with the same name gives weird error -------------------------------------+------------------------------------- Reporter: mrkgnao | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mrkgnao): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 07:28:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 07:28:33 -0000 Subject: [GHC] #12468: GADTs don't refine hole types In-Reply-To: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> References: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> Message-ID: <070.3a2d4e92f4cde27958cf09d77daaaf03@haskell.org> #12468: GADTs don't refine hole types -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 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: #11325 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): On second thoughts, I don't think I'd fully realised that there was a type signature to guide the type checker. Yes, it probably does make sense to "normalise" the hole with all the "givens". And it's very easy to do, a 2-line change. Patch coming -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 07:29:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 07:29:30 -0000 Subject: [GHC] #13726: Declaring GADT constructor and associated data family with the same name gives weird error In-Reply-To: <046.d3912534e6b0f207167735f40f0f6a2a@haskell.org> References: <046.d3912534e6b0f207167735f40f0f6a2a@haskell.org> Message-ID: <061.c9d603e5b88b24b628310eb4f3927b38@haskell.org> #13726: Declaring GADT constructor and associated data family with the same name gives weird error -------------------------------------+------------------------------------- Reporter: mrkgnao | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by mrkgnao: @@ -2,1 +2,2 @@ - short while if this isn't a known bug. + short while if this isn't a known bug fixed in 8.2.1. GHC complains about + the kinds not matching instead of giving a "multiple definitions" error. New description: The code this is from is really messy. I'll submit a minimal example in a short while if this isn't a known bug fixed in 8.2.1. GHC complains about the kinds not matching instead of giving a "multiple definitions" error. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 07:41:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 07:41:04 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.097262ecf5adee547d612f4a35b8dd7b@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Seems dangerously fragile to me. Can you see a path to fixing it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 07:44:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 07:44:41 -0000 Subject: [GHC] #13723: Recover gracefully from simplifier tick exhaustion In-Reply-To: <045.8e6fc95b352c306d9dc1135bc0739e5f@haskell.org> References: <045.8e6fc95b352c306d9dc1135bc0739e5f@haskell.org> Message-ID: <060.21af0750465913c96613d8733cb63155@haskell.org> #13723: Recover gracefully from simplifier tick exhaustion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.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 simonpj): Currently if the limit is exceeded we stop. It would be better if, when the limit was exceeded we refrained from doing the relevant transformation. That opens up a new debugging mechanism. If you get a Lint error you can binary-chop your way to exactly the transformation that introduced it. But it does impose a cost; every transformation needs a conditional, and a code-path for not doing the transformation. We'd need to check what perf impact this had. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 08:12:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 08:12:05 -0000 Subject: [GHC] #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules Message-ID: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `-Wmissing-home-modules` feature was implemented in order to be used by Cabal (see also #13129), however it turns out that it currently has a minor bug which makes it much less useful for `cabal` as we can't enable it for executables this way, as Cabal needs to provide the path to the Main module directly. Consider the following two files: - `src-lib/M1.hs` {{{#!hs module M1 where }}} - `src-exe/Main.hs` {{{#!hs import M1 main = return () }}} And now consider the following inconsistent results: Expected good behaviour: {{{ ghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib -isrc-exe Main : warning: [-Wmissing-home-modules] Modules are not listed in command line: M1 [1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o ) [2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o ) Linking src-exe/Main ... }}} {{{ ghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib -isrc-exe M1 Main [1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o ) [2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o ) Linking src-exe/Main ... }}} Unexpected bad behaviour: {{{ ghc-8.2.1 -fforce-recomp -Wmissing-home-modules src-lib/M1.hs src- exe/Main.hs : warning: [-Wmissing-home-modules] Modules are not listed in command line: M1 Main [1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o ) [2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o ) Linking src-exe/Main ... }}} {{{ ghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib M1 src-exe/Main : warning: [-Wmissing-home-modules] Modules are not listed in command line: Main [1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o ) [2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o ) Linking src-exe/Main ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 08:12:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 08:12:24 -0000 Subject: [GHC] #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules In-Reply-To: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> References: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> Message-ID: <057.aec87d7f1778a229c94803f204bf746f@haskell.org> #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules -------------------------------------+------------------------------------- Reporter: hvr | Owner: Yuras Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: (none) => Yuras -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 08:28:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 08:28:30 -0000 Subject: [GHC] #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules In-Reply-To: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> References: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> Message-ID: <057.2ee3eeac6a0f7334df0ddcbdb6851391@haskell.org> #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules -------------------------------------+------------------------------------- Reporter: hvr | Owner: Yuras Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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 Yuras): The problem here: when file is passed to command line, we don't know yet the module name at the time we generate the warning. And we can't use the file name to guess the module name because executable main module filename could be anything. What if we just ignore "Main" module unconditionally, and don't generate the warning for it? Will it work for cabal? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 08:54:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 08:54:56 -0000 Subject: [GHC] #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules In-Reply-To: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> References: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> Message-ID: <057.37f40d39446950f04dcdcbae706e836e@haskell.org> #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules -------------------------------------+------------------------------------- Reporter: hvr | Owner: Yuras Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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 hvr): Replying to [comment:2 Yuras]: > What if we just ignore "Main" module unconditionally, and don't generate the warning for it? Will it work for cabal? Yeah, I think that's a good enough hack for now. Can we ignore the Main module only when we compile an executable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 09:40:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 09:40:24 -0000 Subject: [GHC] #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules In-Reply-To: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> References: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> Message-ID: <057.88cc08c286e4569f8428ed6083af8f05@haskell.org> #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules -------------------------------------+------------------------------------- Reporter: hvr | Owner: Yuras Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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 refold): IMO that makes sense, given that the user can also specify -main-is via ghc-options. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 09:56:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 09:56:47 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.c2070c94f8d25d8c098efeb65a60d230@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bollu Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12143 Related Tickets: #13309 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Editing the ApplicativeDo wiki page is fine. Thanks for tackling this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 10:11:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 10:11:53 -0000 Subject: [GHC] #12468: GADTs don't refine hole types In-Reply-To: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> References: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> Message-ID: <070.33856e5c6b1e99705e9e4b0521ed3b8f@haskell.org> #12468: GADTs don't refine hole types -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 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: #11325 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"433b80dec1cfef787fc1327a9eada1791b11c12e/ghc" 433b80d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="433b80dec1cfef787fc1327a9eada1791b11c12e" Ensure that insolubles are fully rewritten I was alerted to this by Trac #12468 and #11325. We were treating insolubles (and "hole" constraints are treated as insoluble) inconsistently. In some places we were carefully rewriting them e.g. Note [Make sure that insolubles are fully rewritten] in TcCanonical. But in TcSimplify we weren't feeding them into the solver. As a result, "hole" constraints were not being rewritten, which some users found confusing, and I think rightly so. This patch also fixes a bug in TcSMonad.emitInsoluble, in which two different "hole" constriants could be treated (bogusly) as duplicates, thereby losing one. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 10:11:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 10:11:53 -0000 Subject: [GHC] #11325: Type of hole does not get refined after pattern matching on [GADT] constructors In-Reply-To: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> References: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> Message-ID: <066.9f155d1ad1d21f467cf1871212b97968@haskell.org> #11325: Type of hole does not get refined after pattern matching on [GADT] constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: GADTs Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: #12468 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"433b80dec1cfef787fc1327a9eada1791b11c12e/ghc" 433b80d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="433b80dec1cfef787fc1327a9eada1791b11c12e" Ensure that insolubles are fully rewritten I was alerted to this by Trac #12468 and #11325. We were treating insolubles (and "hole" constraints are treated as insoluble) inconsistently. In some places we were carefully rewriting them e.g. Note [Make sure that insolubles are fully rewritten] in TcCanonical. But in TcSimplify we weren't feeding them into the solver. As a result, "hole" constraints were not being rewritten, which some users found confusing, and I think rightly so. This patch also fixes a bug in TcSMonad.emitInsoluble, in which two different "hole" constriants could be treated (bogusly) as duplicates, thereby losing one. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 10:16:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 10:16:35 -0000 Subject: [GHC] #12468: GADTs don't refine hole types In-Reply-To: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> References: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> Message-ID: <070.255501aa2da0287235cd9b04c543633a@haskell.org> #12468: GADTs don't refine hole types -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: gadt/T12468 Blocked By: | Blocking: Related Tickets: #11325 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => gadt/T12468 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 10:17:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 10:17:41 -0000 Subject: [GHC] #11325: Type of hole does not get refined after pattern matching on [GADT] constructors In-Reply-To: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> References: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> Message-ID: <066.2047f4115bc39b874e1e3f07ff1707aa@haskell.org> #11325: Type of hole does not get refined after pattern matching on [GADT] constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: GADTs Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: #12468 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've confirmed that the 7.10 behaviour is restored, but I didn't add a second test ... the test for #12468 seems sufficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 10:17:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 10:17:48 -0000 Subject: [GHC] #11325: Type of hole does not get refined after pattern matching on [GADT] constructors In-Reply-To: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> References: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> Message-ID: <066.06c53fda8215986db0520e3a61a2697b@haskell.org> #11325: Type of hole does not get refined after pattern matching on [GADT] constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: GADTs Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: #12468 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 10:30:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 10:30:14 -0000 Subject: [GHC] #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules In-Reply-To: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> References: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> Message-ID: <057.b3916ed2b7af78a94d207bcaec573e38@haskell.org> #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules -------------------------------------+------------------------------------- Reporter: hvr | Owner: Yuras Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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): Phab:D3598 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Yuras): * status: new => patch * differential: => Phab:D3598 Comment: I didn't figured out how to add a test case with subdirectory. hvr, do you know how to do it? Could you please add it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 10:47:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 10:47:21 -0000 Subject: [GHC] #13728: Clarify the difference between NameL and NameU in Template Haskell Message-ID: <048.17c37a288703f66f28ee4fb551c7bfee@haskell.org> #13728: Clarify the difference between NameL and NameU in Template Haskell -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | 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: -------------------------------------+------------------------------------- Reading the docs in Language.Haskell.TH.Syntax, I got the impression that when reifying the type {{{#!hs data P a b = P a b }}} defined outside of TH, the type variables a and b will be NameLs; but in my experiments, they come out as NameUs. Are NameLs used anywhere at all? In any case, I think the docs should be updated to explain the difference clearly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 10:55:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 10:55:27 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.7ef2c9f8e1be938de8ed5fb0e31a5031@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by simonpj): I'm on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 11:24:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 11:24:10 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.1aee460846f0756b9f8abce372647ded@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8fe37a0222517c3af5ffbb793fa738ad7f3eac3d/ghc" 8fe37a02/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8fe37a0222517c3af5ffbb793fa738ad7f3eac3d" Account for IfUnpackCo in freeNamesIfDecl We were simply failing to recognise all the free variables of an IfaceDecl, notably the ones in the coercion of an IfUnpackCo. Result: the dependency analysis got messed up, so that fingerprint calculation went wrong. Trac #13695 showed it up. A test case is tricky but the fix is a solid one. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 11:25:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 11:25:02 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.c17740294c791514d492072223f312af@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by simonpj): * status: new => merge Comment: Thanks for the test case. It was a simple, outright bug. Worth merging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 13:55:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 13:55:08 -0000 Subject: [GHC] #13718: diagnostic colors: differentiate between message head and message body In-Reply-To: <044.d0c2ce3e08b76e30b998d2f85762a984@haskell.org> References: <044.d0c2ce3e08b76e30b998d2f85762a984@haskell.org> Message-ID: <059.6cdc6a6328ec9ac249ee1cd41316ac44@haskell.org> #13718: diagnostic colors: differentiate between message head and message body -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13444 | Differential Rev(s): phab:D3599 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Rufflewind): * status: new => patch * differential: => phab:D3599 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 14:00:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 14:00:15 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2313625=3A_GHC_internal_error=3A_?= =?utf-8?q?=E2=80=98Y=E2=80=99_is_not_in_scope_during_type_checki?= =?utf-8?q?ng=2C_but_it_passed_the_renamer?= In-Reply-To: <049.ad31bbf13fa6a8340cd37900420f039f@haskell.org> References: <049.ad31bbf13fa6a8340cd37900420f039f@haskell.org> Message-ID: <064.3c8b3b872fe055fd9a8571db915c6b46@haskell.org> #13625: GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: mpickering | 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 Simon Peyton Jones ): In [changeset:"2501fb70691f80b9c48e5f9bdea3b897653f499a/ghc" 2501fb70/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2501fb70691f80b9c48e5f9bdea3b897653f499a" Fix scoping of data cons during kind checking Trac #13625 pointed out that in data X :: Y where Y :: X we need 'Y' to be in scope (as APromotionErr) when dealing with X's kind signature. Previously we got a crash. This patch simplifies the code as well as making it work. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 14:01:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 14:01:16 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2313625=3A_GHC_internal_error=3A_?= =?utf-8?q?=E2=80=98Y=E2=80=99_is_not_in_scope_during_type_checki?= =?utf-8?q?ng=2C_but_it_passed_the_renamer?= In-Reply-To: <049.ad31bbf13fa6a8340cd37900420f039f@haskell.org> References: <049.ad31bbf13fa6a8340cd37900420f039f@haskell.org> Message-ID: <064.9477d74cefc83bd4eff5d50241c5571a@haskell.org> #13625: GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T13625 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => polykinds/T13625 Comment: Thanks for reporting. Perhaps worth merging, but it only affects incorrect programs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 14:12:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 14:12:13 -0000 Subject: [GHC] #13729: ghc does not pick up TH changes across package boundaries Message-ID: <048.c28ecbc30553d679f691354a7861c80a@haskell.org> #13729: ghc does not pick up TH changes across package boundaries -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the following three modules: {{{#!hs module Types where data Foo = Bar }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module TH where import Language.Haskell.TH import Language.Haskell.TH.Syntax import Types th_string = lift . show =<< reify ''Foo }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Main where import TH main = putStrLn $(th_string) }}} The goal is to make Main recompile if the definition of Types.Foo changes. If I simply put the three files in the same directory and compile with ghc, it works. However, if I put Types and TH in package A and Main in package B, then ghc doesn't recompile B.Main if I change the definition of A.Types.Foo and reinstall the package A. I tried this with both stack and cabal-install. In both cases I compiled B.Main directly with ghc, so it's not Cabal that's hiding the changes. If I pass -fforce-recomp to ghc, Main recompiles as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 14:44:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 14:44:40 -0000 Subject: [GHC] #13719: checkFamInstConsistency dominates compile time In-Reply-To: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> References: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> Message-ID: <061.42ceaadcc6c75eb5bf8520ba0d028cdd@haskell.org> #13719: checkFamInstConsistency dominates compile time -------------------------------------+------------------------------------- Reporter: niteria | 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: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13092, #13099, | Differential Rev(s): phab:D3600 #12191 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * differential: => phab:D3600 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 15:03:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 15:03:01 -0000 Subject: [GHC] #13226: Compiler allocation regressions from top-level string literal patch In-Reply-To: <045.604945792be7d5cdffc4562258697d1f@haskell.org> References: <045.604945792be7d5cdffc4562258697d1f@haskell.org> Message-ID: <060.b1e12d33131ff8b507517f2ea79349d7@haskell.org> #13226: Compiler allocation regressions from top-level string literal patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): In the meantime, can the threshold be bumped up a bit to to avoid the constant complaints from Harbormaster? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 15:22:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 15:22:37 -0000 Subject: [GHC] #13726: Declaring GADT constructor and associated data family with the same name gives weird error In-Reply-To: <046.d3912534e6b0f207167735f40f0f6a2a@haskell.org> References: <046.d3912534e6b0f207167735f40f0f6a2a@haskell.org> Message-ID: <061.9df9073865470fe88e7ec45637a6be7b@haskell.org> #13726: Declaring GADT constructor and associated data family with the same name gives weird error -------------------------------------+------------------------------------- Reporter: mrkgnao | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded Comment: Please do submit a minimal example, as I can't deduce what program you're trying to run, and the description of the error message is sufficiently vague that I can't identify what the problem is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 17:32:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 17:32:43 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.2e77310f72094b7cadd2b2a0148fed16@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Alberto Valverde [https://mail.haskell.org/pipermail/ghc- devs/2017-May/014222.html discovered] another occurrence of this bug: the `fingertree-0.1.1.0` [http://hackage.haskell.org/package/fingertree-0.1.1.0 test suite]: {{{ $ ~/Software/ghc-8.0.2/bin/ghc -O -fforce-recomp FingerTreeTestMain.hs [1 of 2] Compiling FingerTree ( FingerTree.hs, FingerTree.o ) [2 of 2] Compiling Main ( FingerTreeTestMain.hs, FingerTreeTestMain.o ) Linking FingerTreeTestMain ... $ ./FingerTreeTestMain True $ ~/Software/ghc-8.2.0.20170507/bin/ghc -O -fforce-recomp FingerTreeTestMain.hs [1 of 2] Compiling FingerTree ( FingerTree.hs, FingerTree.o ) [2 of 2] Compiling Main ( FingerTreeTestMain.hs, FingerTreeTestMain.o ) Linking FingerTreeTestMain ... $ ./FingerTreeTestMain FingerTreeTestMain: <> }}} In case it's useful, I'll attach a minimized version of the test suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 17:33:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 17:33:11 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.fe12130a46bff39fd2be2c37946302e3@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "FingerTree.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 17:33:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 17:33:20 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.f3e8777afab08058336d3b57f70fc959@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "FingerTreeTestMain.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 19:07:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 19:07:21 -0000 Subject: [GHC] #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException Message-ID: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException ----------------------------------------+------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- I tried running some `GLUT` code in macOS Sierra (Version 10.12.5 (16F73)) and ran into a strange error. If you're willing to use `cabal-install`, you can just do this: {{{ $ cabal install GLFW-0.5.2.5 }}} And run this module in with `runghc`: {{{#!hs -- GLUT.hs module Main where import Graphics.UI.GLUT (($=), getArgsAndInitialize, createWindow, displayCallback, mainLoop) main :: IO () main = do (_progName, _args) <- getArgsAndInitialize _window <- createWindow "Hello World" displayCallback $= return () mainLoop }}} {{{ $ runghc GLUT.hs 2017-05-19 12:03:02.199 ghc[24628:669385] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: nextEventMatchingMask should only be called from the Main Thread! }}} On the other hand, compiling and running the executable works without issue. Alternatively, you can compile the attached files, which require no dependencies: {{{ $ ghc HsGLUT.c GLUT2.hs [1 of 1] Compiling Main ( GLUT2.hs, GLUT2.o ) Linking GLUT2 ... $ ghci HsGLUT.o GLUT2.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/rscott/.ghci [1 of 1] Compiling Main ( GLUT2.hs, interpreted ) Ok, modules loaded: Main. λ> main 2017-05-19 12:06:15.365 ghc[24671:670166] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: nextEventMatchingMask should only be called from the Main Thread! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 19:07:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 19:07:42 -0000 Subject: [GHC] #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException In-Reply-To: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> References: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> Message-ID: <065.c48d639137714470a9cc622ad22514b4@haskell.org> #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Changes (by RyanGlScott): * Attachment "HsGLUT.c" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 19:08:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 19:08:03 -0000 Subject: [GHC] #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException In-Reply-To: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> References: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> Message-ID: <065.44216e4e8be5391ebd18ab2cca9ae593@haskell.org> #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Changes (by RyanGlScott): * Attachment "GLUT2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 19:43:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 19:43:46 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.449b291ef67431730feb901d6c6c1f7b@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks, that's helpful. Does the `fingertree` example of the bug happen in HEAD? (The other example does not.) Are you sure it's the same bug? Just for info, I have investigated this a bit, and I know what's going on. The tricky bit is that we want to specialise dictionary functions (which arise from instance decls); but they produce dictionaries, and it's rather easy to mess up. I think I have a reasonably simple solution, but it's a solition I can't say is wrong, rather than one that obviously right. So I've been ruminating, so far to little avail. Is it actually a show-stopper for anyone? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 20:24:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 20:24:26 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.de8e5b5114f74811f39a003063e9b308@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Simon, I can't speak for absolute HEAD, but I tried it with a very recent build and the bug happens there. I tried modifying the code to use type families and equality constraints to eliminate `FunctionalDependencies`, `FlexibleContexts`, and `UndecidableInstances`, but the same bug shows up. I've not yet been able to make the bug happen using single-parameter type classes, but that certainly doesn't mean it's impossible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 20:27:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 20:27:40 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.9dbd9fb698b2df1b5b4e00c39a943e31@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): As for your other question, Simon, I think we likely ''should'' consider this a show-stopper. This is not test code designed to break GHC; it's test code designed to break a library, using absolutely standard methodology. I don't think it does anything that would be surprising to see in production code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 20:47:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 20:47:05 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.ab868f304aa86369ceb3546e23eef4b1@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): By the way, commit a920404fb12fb52a59e4f728cce4d662a418c5f8 (Fix TcSimplify.decideQuantification for kind variables) is the first commit in which the `fingertree` looping behavior can be observed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 20:51:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 20:51:25 -0000 Subject: [GHC] #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException In-Reply-To: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> References: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> Message-ID: <065.9933e0b5475b9807a70c416edc5cf60f@haskell.org> #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by bgamari): I wonder if this is because `unsafe` FFI calls are performed as `safe` calls in GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 22:19:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 22:19:35 -0000 Subject: [GHC] #13119: yesod-auth-1.4.15: ghc: panic! (the 'impossible' happened) Linker error In-Reply-To: <046.c9301e7c91710c08ea06cbe6838b0d57@haskell.org> References: <046.c9301e7c91710c08ea06cbe6838b0d57@haskell.org> Message-ID: <061.eaa7b57a120f6edfd25902605e07b1b5@haskell.org> #13119: yesod-auth-1.4.15: ghc: panic! (the 'impossible' happened) Linker error ---------------------------------+--------------------------------- Reporter: mcmayer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: ghc panic Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12479 | Differential Rev(s): Wiki Page: | ---------------------------------+--------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12479 Comment: Closing as a duplicate of #12479 (which was fixed in GHC 8.0.2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 22:20:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 22:20:29 -0000 Subject: [GHC] #12897: yesod-auth-1.4.13.2 failed during the building phase. In-Reply-To: <051.9eecd9aa0233266e05fba7c937315f68@haskell.org> References: <051.9eecd9aa0233266e05fba7c937315f68@haskell.org> Message-ID: <066.b89951736d91b61766cd53602bb19cf2@haskell.org> #12897: yesod-auth-1.4.13.2 failed during the building phase. -------------------------------------+------------------------------------- Reporter: onomatopoeia | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: #12479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12479 Comment: Closing as a duplicate of #12479 (which was fixed in GHC 8.0.2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 19 22:43:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 May 2017 22:43:43 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.0063bae2145b635f8daa5b77573c4eb9@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think the original issue is fixed. To be extra clear, the original issue was that it was very slow to compile `Language.Haskell.Extension` from `Cabal`. I was able to reproduce this using Cabal at commit [https://github.com/haskell/cabal/commit/eaf2aae18603965ff668384b391fcaa14de19823 eaf2aae18603965ff668384b391fcaa14de19823]. The problem there appeared in GHC commit b9e49d3e9580e13d89efd1f779cb76f610e0d6e0, which added 1024 specialization rules for said module. The problem is now gone. It looks to me as though ezyang's test case in comment:22 doesn't actually relate to the regression; I don't see it moving terribly much from 7.8 to 7.10 or from 7.10 to 8.2. It seems to be looking at other issues. I will try to see how those have shifted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 02:20:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 02:20:25 -0000 Subject: [GHC] #13731: DeriveFunctor and friends don't understand type families Message-ID: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> #13731: DeriveFunctor and friends don't understand type families -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeFamilies #-} data Test ext a where Foo :: a -> Test ext a Extend :: (ExtensionType ext a) -> Test ext a type family ExtensionType ext a data ListExtension type instance ExtensionType ListExtension a = [a] deriving instance Functor (Test ListExtension) {- a.hs:15:1: error: • Can't make a derived instance of ‘Functor (Test ListExtension)’: Constructor ‘Extend’ must use the type variable only as the last argument of a data type • In the stand-alone deriving instance for ‘Functor (Test ListExtension)’ | 15 | deriving instance Functor (Test ListExtension) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Failed, modules loaded: none. -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 03:11:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 03:11:28 -0000 Subject: [GHC] #12136: SIGABRT on right-shift operation against long negative integer In-Reply-To: <046.ca96221614dc5a54b96ee86f683c2b18@haskell.org> References: <046.ca96221614dc5a54b96ee86f683c2b18@haskell.org> Message-ID: <061.4c7a4047af85ab4abd7902544d7a4c3a@haskell.org> #12136: SIGABRT on right-shift operation against long negative integer -----------------------------------+-------------------------------------- Reporter: khibino | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2998 Wiki Page: | -----------------------------------+-------------------------------------- Comment (by khibino): Is this fix merged into ghc-8.0.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 04:14:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 04:14:40 -0000 Subject: [GHC] #12136: SIGABRT on right-shift operation against long negative integer In-Reply-To: <046.ca96221614dc5a54b96ee86f683c2b18@haskell.org> References: <046.ca96221614dc5a54b96ee86f683c2b18@haskell.org> Message-ID: <061.15642b2de89b03ccec8b78b3e225bc8c@haskell.org> #12136: SIGABRT on right-shift operation against long negative integer -----------------------------------+-------------------------------------- Reporter: khibino | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2998 Wiki Page: | -----------------------------------+-------------------------------------- Comment (by bgamari): I'm afraid there likely will not be a 8.0.3 release nor is this patch on the `ghc-8.0` branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 16:25:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 16:25:55 -0000 Subject: [GHC] #12390: List rules for `Coercible` instances In-Reply-To: <051.b98e23ec385e9c48fab8abae2b183162@haskell.org> References: <051.b98e23ec385e9c48fab8abae2b183162@haskell.org> Message-ID: <066.35407ce1dcef0ee0e0eb1f2f60ea8c0c@haskell.org> #12390: List rules for `Coercible` instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: | -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: => newcomer Comment: The idea on comment:2 could reasonably just added to the code in `:info`, as the most mundane approach. As such, this is a newcomer-compatible patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 17:15:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 17:15:55 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2313732=3A_Incorrectly_suggests_=E2=80=98Ty?= =?utf-8?q?peOperators=E2=80=99?= Message-ID: <051.ae3bd80025f5c07502d34ca31492cb7b@haskell.org> #13732: Incorrectly suggests ‘TypeOperators’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Loading the code {{{#!hs {-# Language RankNTypes, GADTs, MagicHash, PolyKinds, TypeInType, ConstraintKinds #-} import Data.Kind import GHC.Exts import qualified Prelude class Semi (a :: TYPE rep) where data Free :: forall rep. (TYPE rep -> Constraint) -> TYPE rep -> Type where Free :: (forall q. ctx q => (p -> q) -> q) -> Free ctx p }}} gives an incorrect suggestion {{{ GHCi, version 8.2.0.20170507: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tXMX.hs, interpreted ) Ok, modules loaded: Main. *Main> :kind Free Semi Free Semi :: * -> * *Main> :kind Free Semi Int# :1:1: error: Not in scope: type constructor or class ‘#’ :1:1: error: Illegal operator ‘#’ in type ‘Free Semi Int #’ Use TypeOperators to allow operators in types :1:1: error: Operator applied to too few arguments: Free Semi Int # *Main> }}} This should recommend enabling `MagicHash` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 17:44:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 17:44:03 -0000 Subject: [GHC] #9936: Data.Fixed truncates 5.17 to 5.16 In-Reply-To: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> References: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> Message-ID: <064.ff55e68f026e2a1f79cf10988f3f443c@haskell.org> #9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9231, #9240 | Differential Rev(s): Phab:D1693 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Yance): I tried my luck with this one as my first contribution, and I get the same result as the comment right above me. I tried changing the way read works on fixed size floats, but there are a couple of tests that enforce for example read "38.009" :: Centi == 38.00, while I would find 38.01 to be a more reasonable answer. I couldn't find anything about this in the Haskell 2010 report, so my question is: Would it be possible to change this specification? Would it be desirable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 17:55:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 17:55:47 -0000 Subject: [GHC] #13306: Problems with type inference for static expressions In-Reply-To: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> References: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> Message-ID: <059.f7ba7430065104fa9209887c5099e271@haskell.org> #13306: Problems with type inference for static expressions -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): Simon, I apologize for the slow reply to your question. I've been rather swamped lately. But I am now preparing a talk proposal for Haskell Exchange 2017 about static pointers so I've spent some time collecting my thoughts. Describing the original use case would get us too far afield, as it is quite complicated and technical. But let me sketch a much simplified but hopefully still convincing simplification. Consider the following definition of a `Closure`: {{{#!hs data Closure :: * -> * where CPtr :: StaticPtr a -> Closure a CApp :: Closure (a -> b) -> Closure a -> Closure b CEnc :: Closure (Dict (Binary a)) -> ByteString -> Closure a instance IsStatic Closure where fromStaticPtr = CPtr }}} `CPtr` allows us to lift static pointers, `CApp` allows us to apply closures of functions to closures of arguments, and finally `CEnc` allows us to lift anything serializable, as long as we have a static pointer to the corresponding `Binary` type class instance dictionary. This definition is similar to the one used in the [http://hackage.haskell.org/package /distributed-closure distributed-closure] package, but adjusted a little bit for the sake of clarity in the current discussion (and my talk). An example of such as a `Closure` is {{{#!hs ex1 :: Text -> Closure (IO ()) ex1 str = static T.putStrLn `CApp` CEnc (static Dict) (encode str) }}} Now since this is such a common pattern, we'd like to clean it up a bit. A ''very'' useful type class is the following: {{{#!hs class c => Static c where closureDict :: Closure (Dict c) }}} This allows us to define {{{#!hs cpure :: Static (Binary a) => a -> Closure a cpure a = CEnc closureDict (encode a) }}} and hence {{{#!hs instance Static (Binary Text) where closureDict = static Dict ex2 :: Text -> Closure (IO ()) ex2 str = static T.putStrLn `CApp` cpure str }}} In a large application we need lots of `Static C` instances, for all kinds of constraints `C`, basically alongside the standard class hierarchy. The first important point I want to make is that in order to do this in a generic way, we need polymorphic static values. For example, consider {{{#!hs dictBinaryList :: Dict (Binary a) -> Dict (Binary [a]) dictBinaryList Dict = Dict instance (Typeable a, Static (Binary a)) => Static (Binary [a]) where closureDict = static dictBinaryList `CApp` closureDict }}} We can only define this `Static (Binary [a])` instance if we can define a polymorphic static value `static dictBinaryList`. Without support for polymorphic static values our ability to define generic code dealing with static pointers would be severely hindered. Now, one example where the issue discussed in this ticket comes to the fore is where type class instances involve type families. Here's where I can only sketch a very simplified example, but I hope it still illustrates the issue. Consider {{{#!hs type family F a :: * where F a = () class C a b where c :: a -> b instance (C a (), b ~ F a) => C a b where c a = c a }}} Now if we want to "lift" that (admittedly rather silly) instance to `Static`, we need a polymorphic static value, just like we did for the case of `Static (Binary [a])` above, except that this time it involves a type family: {{{#!hs foo :: Dict (C a ()) -> Dict (C a (F a)) foo Dict = Dict instance (Typeable a, Static (C a ()), b ~ F a) => Static (C a b) where closureDict = CPtr (static foo :: StaticPtr (Dict (C a ()) -> Dict (C a (F a)))) `CApp` closureDict }}} Note that actually this example seems to be another test case for the bug in this ticket, as this type annotation is required. Without it, we get the error message {{{ src/Main.hs:545:30: error: • Couldn't match type ‘b’ with ‘()’ Expected type: Dict c0 -> Dict (C a b) Actual type: Dict (C a0 ()) -> Dict (C a0 (F a0)) • In the body of a static form: dictC In the first argument of ‘CPtr’, namely ‘(static dictC)’ In the first argument of ‘CApp’, namely ‘CPtr (static dictC)’ • Relevant bindings include closureDict :: Closure (Dict (C a b)) (bound at src/Main.hs:545:3) | 545 | closureDict = CPtr (static dictC) | ^^^^^ }}} where we see that the family has not been reduced (we get pretty much the same error message in ghc 8.0 and ghc 8.2). I'm not totally sure if that error message is the same problem as the one described elsewhere in this ticket, but I hope that this at least clarifies the use case somewhat. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 18:00:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 18:00:52 -0000 Subject: [GHC] #13733: Simplify constraints on RULES LHS Message-ID: <046.c1818a7fbd77b52e8b57f0d827738261@haskell.org> #13733: Simplify constraints on RULES LHS -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- TL;DR: Rewrite rules should be able to match instance methods. I know that the interaction of rewrite rules and classes/instances/methods is unsatisfying, and probably will be for the forseeable future given the current design. But we might still improve little bits. Consider this code: {{{ {-# RULES "[Integer] Eq Refl" forall (xs :: [Integer]). xs == xs = True #-} }}} This is the best I can to express the intention of “dear compile, this is a rule for the equality on lists if the elements are integers”. But what I get is {{{ "[Integer] Eq Refl" [ALWAYS] forall ($dEq_a1Jv :: Eq [Integer]) (xs_a1Hd :: [Integer]). == @ [Integer] $dEq_a1Jv xs_a1Hd xs_a1Hd = GHC.Types.True }}} which is a rule about the method `==` applied to ''any'' evidence of equality about lists. This works in the most obvious cases, such as {{{ alwaysTrue :: [Integer]-> Bool alwaysTrue xs = xs == xs }}} but it does not fire with {{{ delayedId :: a -> a delayedId x = x {-# INLINE [0] delayedId #-} alwaysTrue :: [Integer]-> Bool alwaysTrue xs = xs == delayedId xs {-# NOINLINE alwaysTrue #-} }}} The reason is that directly after the simplifier, in the former case, the Core looks like this {{{ $dEq_a1HH :: Eq [Integer] [LclId, Str=DmdType] $dEq_a1HH = GHC.Classes.$fEq[] @ Integer integer- gmp-1.0.0.1:GHC.Integer.Type.$fEqInteger alwaysTrue [InlPrag=NOINLINE] :: [Integer] -> Bool [LclIdX, Str=DmdType] alwaysTrue = \ (xs_aGT :: [Integer]) -> == @ [Integer] $dEq_a1HH xs_aGT xs_aGT }}} which matches the rule, but in the latter case, by the time the `delayedId` is out of the way, we have {{{ alwaysTrue [InlPrag=NOINLINE] :: [Integer] -> Bool [LclIdX, Arity=1, Str=DmdType ] alwaysTrue = \ (xs_aGT :: [Integer]) -> GHC.Classes.$fEq[]_$c== @ Integer integer-gmp-1.0.0.1:GHC.Integer.Type.$fEqInteger xs_aGT xs_aGT }}} One possible way forward would be to simplify the wanted constraints on the LHS of the rule using the instances in scope: {{{ "[Integer] Eq Refl" [ALWAYS] forall (xs_a1Hd :: [Integer]). GHC.Classes.$fEq[]_$c== @ Integer integer-gmp-1.0.0.1:GHC.Integer.Type.$fEqInteger xs_a1Hd xs_a1Hd = True }}} This might be tricky, of course, as this requires not only help from the type checker, but also some careful tuned simplification of the LHS afterwards (e.g. unfold dictionary accessors)). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 18:18:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 18:18:54 -0000 Subject: [GHC] #13734: Code requires ScopedTypeVariables, possibly erroneously Message-ID: <051.67da3ed2a81909933d3bc41a04f15152@haskell.org> #13734: Code requires ScopedTypeVariables, possibly erroneously -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This doesn't work without `ScopedTypeVariables`, but shouldn't it? (on `8.0.1`, 8.2.0.20170507`) {{{#!hs {-# Language ScopedTypeVariables, TypeApplications, AllowAmbiguousTypes, InstanceSigs #-} class Sized f where size :: Int instance Sized Int where size :: Int size = 42 instance (Sized a, Sized b) => Sized (a, b) where size :: Int size = size @a + size @b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 20:22:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 20:22:19 -0000 Subject: [GHC] #13734: Code requires ScopedTypeVariables, possibly erroneously In-Reply-To: <051.67da3ed2a81909933d3bc41a04f15152@haskell.org> References: <051.67da3ed2a81909933d3bc41a04f15152@haskell.org> Message-ID: <066.08fdc0a0a38ebcab35e3926ef1d52acc@haskell.org> #13734: Code requires ScopedTypeVariables, possibly erroneously -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This looks like expected behavior to me. After all, this won't typecheck without `ScopedTypeVariables` either: {{{#!hs {-# Language ScopedTypeVariables, TypeApplications, InstanceSigs #-} import Data.Proxy class Sized f where size :: proxy f -> Int instance Sized Int where size :: proxy Int -> Int size _ = 42 instance (Sized a, Sized b) => Sized (a, b) where size :: proxy (a, b) -> Int size _ = size (Proxy :: Proxy a) + size (Proxy :: Proxy b) }}} I don't see why `TypeApplications` would be different in that regard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 20:29:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 20:29:29 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.9ae686731496d7dd2f1d6968489509ee@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"80d5190630a975dfa03d1d84d23cdee4f950d58d/ghc" 80d51906/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="80d5190630a975dfa03d1d84d23cdee4f950d58d" base: Explicitly mark Data.Either.{left,right} as INLINABLE Test Plan: read it Reviewers: dfeuer, austin, hvr, nomeata Reviewed By: dfeuer, nomeata Subscribers: nomeata, rwbarton, thomie GHC Trac Issues: #13689 Differential Revision: https://phabricator.haskell.org/D3576 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 20:29:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 20:29:29 -0000 Subject: [GHC] #13699: Pretty printing: Strict record fields are not parenthesized properly In-Reply-To: <043.b6fa972648fe3f86984213baf3e59df6@haskell.org> References: <043.b6fa972648fe3f86984213baf3e59df6@haskell.org> Message-ID: <058.22fa0d8323dda0c4edc2fd3e5f35fcff@haskell.org> #13699: Pretty printing: Strict record fields are not parenthesized properly -------------------------------------+------------------------------------- Reporter: zyla | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: pretty-print | bang record Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3587 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2108460f9211bf5eab98e0f2f3218dcd271eeaad/ghc" 2108460f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2108460f9211bf5eab98e0f2f3218dcd271eeaad" Pretty-print strict record fields from ifaces correctly We need to use parentheses more when pretty-printing types with bang patterns within constructors that use record syntax. Fixes #13699. Test Plan: make test TEST=T13699 Reviewers: austin, bgamari, dfeuer Reviewed By: dfeuer Subscribers: dfeuer, rwbarton, thomie GHC Trac Issues: #13699 Differential Revision: https://phabricator.haskell.org/D3587 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 20:29:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 20:29:29 -0000 Subject: [GHC] #8025: -fno-code and Template Haskell are incompatible In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.14a5042d8e8b0476d602d47301867cf8@haskell.org> #8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"53c78be0aab76a3107c4dacbb1d177afacdd37fa/ghc" 53c78be0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="53c78be0aab76a3107c4dacbb1d177afacdd37fa" Compile modules that are needed by template haskell, even with -fno-code. This patch relates to Trac #8025 The goal here is to enable typechecking of packages that contain some template haskell. Prior to this patch, compilation of a package with -fno-code would fail if any functions in the package were called from within a splice. downsweep is changed to do an additional pass over the modules, targetting any ModSummaries transitively depended on by a module that has LangExt.TemplateHaskell enabled. Those targeted modules have hscTarget changed from HscNothing to the default target of the platform. There is a small change to the prevailing_target logic to enable this. A simple test is added. I have benchmarked with and without a patched haddock (available:https://github.com/duog/haddock/tree/wip-no-explicit-th-compi lation). Running cabal haddock on the wreq package results in a 25% speedup on my machine: time output from patched cabal haddock: real 0m5.780s user 0m5.304s sys 0m0.496s time output from unpatched cabal haddock: real 0m7.712s user 0m6.888s sys 0m0.736s Reviewers: austin, bgamari, ezyang Reviewed By: bgamari Subscribers: bgamari, DanielG, rwbarton, thomie GHC Trac Issues: #8025 Differential Revision: https://phabricator.haskell.org/D3441 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 20:44:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 20:44:33 -0000 Subject: [GHC] #9936: Data.Fixed truncates 5.17 to 5.16 In-Reply-To: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> References: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> Message-ID: <064.f8221ecf88f1302cd99f28ce6426d139@haskell.org> #9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9231, #9240 | Differential Rev(s): Phab:D1693 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: core-libraries-committee@… (added) Comment: Hmm, this is rather tricky. On one hand, I agree with you that rounding seems sensible at first glance; on the other hand, I worry about what might break if we change this beneath users' feet. Perhaps the Core Libraries Committee should weigh in on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 20:48:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 20:48:32 -0000 Subject: [GHC] #13699: Pretty printing: Strict record fields are not parenthesized properly In-Reply-To: <043.b6fa972648fe3f86984213baf3e59df6@haskell.org> References: <043.b6fa972648fe3f86984213baf3e59df6@haskell.org> Message-ID: <058.3629a6aa55eaecd348780569bc83b9d3@haskell.org> #13699: Pretty printing: Strict record fields are not parenthesized properly -------------------------------------+------------------------------------- Reporter: zyla | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Resolution: fixed | Keywords: pretty-print | bang record Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3587 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 20:55:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 20:55:34 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.fc4e716054d7304612a3855614d5fd79@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new * milestone: 8.2.1 => ⊥ Comment: I have merged comment:24 to `ghc-8.2`, but, as has been pointed out above, this is arguably only papering over a symptom. However, we discussed this on the call and it seems that fixing this robustly may be quite tricky. Reopening but milestoning to _|_. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 21:03:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 21:03:16 -0000 Subject: [GHC] #13703: Internal libraries regression in GHC 8.2 (ghc-pkg handling) In-Reply-To: <045.0eb24a47df9920808d8c257fd8ac90fc@haskell.org> References: <045.0eb24a47df9920808d8c257fd8ac90fc@haskell.org> Message-ID: <060.c3d6ce18b7cc68c4e37e168789a21aff@haskell.org> #13703: Internal libraries regression in GHC 8.2 (ghc-pkg handling) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.2.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3590 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 8054a7435dc15bc45c04adabe098a78ff6d6a7eb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 21:03:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 21:03:47 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.57155894afd2488fd0f0047b2aedcfa3@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Core Libraries | Version: 8.0.2 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:D3576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.2` as fdcdcd0f8fdb08125932b7f8a3f5a8adc5d50466. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 21:10:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 21:10:55 -0000 Subject: [GHC] #13226: Compiler allocation regressions from top-level string literal patch In-Reply-To: <045.604945792be7d5cdffc4562258697d1f@haskell.org> References: <045.604945792be7d5cdffc4562258697d1f@haskell.org> Message-ID: <060.b5c0c6fdecd9f666bc874ab81ed04314@haskell.org> #13226: Compiler allocation regressions from top-level string literal patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm not sure what you mean. Which threshold are you referring to? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 20 21:11:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 May 2017 21:11:13 -0000 Subject: [GHC] #8025: -fno-code and Template Haskell are incompatible In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.b5ed1efe218cd38f4fbce0530568a19c@haskell.org> #8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3441 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * differential: => Phab:D3441 * resolution: => fixed * milestone: => 8.4.1 Comment: Thanks Duog! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 21 01:11:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 May 2017 01:11:36 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms Message-ID: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data PLambda a = Var a | Int Int | Bool Bool | If (PLambda a) (PLambda a) (PLambda a) | Add (PLambda a) (PLambda a) | Mult (PLambda a) (PLambda a) | Eq (PLambda a) (PLambda a) | Lam (a -> PLambda a) | App (PLambda a) (PLambda a) newtype Lam = L { un :: forall a. PLambda a } }}} {{{#!hs llam :: (forall a. a -> PLambda a) -> Lam llam f = L (Lam f) }}} works fine, but does not with pattern synonyms: {{{ -- $ ghci -ignore-dot-ghci tirr.hs -- GHCi, version 8.2.0.20170507: http://www.haskell.org/ghc/ :? for help -- [1 of 1] Compiling Main ( tirr.hs, interpreted ) -- -- tirr.hs:20:25: error: -- • Couldn't match expected type ‘forall a. a -> PLambda a’ -- with actual type ‘a0 -> PLambda a0’ -- • In the declaration for pattern synonym ‘LLam’ -- • Relevant bindings include -- a :: a0 -> PLambda a0 (bound at tirr.hs:20:25) -- | -- 20 | pattern LLam a = L (Lam a) -- | ^ -- Failed, modules loaded: none. -- Prelude> pattern LLam :: (forall a. a -> PLambda a) -> Lam pattern LLam a = L (Lam a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 21 08:41:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 May 2017 08:41:31 -0000 Subject: [GHC] #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... In-Reply-To: <046.97ac1572178bf3067f644135fab3a749@haskell.org> References: <046.97ac1572178bf3067f644135fab3a749@haskell.org> Message-ID: <061.f65194cbff97a01923edee6ba6c0e6fe@haskell.org> #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T13662 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Indeed, my problem is gone in ghc-8.2.0.20170517, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 21 09:25:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 May 2017 09:25:00 -0000 Subject: [GHC] #9700: Support C structures in Haskell FFI In-Reply-To: <044.596a97e8d8f649bed4fc2b5d38a5701e@haskell.org> References: <044.596a97e8d8f649bed4fc2b5d38a5701e@haskell.org> Message-ID: <059.ad880edda23debb5dd282c75aa7158ae@haskell.org> #9700: Support C structures in Haskell FFI -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D252 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sboosali): any update? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 21 13:31:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 May 2017 13:31:54 -0000 Subject: [GHC] #8048: Register spilling produces ineffecient/highly contending code In-Reply-To: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> References: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> Message-ID: <061.cdf912eebda45c25d7dddcaa39c14cd8@haskell.org> #8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.6.3 (CodeGen) | Keywords: register Resolution: | allocator spill Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10012 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 21 13:32:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 May 2017 13:32:20 -0000 Subject: [GHC] #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure In-Reply-To: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> References: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> Message-ID: <061.c3ae6541b63c71d36b1609fea51cccda@haskell.org> #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8048 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 21 13:32:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 May 2017 13:32:53 -0000 Subject: [GHC] #8272: testing if SpLim=$rbp and Sp=$rsp changed performance at all In-Reply-To: <045.ecd7af4f53d7df1147bf6a068ec1e485@haskell.org> References: <045.ecd7af4f53d7df1147bf6a068ec1e485@haskell.org> Message-ID: <060.656d9911565b7ea520bd10d9d7bc126c@haskell.org> #8272: testing if SpLim=$rbp and Sp=$rsp changed performance at all -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | callingConvention Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 21 14:33:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 May 2017 14:33:37 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms In-Reply-To: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> References: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> Message-ID: <066.c00d37602efd488868b64872bfcdcfc6@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another infelicity of the interaction between `PatternSynonyms` and `RankNTypes` is that this unidirectional version typechecks: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} module Bug where data PLambda a = Var a | Int Int | Bool Bool | If (PLambda a) (PLambda a) (PLambda a) | Add (PLambda a) (PLambda a) | Mult (PLambda a) (PLambda a) | Eq (PLambda a) (PLambda a) | Lam (a -> PLambda a) | App (PLambda a) (PLambda a) newtype Lam = L { un :: forall a. PLambda a } pattern LLam a <- L (Lam a) }}} And this is what GHCi says about the inferred type of `LLam`: {{{ GHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, modules loaded: Bug. λ> :i LLam pattern LLam :: (a -> PLambda a) -> Lam -- Defined at Bug.hs:13:1 }}} But this does not work in an expression context: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} module Bug where data PLambda a = Var a | Int Int | Bool Bool | If (PLambda a) (PLambda a) (PLambda a) | Add (PLambda a) (PLambda a) | Mult (PLambda a) (PLambda a) | Eq (PLambda a) (PLambda a) | Lam (a -> PLambda a) | App (PLambda a) (PLambda a) newtype Lam = L { un :: forall a. PLambda a } llam f = L (Lam f) }}} {{{ GHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:13:17: error: • Couldn't match expected type ‘a -> PLambda a’ with actual type ‘p’ because type variable ‘a’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: forall a. PLambda a at Bug.hs:13:10-18 • In the first argument of ‘Lam’, namely ‘f’ In the first argument of ‘L’, namely ‘(Lam f)’ In the expression: L (Lam f) • Relevant bindings include f :: p (bound at Bug.hs:13:6) llam :: p -> Lam (bound at Bug.hs:13:1) | 13 | llam f = L (Lam f) | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 21 14:35:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 May 2017 14:35:25 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms In-Reply-To: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> References: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> Message-ID: <066.1859b0b797442c96d40b7a57c81e0e5d@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -18,1 +18,1 @@ - {{{ + {{{#!hs New description: {{{#!hs data PLambda a = Var a | Int Int | Bool Bool | If (PLambda a) (PLambda a) (PLambda a) | Add (PLambda a) (PLambda a) | Mult (PLambda a) (PLambda a) | Eq (PLambda a) (PLambda a) | Lam (a -> PLambda a) | App (PLambda a) (PLambda a) newtype Lam = L { un :: forall a. PLambda a } }}} {{{#!hs llam :: (forall a. a -> PLambda a) -> Lam llam f = L (Lam f) }}} works fine, but does not with pattern synonyms: {{{#!hs -- $ ghci -ignore-dot-ghci tirr.hs -- GHCi, version 8.2.0.20170507: http://www.haskell.org/ghc/ :? for help -- [1 of 1] Compiling Main ( tirr.hs, interpreted ) -- -- tirr.hs:20:25: error: -- • Couldn't match expected type ‘forall a. a -> PLambda a’ -- with actual type ‘a0 -> PLambda a0’ -- • In the declaration for pattern synonym ‘LLam’ -- • Relevant bindings include -- a :: a0 -> PLambda a0 (bound at tirr.hs:20:25) -- | -- 20 | pattern LLam a = L (Lam a) -- | ^ -- Failed, modules loaded: none. -- Prelude> pattern LLam :: (forall a. a -> PLambda a) -> Lam pattern LLam a = L (Lam a) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 21 14:36:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 May 2017 14:36:05 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.046593dbaed2d62a75d6e11dd73e86c4@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > what is stopping GHCi supporting unsafe FFI calls? If I understand Simon correctly, the answer is probably "nothing". However, it's more a question of whether we want to change the semantics of "unsafe" foreign calls (something which would require the involvement of the Haskell Prime committee, if to be done properly). I can see the argument for `unsafe` not placing any new obligations on the compiler and think there's little reason to push for such a change. I do think, however, that it is important that we have a `unsafenogc` call type for the reason you describe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 21 15:50:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 May 2017 15:50:52 -0000 Subject: [GHC] #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules In-Reply-To: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> References: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> Message-ID: <057.0a09bd8d21611e3684858fbf828d9977@haskell.org> #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules -------------------------------------+------------------------------------- Reporter: hvr | Owner: Yuras Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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): Phab:D3598 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:5 Yuras]: > I didn't figured out how to add a test case with subdirectory. hvr, do you know how to do it? Could you please add it? I've found a way (it feels like a minor hack though), I'll soon commandeer phab:D3498 and add what I came up with... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 21 17:04:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 May 2017 17:04:37 -0000 Subject: [GHC] #13736: GHC panic with DataKinds and TypeOperators Message-ID: <045.062c8515a515b4f6b9126b6bf1341552@haskell.org> #13736: GHC panic with DataKinds and TypeOperators -------------------------------------+------------------------------------- Reporter: turion | 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: -------------------------------------+------------------------------------- The following program causes a GHC panic: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} import GHC.TypeLits data Proxy (n :: Nat) = Proxy data Foo a = Foo a foo :: Foo (Proxy (2 * 2)) foo = Foo _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 21 17:11:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 May 2017 17:11:23 -0000 Subject: [GHC] #13736: GHC panic with DataKinds and TypeOperators In-Reply-To: <045.062c8515a515b4f6b9126b6bf1341552@haskell.org> References: <045.062c8515a515b4f6b9126b6bf1341552@haskell.org> Message-ID: <060.62f3704590613f4188f4ce4da6966cc2@haskell.org> #13736: GHC panic with DataKinds and TypeOperators -------------------------------------+------------------------------------- Reporter: turion | 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 turion: @@ -15,0 +15,10 @@ + + The error message is: + + + {{{ + ghc: panic! (the 'impossible' happened) + (GHC version 8.0.2 for x86_64-unknown-linux): + initTc: unsolved constraints + WC {wc_insol = [W] __aBJ :: t_aBI[tau:1] (CHoleCan: _)} + }}} New description: The following program causes a GHC panic: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} import GHC.TypeLits data Proxy (n :: Nat) = Proxy data Foo a = Foo a foo :: Foo (Proxy (2 * 2)) foo = Foo _ }}} The error message is: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] __aBJ :: t_aBI[tau:1] (CHoleCan: _)} }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 21 20:20:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 May 2017 20:20:38 -0000 Subject: [GHC] #13736: GHC panic with DataKinds and TypeOperators In-Reply-To: <045.062c8515a515b4f6b9126b6bf1341552@haskell.org> References: <045.062c8515a515b4f6b9126b6bf1341552@haskell.org> Message-ID: <060.8a6fa3aceb41b75fe3adfb6ae8bfde1f@haskell.org> #13736: GHC panic with DataKinds and TypeOperators -------------------------------------+------------------------------------- Reporter: turion | 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, and has been fixed in GHC 8.2.1, where you'll get this proper error message instead: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:1:1: error: The IO action ‘main’ is not defined in module ‘Main’ | 1 | {-# LANGUAGE DataKinds #-} | ^ Bug.hs:11:11: error: • Found hole: _ :: a0 Where: ‘a0’ is an ambiguous type variable • In the first argument of ‘Main.Foo’, namely ‘_’ In the expression: Main.Foo _ In an equation for ‘Main.foo’: Main.foo = Main.Foo _ • Relevant bindings include foo :: Main.Foo (Main.Proxy (2 * 2)) (bound at Bug.hs:11:1) | 11 | foo = Foo _ | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 21 22:26:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 May 2017 22:26:47 -0000 Subject: [GHC] #11593: Template Haskell: Add a way to get names that are neither capturable nor capturing. In-Reply-To: <047.507e61696acbd5d73fd43e115fb3392c@haskell.org> References: <047.507e61696acbd5d73fd43e115fb3392c@haskell.org> Message-ID: <062.5294b2f8f788fd51750f23721e72151c@haskell.org> #11593: Template Haskell: Add a way to get names that are neither capturable nor capturing. -------------------------------------+------------------------------------- Reporter: cgibbard | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: | yhjulwwiefzojcbxybbruweejw Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 00:53:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 00:53:51 -0000 Subject: [GHC] #13737: Have typechecking produce HsType Typechecked instead of Type Message-ID: <047.10980034e11b4870fb14c5cc4724de83@haskell.org> #13737: Have typechecking produce HsType Typechecked instead of Type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Right now, there is an unfortunate lack of parallelism between expressions and types. When an expression is typechecked, it is transformed from `HsExpr Name` to `HsExpr TcId`. When a type is typechecked, it is transformed from `HsType Name` to `Type`. This arrangement has served us well enough for some time, but it has several drawbacks: - Validity checking is really meant to be done over user-written syntax. This bit when implementing #11715, when validity checking couldn't tell the difference between `Int => Int` (bad) and `Int -> Int` (good). There may be other opportunities for simplification by having the user-written syntax available. - The situation above extends to type-level declarations. That is, an `HsDecl Name` for a datatype goes straight to a `TyCon`, instead of to a typechecked form of source. This is problematic because it means that all of typechecking must happen ''twice''. The first is to figure out the kind of the `TyCon` (the is the `kc` pass); the actual result is discarded. Then, typechecking is repeated with the known `TyCon` kind; this pass should always succeed and is more like desugaring than typechecking. But all the constraint generation and solving happens again. - This second pass uses knot-tied `TyCon`s, leading to `Note [Type- checking inside the knot]` in !TsHsType. If we have a form of types in `HsSyn` that occurs ''after'' typechecking, we can fix the above problems, leading both to a runtime improvement (no double-checking type declarations) and code simplification (no more typechecking in the knot). This is a significant refactor, and it should proceed in at least two stages: one for just plain types, and one for type declarations. Note that we can't produce `HsType TcTyVar`, because `Name`s in `HsType Name` sometimes become `TyCon`s and sometimes become `TcTyVar`s. We really need `HsType (TyCon + TcTyVar)` or some such. But perhaps it would be better to wait until after refactoring with respect to the Trees That Grow paper. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 01:08:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 01:08:56 -0000 Subject: [GHC] #9445: GHC Panic: Tick Exhausted with high factor In-Reply-To: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> References: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> Message-ID: <063.6a8fcc419746801f82befe3a374491f9@haskell.org> #9445: GHC Panic: Tick Exhausted with high factor -------------------------------------+------------------------------------- Reporter: adinapoli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: panic Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5539 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I've stripped it down to a small test case. Under GHC 8.0.2, this requires a tick factor somewhere between 5190 and 5210 (really). Under GHC 8.2, it compiles about as quickly as one might expect. {{{#!hs module SFML.Graphics.Transform ( Transform ) where -- | Encapsulate a 3x3 transform matrix. data Transform = Transform { m00 :: !Float, m10 :: !Float, m20 :: !Float , m01 :: !Float, m11 :: !Float, m21 :: !Float , m02 :: !Float, m12 :: !Float, m22 :: !Float } instance Num Transform where abs (Transform a00 a01 a02 a03 a04 a05 a06 a07 a08) = (Transform (abs a00) (abs a01) (abs a02) (abs a03) (abs a04) (abs a05) (abs a06) (abs a07) (abs a08)) }}} I'll install this test case so we can (hopefully) close the ticket. I am not able to test the actual package at the relevant commit (prior to https://github.com/SFML- haskell/SFML/commit/becb6c967721a77f244b3c0e3c61ac72f13d91eb) because my distribution doesn't offer all the required C libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 01:09:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 01:09:31 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error Message-ID: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is reproducible with GHC 8.0.1, 8.0.2, 8.2.1, and HEAD: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} module Bug where import Data.Coerce class MFunctor t where hoist :: (Monad m) => (forall a . m a -> n a) -> t m b -> t n b newtype TaggedTrans tag trans m a = TaggedTrans (trans m a) instance MFunctor trans => MFunctor (TaggedTrans tag trans) where hoist = coerce @(forall (m :: * -> *) (n :: * -> *) (b :: k). Monad m => (forall (a :: *). m a -> n a) -> trans m b -> trans n b) @(forall (m :: * -> *) (n :: * -> *) (b :: k). Monad m => (forall (a :: *). m a -> n a) -> TaggedTrans tag trans m b -> TaggedTrans tag trans n b) hoist }}} {{{ GHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:18:26: error: • GHC internal error: ‘k’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a1tR :-> Type variable ‘m’ = m, a1tS :-> Type variable ‘n’ = n, a1tT :-> Type variable ‘b’ = b, a1tV :-> Type variable ‘trans’ = trans, a1tW :-> Type variable ‘tag’ = tag, a1tX :-> Type variable ‘m’ = m, a1tY :-> Type variable ‘n’ = n, a1KE :-> Type variable ‘k’ = k, a1KF :-> Type variable ‘k’ = k] • In the kind ‘k’ In the type ‘(forall (m :: * -> *) (n :: * -> *) (b :: k). Monad m => (forall (a :: *). m a -> n a) -> trans m b -> trans n b)’ In the expression: coerce @(forall (m :: * -> *) (n :: * -> *) (b :: k). Monad m => (forall (a :: *). m a -> n a) -> trans m b -> trans n b) @(forall (m :: * -> *) (n :: * -> *) (b :: k). Monad m => (forall (a :: *). m a -> n a) -> TaggedTrans tag trans m b -> TaggedTrans tag trans n b) hoist | 18 | (b :: k). | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 01:12:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 01:12:42 -0000 Subject: [GHC] #9445: GHC Panic: Tick Exhausted with high factor In-Reply-To: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> References: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> Message-ID: <063.8678187e32dc30bedbff1e0047811a61@haskell.org> #9445: GHC Panic: Tick Exhausted with high factor -------------------------------------+------------------------------------- Reporter: adinapoli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: panic Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5539 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I've filed [https://github.com/SFML-haskell/SFML/issues/25 a ticket] against SFML to consider reverting their workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 01:15:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 01:15:43 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.7453d26bc733c341a5c682f102fbcc41@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's a somewhat more minimal example: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} module Bug where import Data.Coerce newtype Wrap f a = Wrap (f a) class C f where c :: f a instance C f => C (Wrap f) where c = coerce @(forall (a :: k). f a) @(forall (a :: k). C f a) c }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:15:29: error: • GHC internal error: ‘k’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a1tN :-> Type variable ‘a’ = a, a1tQ :-> Type variable ‘f’ = f, a1uU :-> Type variable ‘k’ = k] • In the kind ‘k’ In the type ‘(forall (a :: k). f a)’ In the expression: coerce @(forall (a :: k). f a) @(forall (a :: k). C f a) c | 15 | c = coerce @(forall (a :: k). f a) | }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 02:35:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 02:35:09 -0000 Subject: [GHC] #13728: Clarify the difference between NameL and NameU in Template Haskell In-Reply-To: <048.17c37a288703f66f28ee4fb551c7bfee@haskell.org> References: <048.17c37a288703f66f28ee4fb551c7bfee@haskell.org> Message-ID: <063.78bbf149af42a16aa675113472c08da3@haskell.org> #13728: Clarify the difference between NameL and NameU in Template Haskell -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * component: Core Libraries => Template Haskell Comment: It looks like `NameL`s are used when a quotation in a splice mentions an in-scope variable: {{{ f x = $(do VarE stuff <- [| x |] runIO $ putStrLn $ case stuff of Name _ (NameS {}) -> "NameS" Name _ (NameQ {}) -> "NameQ" Name _ (NameU {}) -> "NameU" Name _ (NameL {}) -> "NameL" Name _ (NameG {}) -> "NameG" [| 0 |]) }}} prints `NameL` when compiled. Yes, this should be clarified in the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 03:06:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 03:06:41 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables Message-ID: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While building profiled executables with 8.2.1rc2 I've noticed the link times seem to have significantly regressed. I don't have a minimal test case. Testing on cabal head source tree {{{ cabal --version >cabal-install version 2.1.0.0 >compiled using version 2.1.0.0 of the Cabal library cabal new-configure --enable-profiling --enable-newer --with- ghc=/opt/ghc-8.2.1/bin/ghc cabal build cabal-install # hit Ctrl-C during linking time cabal build cabal-install }}} gives real 1m54.833s user 1m52.936s sys 0m1.620s doing the same with 8.0.2 links in less than a second -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 07:19:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 07:19:02 -0000 Subject: [GHC] #13740: GHC panic with operator constructor of newtype Message-ID: <046.2588b75dce854509574dbc6f8c8d6019@haskell.org> #13740: GHC panic with operator constructor of newtype -------------------------------------+------------------------------------- Reporter: codebje | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code causes a GHC panic: {{{ newtype Cont r a = Cont { (>>-) :: (a -> r) -> r } x = \a b c -> c >>- a . b }}} This slight modification, however, is fine: {{{ newtype Cont r a = Cont { (>>-) :: (a -> r) -> r } x = \a b c -> c >>- (a . b) }}} The presence or absence of a type signature for `x` makes no difference. Compiling with "-v" suggests the panic occurs during type checking: {{{ Glasgow Haskell Compiler, Version 8.0.2, stage 2 booted by GHC version 7.10.3 Using binary package database: /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d/package.cache Using binary package database: /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb/package.cache Using binary package database: /Users/bje/.stack/global/.stack- work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb/package.cache loading package database /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d loading package database /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb loading package database /Users/bje/.stack/global/.stack- work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.1.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.1.0 wired-in package ghc mapped to ghc-8.0.2 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: loading package database /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d loading package database /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb loading package database /Users/bje/.stack/global/.stack- work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.1.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.11.1.0 wired-in package ghc mapped to ghc-8.0.2 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *panic.hs !!! Chasing dependencies: finished in 0.57 milliseconds, allocated 0.224 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2017-05-22 07:07:41 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file panic.hs *** Checking old interface for Main: [1 of 1] Compiling Main ( panic.hs, panic.o ) *** Parser [Main]: !!! Parser [Main]: finished in 0.38 milliseconds, allocated 0.209 megabytes *** Renamer/typechecker [Main]: *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): get_op >>- Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 07:32:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 07:32:32 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.3a9a6c1a48f5aaad9cbcc32a845c8a5e@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | codeGen/should_fail/T13233 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3490 Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) Comment: The panic still happens for me, with 6f8c3ce4b1. {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170522 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (a_12 :: TYPE k0_10) k0_10 Call stack: Call stack unavailable Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> compiler/ghc.mk:591: recipe for target 'compiler/stage2/build/StgCmmMonad.p_o' failed }}} My build.mk is: {{{ BuildFlavour = prof ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif STRIP_CMD = : GhcStage2HcOpts += -fprof-auto-top }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 07:42:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 07:42:48 -0000 Subject: [GHC] #13741: Newtype unwrapping causes GHC panic Message-ID: <051.8af3e5b66b30f5114df1f92070bc19bd@haskell.org> #13741: Newtype unwrapping causes GHC panic -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: newtype ghci | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Some combination of newtypes and infix operators is causing GHCi to panic. Steps to reproduce: 1. Open a fresh GHCi session. 2. Define `Cont`: `newtype Cont a r = Cont {(>>-) :: (a -> r) -> r}` 3. Define a `Functor` instance for `Cont`: `instance Functor (Cont r) where fmap f c = Cont $ \k -> c >>>- f . k` 4. Observe the following: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): get_op >>>- Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 07:45:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 07:45:44 -0000 Subject: [GHC] #13741: Newtype unwrapping causes GHC panic In-Reply-To: <051.8af3e5b66b30f5114df1f92070bc19bd@haskell.org> References: <051.8af3e5b66b30f5114df1f92070bc19bd@haskell.org> Message-ID: <066.a98cfb36babb20998f92b4eea9dbffaf@haskell.org> #13741: Newtype unwrapping causes GHC panic -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: newtype ghci 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 vaibhavsagar: @@ -19,0 +19,4 @@ + + Discovered + [https://www.reddit.com/r/haskell/comments/6clkgs/discovering_continuations_with_typed_holes/dhvluoq/ + here]. New description: Some combination of newtypes and infix operators is causing GHCi to panic. Steps to reproduce: 1. Open a fresh GHCi session. 2. Define `Cont`: `newtype Cont a r = Cont {(>>-) :: (a -> r) -> r}` 3. Define a `Functor` instance for `Cont`: `instance Functor (Cont r) where fmap f c = Cont $ \k -> c >>>- f . k` 4. Observe the following: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): get_op >>>- Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Discovered [https://www.reddit.com/r/haskell/comments/6clkgs/discovering_continuations_with_typed_holes/dhvluoq/ here]. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 08:38:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 08:38:31 -0000 Subject: [GHC] #13741: Newtype unwrapping causes GHC panic In-Reply-To: <051.8af3e5b66b30f5114df1f92070bc19bd@haskell.org> References: <051.8af3e5b66b30f5114df1f92070bc19bd@haskell.org> Message-ID: <066.233093758570cb90eacfc2b849befee9@haskell.org> #13741: Newtype unwrapping causes GHC panic -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: newtype ghci 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 vaibhavsagar: @@ -6,1 +6,1 @@ - 2. Define `Cont`: `newtype Cont a r = Cont {(>>-) :: (a -> r) -> r}` + 2. Define `Cont`: `newtype Cont r a = Cont {(>>-) :: (a -> r) -> r}` New description: Some combination of newtypes and infix operators is causing GHCi to panic. Steps to reproduce: 1. Open a fresh GHCi session. 2. Define `Cont`: `newtype Cont r a = Cont {(>>-) :: (a -> r) -> r}` 3. Define a `Functor` instance for `Cont`: `instance Functor (Cont r) where fmap f c = Cont $ \k -> c >>>- f . k` 4. Observe the following: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): get_op >>>- Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Discovered [https://www.reddit.com/r/haskell/comments/6clkgs/discovering_continuations_with_typed_holes/dhvluoq/ here]. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 10:47:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 10:47:30 -0000 Subject: [GHC] #13740: GHC panic with operator constructor of newtype In-Reply-To: <046.2588b75dce854509574dbc6f8c8d6019@haskell.org> References: <046.2588b75dce854509574dbc6f8c8d6019@haskell.org> Message-ID: <061.9a6f40f84c9b000b141f88b6e5e89083@haskell.org> #13740: GHC panic with operator constructor of newtype -------------------------------------+------------------------------------- Reporter: codebje | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 13741 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by codebje): * related: => 13741 Comment: Duplicated in https://ghc.haskell.org/trac/ghc/ticket/13741#ticket. The issue is not triggered if precedence and fixity are assigned: {{{ infixl 5 >>- -- any precedence and fixity works newtype Cont r a = Cont { (>>-) :: (a -> r) -> r } x = \a b c -> c >>- a . b }}} Other infix operators in place of `.` don't seem to cause the same problem, but that's not an exhaustive check! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 10:51:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 10:51:10 -0000 Subject: [GHC] #13740: GHC panic with operator constructor of newtype In-Reply-To: <046.2588b75dce854509574dbc6f8c8d6019@haskell.org> References: <046.2588b75dce854509574dbc6f8c8d6019@haskell.org> Message-ID: <061.719bf2bc7bffe263944d5822a6b85006@haskell.org> #13740: GHC panic with operator constructor of newtype -------------------------------------+------------------------------------- Reporter: codebje | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13741, #13132 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate * related: 13741 => #13741, #13132 Comment: I tried this and it is fixed in 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 10:51:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 10:51:44 -0000 Subject: [GHC] #13741: Newtype unwrapping causes GHC panic In-Reply-To: <051.8af3e5b66b30f5114df1f92070bc19bd@haskell.org> References: <051.8af3e5b66b30f5114df1f92070bc19bd@haskell.org> Message-ID: <066.b003036215dc9d4e2094b48abad21734@haskell.org> #13741: Newtype unwrapping causes GHC panic -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: newtype ghci Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13132 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate * related: => #13132 Comment: See #13132 Fixed in 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 11:52:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 11:52:51 -0000 Subject: [GHC] #9700: Support C structures in Haskell FFI In-Reply-To: <044.596a97e8d8f649bed4fc2b5d38a5701e@haskell.org> References: <044.596a97e8d8f649bed4fc2b5d38a5701e@haskell.org> Message-ID: <059.4a9facf427518f1b7fae93bacee22518@haskell.org> #9700: Support C structures in Haskell FFI -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D252 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Yuras): Replying to [comment:6 sboosali]: > any update? I'm afraid this proposal is dead. [https://github.com/Yuras/ghc/commits /cmm-cstruct Here] is the code rebased over ghc-8.0 in case anyone wants to take it over. If you are interested to push it forward, then I'd suggest to open new [https://github.com/ghc-proposals/ghc-proposals GHC proposal]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 14:32:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 14:32:33 -0000 Subject: [GHC] #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException In-Reply-To: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> References: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> Message-ID: <065.d15840ae4eac02305461b2898dcd53c1@haskell.org> #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by svenpanne): OpenGL-related stuff heavily depends on thread-local state by design, so it is crucial that there are no hidden thread migrations etc. behind the scenes. Has there been some change in that area? I'm quite sure that this worked in the past, both in compiled form and within GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 15:13:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 15:13:59 -0000 Subject: [GHC] #13719: checkFamInstConsistency dominates compile time In-Reply-To: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> References: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> Message-ID: <061.fd9c21c3b3f29e6fbc9ae5d89f9d1d5e@haskell.org> #13719: checkFamInstConsistency dominates compile time -------------------------------------+------------------------------------- Reporter: niteria | 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: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13092, #13099, | Differential Rev(s): phab:D3600, #12191 | phab:D3602 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * differential: phab:D3600 => phab:D3600, phab:D3602 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 15:50:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 15:50:09 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.ea7e6b17d414c681ebe72332028c0a8a@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3569 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d6686a254293442a633482eae7ca78be968bef58/ghc" d6686a25/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d6686a254293442a633482eae7ca78be968bef58" Ensure package.cache is newer than registration files after make install Rebuild package.cache to ensure that it's newer than the package database registration files, avoiding out-of-date cache warnings from ghc-pkg. See #13375. Test Plan: `make install`, run `ghc-pkg list`, look for out-of-date cache warning Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #13375 Differential Revision: https://phabricator.haskell.org/D3569 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 15:55:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 15:55:29 -0000 Subject: [GHC] #9445: GHC Panic: Tick Exhausted with high factor In-Reply-To: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> References: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> Message-ID: <063.71e6c8b88e06b6a03f805fb31b11add2@haskell.org> #9445: GHC Panic: Tick Exhausted with high factor -------------------------------------+------------------------------------- Reporter: adinapoli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: panic Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5539 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's great that this one has been fixed. Thank you for adding a test case in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 16:09:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 16:09:04 -0000 Subject: [GHC] #13734: Code requires ScopedTypeVariables, possibly erroneously In-Reply-To: <051.67da3ed2a81909933d3bc41a04f15152@haskell.org> References: <051.67da3ed2a81909933d3bc41a04f15152@haskell.org> Message-ID: <066.e1c3a5677fc8ebe95d868442af54d1fe@haskell.org> #13734: Code requires ScopedTypeVariables, possibly erroneously -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Without `ScopedTypeVariables` the type variables mentioned in are, well, not in scope. (As specified in the Haskell 2010 report.) We get {{{ T13734.hs:16:18: error: Not in scope: type variable ‘a’ | 16 | size _ = size @a + size @b | ^ }}} So I agree with Ryan. Please re-open if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 16:15:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 16:15:18 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms In-Reply-To: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> References: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> Message-ID: <066.fc4103227dda1e1c7eba4fc8d31b7d4b@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Re comment:1, it's unsurprising that {{{ llam f = L (Lam f) }}} with no type signature, does not work. Because `f` needs to have a polytype, and it won't without a type sig. But re the original Description, I agree that the bidirectional definition should go through. I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 16:19:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 16:19:49 -0000 Subject: [GHC] #13731: DeriveFunctor and friends don't understand type families In-Reply-To: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> References: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> Message-ID: <065.2ada11a8ace273a8e42b8a295d0b092b@haskell.org> #13731: DeriveFunctor and friends don't understand type families -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The error message is terrible. (Ryan might you look at that?) But the program IS wrong. In Haskell you can't write {{{ f (xs ++ ys) = ... }}} which pattern-matches on a function call. And similarly at the type level you can't pattern match on a function call, as in `instance Functor (Test ListExtension)`. Instead write `instance Functor []`. Oh! We have that instance already; so you can just omit it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 16:21:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 16:21:16 -0000 Subject: [GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 Message-ID: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple ConstraintKinds, KindSignatures | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached module compiles without errors with GHC 8.0.1 but needs an explicit kind signature with GHC 8.2.1-rc2. Mentioned in this [https://mail.haskell.org/pipermail/ghc- devs/2017-May/014222.html ghc-dev thread]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 16:22:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 16:22:05 -0000 Subject: [GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 In-Reply-To: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> References: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> Message-ID: <062.bdcf6ca73e339dacf9715e264d296b42@haskell.org> #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | ConstraintKinds, KindSignatures 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 albertov): * Attachment "CKBug.hs" added. This module reproduces the bug without third-party dependencies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 16:27:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 16:27:14 -0000 Subject: [GHC] #13733: Simplify constraints on RULES LHS In-Reply-To: <046.c1818a7fbd77b52e8b57f0d827738261@haskell.org> References: <046.c1818a7fbd77b52e8b57f0d827738261@haskell.org> Message-ID: <061.17e0fda197ee0e0d7e9c572f4fe1bcb0@haskell.org> #13733: Simplify constraints on RULES LHS -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | 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): The problem is that the built-in rule that rewrites {{{ GHC.Classes.$fEq[] @ Integer GHC.Integer.Type.$fEqInteger ----> GHC.Classes.$fEq[]_$c== @ Integer GHC.Integer.Type.$fEqInteger }}} is firing before your user-defined rule has a chance to fire. The basic problem is that two overlapping rules are competing, and it's a fluke which "wins". Monkeying around with solving constraints on rule LHSs might be a sticking plaster, but it won't tackle the underlying issue. Possible solution: make the built-in rule fire in phase 2,1,0, but not in the initial "gentle" phase. Of course, ''not'' firing the built-in class-op rule means that other things won't happen as early as they otherwise might, so I don't know what the knock-on effects might be. But I think this is the path to follow if you want to pursue this. Something similar happens for the inlining for data constructor wrappers. I'm sure there is a ticket about this stuff already. Maybe more than one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 16:41:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 16:41:31 -0000 Subject: [GHC] #1: Implicit parameters cause strange behavi In-Reply-To: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> References: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> Message-ID: <060.576771e25e1d3f942551e65accb0f2c1@haskell.org> #1: Implicit parameters cause strange behavi --------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.0 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Comment (by Ben Gamari ): In [changeset:"83ee930fdd125d74939307ed3fa1bf6a2ba7fb36/ghc" 83ee930f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="83ee930fdd125d74939307ed3fa1bf6a2ba7fb36" fix a memory leak in osNumaMask got an error when using asan: ``` ==1866689==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x10640568 in malloc ??:? #1 0x154d867e in numa_bitmask_alloc .../numactl-2.0.8/libnuma_nosymve r.c:204 #2 0x154d867e in numa_allocate_nodemask .../numactl-2.0.8/libnuma_nosymve r.c:724 #3 0x154d867e in numa_get_mems_allowed .../numactl-2.0.8/libnuma_nosymve r.c:1141 #4 0x10b54a45 in osNumaMask ...ghc-8.0.2/rts/posix/OSMem.c:59 8 ``` Test Plan: compile, validate Reviewers: simonmar, niteria, austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3537 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 16:41:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 16:41:31 -0000 Subject: [GHC] #2: rewrite rules, forall, no -fglasgow-exts In-Reply-To: <045.06ea7a403df37fa1d474136f4bf6bb53@haskell.org> References: <045.06ea7a403df37fa1d474136f4bf6bb53@haskell.org> Message-ID: <060.9cbddd7cfec8e4ad80aa463773c8d2e5@haskell.org> #2: rewrite rules, forall, no -fglasgow-exts -------------------------------------+---------------------- Reporter: nobody | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: None Resolution: Fixed | Keywords: Type of failure: None/Unknown | -------------------------------------+---------------------- Changes (by Ben Gamari ): * failure: => None/Unknown Comment: In [changeset:"83ee930fdd125d74939307ed3fa1bf6a2ba7fb36/ghc" 83ee930f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="83ee930fdd125d74939307ed3fa1bf6a2ba7fb36" fix a memory leak in osNumaMask got an error when using asan: ``` ==1866689==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x10640568 in malloc ??:? #1 0x154d867e in numa_bitmask_alloc .../numactl-2.0.8/libnuma_nosymve r.c:204 #2 0x154d867e in numa_allocate_nodemask .../numactl-2.0.8/libnuma_nosymve r.c:724 #3 0x154d867e in numa_get_mems_allowed .../numactl-2.0.8/libnuma_nosymve r.c:1141 #4 0x10b54a45 in osNumaMask ...ghc-8.0.2/rts/posix/OSMem.c:59 8 ``` Test Plan: compile, validate Reviewers: simonmar, niteria, austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3537 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 16:41:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 16:41:32 -0000 Subject: [GHC] #4: -fext-core -fno-core behaves funny In-Reply-To: <045.ae3f8b0e845fade77535d5ec02817b6a@haskell.org> References: <045.ae3f8b0e845fade77535d5ec02817b6a@haskell.org> Message-ID: <060.e3e6bcc00c966ec2d436d0296e703f14@haskell.org> #4: -fext-core -fno-core behaves funny --------------------------------+-------------------- Reporter: josefs | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: None Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Changes (by Ben Gamari ): * failure: => None/Unknown Comment: In [changeset:"83ee930fdd125d74939307ed3fa1bf6a2ba7fb36/ghc" 83ee930f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="83ee930fdd125d74939307ed3fa1bf6a2ba7fb36" fix a memory leak in osNumaMask got an error when using asan: ``` ==1866689==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x10640568 in malloc ??:? #1 0x154d867e in numa_bitmask_alloc .../numactl-2.0.8/libnuma_nosymve r.c:204 #2 0x154d867e in numa_allocate_nodemask .../numactl-2.0.8/libnuma_nosymve r.c:724 #3 0x154d867e in numa_get_mems_allowed .../numactl-2.0.8/libnuma_nosymve r.c:1141 #4 0x10b54a45 in osNumaMask ...ghc-8.0.2/rts/posix/OSMem.c:59 8 ``` Test Plan: compile, validate Reviewers: simonmar, niteria, austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3537 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 16:41:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 16:41:31 -0000 Subject: [GHC] #3: DiffArray should be instance of Show In-Reply-To: <047.3d7bfcea6c6c5eaaf4a369a972367c38@haskell.org> References: <047.3d7bfcea6c6c5eaaf4a369a972367c38@haskell.org> Message-ID: <062.ea73508672e16d85f087a6a99d9de7e0@haskell.org> #3: DiffArray should be instance of Show --------------------------------+-------------------- Reporter: magunter | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: hslibs/lang | Version: 5.0 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Changes (by Ben Gamari ): * failure: => None/Unknown Comment: In [changeset:"83ee930fdd125d74939307ed3fa1bf6a2ba7fb36/ghc" 83ee930f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="83ee930fdd125d74939307ed3fa1bf6a2ba7fb36" fix a memory leak in osNumaMask got an error when using asan: ``` ==1866689==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x10640568 in malloc ??:? #1 0x154d867e in numa_bitmask_alloc .../numactl-2.0.8/libnuma_nosymve r.c:204 #2 0x154d867e in numa_allocate_nodemask .../numactl-2.0.8/libnuma_nosymve r.c:724 #3 0x154d867e in numa_get_mems_allowed .../numactl-2.0.8/libnuma_nosymve r.c:1141 #4 0x10b54a45 in osNumaMask ...ghc-8.0.2/rts/posix/OSMem.c:59 8 ``` Test Plan: compile, validate Reviewers: simonmar, niteria, austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3537 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 16:41:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 16:41:32 -0000 Subject: [GHC] #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules In-Reply-To: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> References: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> Message-ID: <057.3d5ccbdadffa1bdfe50c149e79fbba32@haskell.org> #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules -------------------------------------+------------------------------------- Reporter: hvr | Owner: Yuras Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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): Phab:D3598 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"dac49bdc79387ca9f91c7c5c9220699efb6239fb/ghc" dac49bd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dac49bdc79387ca9f91c7c5c9220699efb6239fb" Handle file targets in missing home modules warning When main module is listed on command line as a file, we should not issue a warning about it. See Trac #13727 Reviewers: austin, bgamari, Yuras Reviewed By: bgamari, Yuras Subscribers: 23Skidoo, rwbarton, thomie GHC Trac Issues: #13727 Differential Revision: https://phabricator.haskell.org/D3598 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 16:41:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 16:41:32 -0000 Subject: [GHC] #13719: checkFamInstConsistency dominates compile time In-Reply-To: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> References: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> Message-ID: <061.943f6f210383aeab62293b04c2ab2c05@haskell.org> #13719: checkFamInstConsistency dominates compile time -------------------------------------+------------------------------------- Reporter: niteria | 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: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13092, #13099, | Differential Rev(s): phab:D3600, #12191 | phab:D3602 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"17fef390c575c153c7e70438783e7f8fee62e451/ghc" 17fef39/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17fef390c575c153c7e70438783e7f8fee62e451" Testcase for #13719 I expect to improve this, a testcase will ensure it doesn't regress. Test Plan: ./validate Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13719 Differential Revision: https://phabricator.haskell.org/D3600 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 16:41:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 16:41:32 -0000 Subject: [GHC] #13718: diagnostic colors: differentiate between message head and message body In-Reply-To: <044.d0c2ce3e08b76e30b998d2f85762a984@haskell.org> References: <044.d0c2ce3e08b76e30b998d2f85762a984@haskell.org> Message-ID: <059.6ffe440a2b37553ebc43fd707b5e5c88@haskell.org> #13718: diagnostic colors: differentiate between message head and message body -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13444 | Differential Rev(s): phab:D3599 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"139ef04bdbd14b74dd6202295e11a37295442fc8/ghc" 139ef04b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="139ef04bdbd14b74dd6202295e11a37295442fc8" Add "header" to GHC_COLORS Add "header" to GHC_COLORS and allow colors to be inherited from the surroundings. Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13718 Differential Revision: https://phabricator.haskell.org/D3599 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 16:41:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 16:41:32 -0000 Subject: [GHC] #13719: checkFamInstConsistency dominates compile time In-Reply-To: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> References: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> Message-ID: <061.cc164280f1b7639329063ad7f1caffec@haskell.org> #13719: checkFamInstConsistency dominates compile time -------------------------------------+------------------------------------- Reporter: niteria | 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: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13092, #13099, | Differential Rev(s): phab:D3600, #12191 | phab:D3602 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2bc3a0570dac333cc7fb6f8038e08f36d62e4d13/ghc" 2bc3a057/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2bc3a0570dac333cc7fb6f8038e08f36d62e4d13" Testcase for type family consistency checks Based on my quick search, we don't have a test that verifies that we check the type family instances of currently compiled module against direct or indirect dependencies. This adds two tests: for a direct dependency and for an indirect dependency. I also added a comment to make it clear what the 'Over' test tests. Other than completeness, it makes sense to have these tests because if you look at Note [The type family instance consistency story] in FamInsts these cases are checked through different mechanisms. Test Plan: new tests Reviewers: simonmar, rwbarton, simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie GHC Trac Issues: #13719 Differential Revision: https://phabricator.haskell.org/D3602 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 17:07:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 17:07:55 -0000 Subject: [GHC] #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException In-Reply-To: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> References: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> Message-ID: <065.631cf58476805e2f06f2da849f88f785@haskell.org> #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Changes (by bgamari): * cc: Jaffacake (added) Comment: I don't believe anything has changed; as far as I know ghc I has always treated unsafe calls as safe. See #8281 where this was recently discussed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 17:42:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 17:42:27 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.05310b9db3224520ae6aae604a0be2b7@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13629 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 17:42:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 17:42:41 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.ba730e8a270b2375b715a676e7474485@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 17:52:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 17:52:58 -0000 Subject: [GHC] #13731: DeriveFunctor and friends don't understand type families In-Reply-To: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> References: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> Message-ID: <065.e54eb7265685cfec113eebbc084fa66e@haskell.org> #13731: DeriveFunctor and friends don't understand type families -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): What would you rather the error message say? I do think the phrase "the type variable" is unfortunate, as it should rather be "the //last// type variable" (since there can be more than one). But other than that, it's pretty spot-on: if you're using the last type variable within another type, it must be a data type, and `ExtensionType` is not a data type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 18:01:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 18:01:47 -0000 Subject: [GHC] #13743: Colourise command output Message-ID: <051.41e540f3ba1bbaf7e0918d0f79f0c13f@haskell.org> #13743: Colourise command output -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Our error messages are now colourful (#10073), can we do the same for the output of commands like `:info`? `:info` has gotten bloated (I also think the context / instance head should be swapped, but that's another story), adding colour would make it easier to read {{{#!html
 >>> :i Int
 data Int = I# E.Int#
 -- Defined in ‘GHC.Types’
instance Eq Int -- Defined in ‘GHC.Classes’ instance Ord Int -- Defined in ‘GHC.Classes’ instance Show Int -- Defined in ‘GHC.Show’ instance Read Int -- Defined in ‘GHC.Read’ instance Enum Int -- Defined in ‘GHC.Enum’ instance Num Int -- Defined in ‘GHC.Num’ instance Real Int -- Defined in ‘GHC.Real’ instance [safe] NFData Int -- Defined in ‘Control.DeepSeq’ instance Data Int -- Defined in ‘Data.Data’ instance Bounded Int -- Defined in ‘GHC.Enum’ instance O.Outputable Int -- Defined in ‘Outputable’ instance [safe] PrintfArg Int -- Defined in ‘Text.Printf’ instance Integral Int -- Defined in ‘GHC.Real’
}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 18:11:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 18:11:34 -0000 Subject: [GHC] #13743: Colourise command output In-Reply-To: <051.41e540f3ba1bbaf7e0918d0f79f0c13f@haskell.org> References: <051.41e540f3ba1bbaf7e0918d0f79f0c13f@haskell.org> Message-ID: <066.31e07b8dffbc638ee43dae6e51d47761@haskell.org> #13743: Colourise command output -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): TODO create a command to get a simplified output {{{#!html
 >>> :sinfo Int
 data Int = I# E.Int#
 Eq         Int
 Ord        Int
 Show       Int
 Read       Int
 Enum       Int
 Num        Int
 Real       Int
 NFData     Int
 Data       Int
 Bounded    Int
 Outputable Int
 PrintfArg  Int
 Integral   Int
 
}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 18:51:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 18:51:06 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.8a0e792f5a94e984fef29d7e0a19c7ab@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bollu Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12143 Related Tickets: #13309 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AaronFriel): A user ElvishJerricco on Reddit posted an interesting test case ([[https://www.reddit.com/r/haskell/comments/6c7hen/applicativedo_overhaul_request_for_comments/dhw9po0/?context=3|my analysis here]]). There were two interesting things that popped out. Here's the reduced test case: {{{#!hs {-# LANGUAGE ApplicativeDo #-} foo :: Monad f => f () -> f () foo f = f bar :: Monad f => f () -> f () bar f = do _ <- f foo f }}} Clearly the two statements of `bar` are independent, and so we should use `*>` here too. The interesting thing to me is that this doesn't trigger the `ApplicativeDo` desugaring at all! The desugarer outputs: `bar = f >>= \_ -> foo f`. So this is another thing to make sure my revised rules cover. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 18:55:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 18:55:51 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.835a2137b008e3efd0efe97709d4ab81@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1287 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Possible use-case #13731 {{{#!hs type family ExtensionType ext a = res | res -> ext a data ListExtension type instance ExtensionType ListExtension a = [a] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 18:58:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 18:58:42 -0000 Subject: [GHC] #13731: DeriveFunctor and friends don't understand type families In-Reply-To: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> References: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> Message-ID: <065.d863e2fd5a8d5c082bf587bf467a1d1b@haskell.org> #13731: DeriveFunctor and friends don't understand type families -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): That instance becomes writable if we mark `ExtensionType` injective {{{#!hs data Test :: Type -> Type -> Type where Foo :: a -> Test ext a Extend :: ExtensionType ext a -> Test ext a type family ExtensionType a = (res :: Type -> Type) | res -> a data ListExtension type instance ExtensionType ListExtension = [] instance Functor (ExtensionType ext) => Functor (Test ext) where fmap :: (a -> a') -> (Test ext a -> Test ext a') fmap f = \case Foo a -> Foo (f a) Extend ex -> Extend (fmap f ex) }}} We need to bump the arity of `ExtensionType` down to one, given that we don't have #10832. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 19:00:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 19:00:47 -0000 Subject: [GHC] #8272: testing if SpLim=$rbp and Sp=$rsp changed performance at all In-Reply-To: <045.ecd7af4f53d7df1147bf6a068ec1e485@haskell.org> References: <045.ecd7af4f53d7df1147bf6a068ec1e485@haskell.org> Message-ID: <060.e787d54a8e7a78d68227bd02c9e2aee5@haskell.org> #8272: testing if SpLim=$rbp and Sp=$rsp changed performance at all -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | callingConvention Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: simonmar, rwbarton (added) Comment: There's been an interesting discussion about this in: https://github.com/ghc-proposals/ghc-proposals/pull/17 If people still think this would be a good idea, I'd like to try things out. But I need some help to get started. :) First question. It seems to me that there are two slightly different ideas here: 1) using `%rsp` for managing the Haskell stack (instead of `%rbp`) 2) using `call`/`ret` Is 1) really a strict requirement for 2)? IIUC we're already using C-stack (`%rsp`) for spilling things during register allocation. The only problem I can think of is the amount of space for those return addresses. Am I missing something else or is this enough to prevent us from using `call`/`ret`? (also, somewhat related, wouldn't using `call`/`ret` allow us to get rid of proc-point splitting for LLVM?) Second question. For every `CmmCall` that contains `cml_cont` we'd need to compile this into two instructions: `call` and `jmp ` (to jump over the info table that preceeds the block where we want to return to). But that means that the return address no longer points to the info table. Does anything else depend on this? Is there some easy way to check that? Third question. How could this work in LLVM backend? I don't think LLVM even allows direct manipulation of the stack pointer. Also, even if we could manipulate it, I wouldn't be surprised if LLVM wanted to move things around the stack, which again sounds pretty problematic (for, e.g., GC) PS. CCing simonmar and rwbarton since they were the main contributors to the linked GHC proposal. (hope you don't mind!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 19:22:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 19:22:16 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.1bce4e761c95a1211bbc3753c3a4fb58@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3569 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 4ea0868737cfce7051bc10a731d5de152c93fde5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 19:22:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 19:22:21 -0000 Subject: [GHC] #13744: Compile-time regression in 8.2 when compiling bloodhound's test suite Message-ID: <045.7ecb20ffade767f887f3581e5bd15ca2@haskell.org> #13744: Compile-time regression in 8.2 when compiling bloodhound's test suite -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- GHC 8.2 takes much longer to compile bloodhound's test suite than GHC 8.0.2. With 8.0.2, compilation takes approximately a minute on my machine, 8.2 takes approximately four minutes and uses much more memory. How to reproduce: {{{ $ git clone -b ghc-8.2 https://github.com/23Skidoo/bloodhound.git $ cd bloodhound $ cabal new-build -w ghc-8.0.1 --enable-tests $ cabal new-build -w ghc-8.2.1 --enable-tests }}} GHC version: {{{ $ ghc-8.2.1 --version The Glorious Glasgow Haskell Compilation System, version 8.2.0.20170505 }}} These warnings (fixed in my `ghc-8.2` branch of `bloodhound`) may provide a clue to what's happening: {{{ tests/V1/tests.hs:1876:17: warning: [-Wsimplifiable-class-constraints] • The constraint ‘SOP.All SOP.SListI (SOP.GCode a)’ matches an instance declaration instance forall k (f :: k -> Constraint) (xs :: [k]). (Generics.SOP.Constraint.AllF f xs, SOP.SListI xs) => SOP.All f xs -- Defined in ‘Generics.SOP.Constraint’ This makes type inference for inner bindings fragile; either use MonoLocalBinds, or simplify it using the instance • In the type signature: sopArbitrary :: forall a. (Generic a, SOP.GTo a, SOP.All SOP.SListI (SOP.GCode a), SOP.All2 Arbitrary (SOP.GCode a)) => Gen a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 19:22:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 19:22:32 -0000 Subject: [GHC] #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules In-Reply-To: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> References: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> Message-ID: <057.0ce9ebd6d0f1175c4f1b9dd69de8a9bd@haskell.org> #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules -------------------------------------+------------------------------------- Reporter: hvr | Owner: Yuras Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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): Phab:D3598 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.2` as 72eade6d7cf47f0738a58f560085acc952248d2c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 19:23:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 19:23:03 -0000 Subject: [GHC] #13718: diagnostic colors: differentiate between message head and message body In-Reply-To: <044.d0c2ce3e08b76e30b998d2f85762a984@haskell.org> References: <044.d0c2ce3e08b76e30b998d2f85762a984@haskell.org> Message-ID: <059.415868cbe95fda3df6397e29653e857a@haskell.org> #13718: diagnostic colors: differentiate between message head and message body -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13444 | Differential Rev(s): phab:D3599 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Merged to `ghc-8.2` as c0b82c3826c8e1b26d198f050baa9d5077370247 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 19:37:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 19:37:23 -0000 Subject: [GHC] #13743: Colourise command output In-Reply-To: <051.41e540f3ba1bbaf7e0918d0f79f0c13f@haskell.org> References: <051.41e540f3ba1bbaf7e0918d0f79f0c13f@haskell.org> Message-ID: <066.c4263909fc87fb46a43379e354443502@haskell.org> #13743: Colourise command output -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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: #8809 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #8809 Comment: #8809 is perhaps relevant here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 19:43:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 19:43:09 -0000 Subject: [GHC] #13743: Colourise command output In-Reply-To: <051.41e540f3ba1bbaf7e0918d0f79f0c13f@haskell.org> References: <051.41e540f3ba1bbaf7e0918d0f79f0c13f@haskell.org> Message-ID: <066.ad5cba264f28177a982faf4b9bef55fb@haskell.org> #13743: Colourise command output -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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: #8809 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In general I think we should be careful in how we approach colorization in the compiler. I fear that adding a bunch of special cases will easily snowball into an unmaintainable mess as more and more users try to get their favorite case into the tree. We are already beginning to see this with requests like #13718. I would much rather have a general mechanism for integrating with GHCi, allowing users to more easily extend and customize its functionality. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 20:01:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 20:01:31 -0000 Subject: [GHC] #13719: checkFamInstConsistency dominates compile time In-Reply-To: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> References: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> Message-ID: <061.309fbe5cfaf4375d135a17661a662e0a@haskell.org> #13719: checkFamInstConsistency dominates compile time -------------------------------------+------------------------------------- Reporter: niteria | 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: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13092, #13099, | Differential Rev(s): phab:D3600, #12191 | phab:D3602, phab:D3603 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * differential: phab:D3600, phab:D3602 => phab:D3600, phab:D3602, phab:D3603 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 20:14:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 20:14:06 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.5d8b547534cac4340875ed0d38d8ab51@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13719 | Differential Rev(s): Phab:D2992, Wiki Page: | Phab: D3603 -------------------------------------+------------------------------------- Changes (by niteria): * differential: Phab:D2992 => Phab:D2992, Phab: D3603 * related: => #13719 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 20:17:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 20:17:20 -0000 Subject: [GHC] #13743: Colourise command output In-Reply-To: <051.41e540f3ba1bbaf7e0918d0f79f0c13f@haskell.org> References: <051.41e540f3ba1bbaf7e0918d0f79f0c13f@haskell.org> Message-ID: <066.87470461f13b4553658c761ee06480f2@haskell.org> #13743: Colourise command output -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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: #8809 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -9,1 +9,1 @@ -
+ 

New description:

 Our error messages are now colourful (#10073), can we do the same for the
 output of commands like `:info`?

 `:info` has gotten bloated (I also think the context / instance head
 should be swapped, but that's another story), adding colour would make it
 easier to read

 {{{#!html
 
 >>> :i Int
 data Int = I# E.Int#
 -- Defined in ‘GHC.Types’
instance Eq Int -- Defined in ‘GHC.Classes’ instance Ord Int -- Defined in ‘GHC.Classes’ instance Show Int -- Defined in ‘GHC.Show’ instance Read Int -- Defined in ‘GHC.Read’ instance Enum Int -- Defined in ‘GHC.Enum’ instance Num Int -- Defined in ‘GHC.Num’ instance Real Int -- Defined in ‘GHC.Real’ instance [safe] NFData Int -- Defined in ‘Control.DeepSeq’ instance Data Int -- Defined in ‘Data.Data’ instance Bounded Int -- Defined in ‘GHC.Enum’ instance O.Outputable Int -- Defined in ‘Outputable’ instance [safe] PrintfArg Int -- Defined in ‘Text.Printf’ instance Integral Int -- Defined in ‘GHC.Real’
}}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 20:48:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 20:48:54 -0000 Subject: [GHC] #8272: testing if SpLim=$rbp and Sp=$rsp changed performance at all In-Reply-To: <045.ecd7af4f53d7df1147bf6a068ec1e485@haskell.org> References: <045.ecd7af4f53d7df1147bf6a068ec1e485@haskell.org> Message-ID: <060.ca1de8b412d2aa575e0b30c651887651@haskell.org> #8272: testing if SpLim=$rbp and Sp=$rsp changed performance at all -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | callingConvention Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In my view (1) is really the more interesting change as it enables use of native profiling tools. Currently we are essentially unable to use systems' native profiling tools to collect callstacks (e.g. `perf record --callgraph`) since they generally assume that the callstack is tracked by `%rsp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 21:05:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 21:05:03 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 Message-ID: <046.b7de3eed99bc2dfd75756f4f73799d3c@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.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- hvr [[https://mail.haskell.org/pipermail/ghc- devs/2017-May/014208.html|points out]] that GHC 8.2 takes significantly longer to compile `regex-tdfa-1.2.2` than 8.0.2. Interestingly, it seems that compiler allocations fell dramatically while compilation time rose. {{{ GHC 8.0.2: <> GHC 8.2.1: <> }}} == Reproducing == {{{ $ cabal unpack regex-tdfa-1.2.2 $ cd regex-tdfa-1.2.2 $ cabal install --only-dependencies $ cabal configure $ cabal build $ time ghc -idist/build/autogen -O2 Text/Regex/TDFA.hs \ -XMagicHash -XFlexibleInstances -XMultiParamTypeClasses \ -XRecursiveDo -XBangPatterns -XRankNTypes -XUnboxedTuples \ -XFlexibleContexts -XUnliftedFFITypes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 21:10:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 21:10:52 -0000 Subject: [GHC] #13733: Simplify constraints on RULES LHS In-Reply-To: <046.c1818a7fbd77b52e8b57f0d827738261@haskell.org> References: <046.c1818a7fbd77b52e8b57f0d827738261@haskell.org> Message-ID: <061.a65715609fee6c3b6bd42a71af49e981@haskell.org> #13733: Simplify constraints on RULES LHS -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | 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): Another view is that the problem is that the user cannot even specify the desired rule, namely one that matches {{{ GHC.Classes.$fEq[]_$c== @ Integer GHC.Integer.Type.$fEqInteger }}} and maybe the problem should be attacked from this angle. There is precedent in the way `coerce` works on the LHS of a rule: If it appears on the LHS, the compiler assumes the user wants to match any Core- level cast (`x |> c`), and thus inlines `coerce`, and even changes the free variable of the rule so that it can match unlifted coercions (see Note [Getting the map/coerce RULE to work]). In that sense, solving constraints on the LHS is not really monkeying or a plaster, but it is what what we have to do to allow the user to write rules that match a specific instance method. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 21:38:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 21:38:14 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.ee9012bc15dbe0e8eb2d155c12ebf567@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): What `cabal` commit are you looking at? I tried building b3af711a492970718d31ffdc46d31110109ddc42 but was unable to reproduce this. Link times are long (`real 0m5.947s user 0m0.028s sys 0m5.909s`) but nothing like you report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 21:51:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 21:51:58 -0000 Subject: [GHC] #13746: Typeable changes in base-4.10 break ChasingBottoms's test suite Message-ID: <045.32f3840a089a8e740875e5633a95d4d2@haskell.org> #13746: Typeable changes in base-4.10 break ChasingBottoms's test suite -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.1-rc2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiled against base-4.10, `ChasingBottoms`'s test suite fails with: {{{ Approx: ChasingBottomsTestSuite: typeRepTyCon: FunTy CallStack (from HasCallStack): error, called at libraries/base/Data/Typeable/Internal.hs:308:33 in base:Data.Typeable.Internal }}} This is due to the use of `error` in the following function in [https://github.com/ghc/ghc/blob/master/libraries/base/Data/Typeable/Internal.hs#L308 `Data.Typeable.Internal`]: {{{#!hs -- | Observe the type constructor of a type representation typeRepTyCon :: TypeRep a -> TyCon typeRepTyCon (TrTyCon _ tc _) = tc typeRepTyCon (TrApp _ a _) = typeRepTyCon a typeRepTyCon (TrFun _ _ _) = error "typeRepTyCon: FunTy" -- TODO }}} `ChasingBottoms`'s test suite works fine when compiled with GHC 8.0.2. It seems to me that the change in behaviour constitutes a bug or a breaking change (for which there is no mention in the changelog). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 22:00:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 22:00:00 -0000 Subject: [GHC] #13733: Simplify constraints on RULES LHS In-Reply-To: <046.c1818a7fbd77b52e8b57f0d827738261@haskell.org> References: <046.c1818a7fbd77b52e8b57f0d827738261@haskell.org> Message-ID: <061.82dffbb7811e97abdec0f2af32991d66@haskell.org> #13733: Simplify constraints on RULES LHS -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | 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): > user cannot even specify the desired rule, Certainly you can! {{{ isntance Eq T where (==) = eqT eqT :: T -> T -> T {-# NOINLINE [1] eqT #-} {-# RULES eqT x x = True #-} }}} All fine! I have no clear understanding of what you are proposing. Perhaps you can lay it out? What's wrong with the approach I suggest? It seems simple and direct. Really the only thing that's tricky here is that the "class-op rules" are built-in so you can't control their competition with rules you want to write. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 22:01:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 22:01:59 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.11da9d6862a14a865caa18efb3ee5210@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I tried 8.2.1-rc2 and it took a similar amount of time (`real 0m6.241s user 0m0.013s sys 0m6.227s`) to link. However, then I tried 8.0.2 and indeed saw it was quite a bit faster (`real 0m2.888s user 0m0.009s sys 0m2.878s`). I still don't know you ended up seeing two minute link times though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 22:08:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 22:08:50 -0000 Subject: [GHC] #13746: Typeable changes in base-4.10 break ChasingBottoms's test suite In-Reply-To: <045.32f3840a089a8e740875e5633a95d4d2@haskell.org> References: <045.32f3840a089a8e740875e5633a95d4d2@haskell.org> Message-ID: <060.eacf22b842828b63c37bb2d6c11b1943@haskell.org> #13746: Typeable changes in base-4.10 break ChasingBottoms's test suite -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3605 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3605 Comment: Oh dear, how embarrassing! Thanks for the report. Patch in Phab:D3605. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 22:15:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 22:15:16 -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.9fde235bfcf70d1266c13e4fdb9bf92d@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.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 22:16:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 22:16:29 -0000 Subject: [GHC] #13731: DeriveFunctor and friends don't understand type families In-Reply-To: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> References: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> Message-ID: <065.36b0d6c57b06f7be890ac570f0044f81@haskell.org> #13731: DeriveFunctor and friends don't understand type families -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Oh my mistake. I thought `instance Functor (Test ListExtension)` involved a type family; but it doesn't. Neither `Test` nor `ListExtension` is a type family. My mistake. Then indeed the error message makes more sense. But not total sense. If you reduce the arity of `ExtensionType1 the `deriving` clause works fine (as it should) {{{ type family ExtensionType ext :: * -> * type instance ExtensionType ListExtension = [] }}} So it's not that it must be a data type; it can be a saturated type-family application. But I now think this is a non-bug; `deriving` is working right, and reducing the arity of `ExtensionType` is the right solution. But -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 22:16:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 22:16:45 -0000 Subject: [GHC] #13733: Simplify constraints on RULES LHS In-Reply-To: <046.c1818a7fbd77b52e8b57f0d827738261@haskell.org> References: <046.c1818a7fbd77b52e8b57f0d827738261@haskell.org> Message-ID: <061.dfc8b6e2d6d85836c4f794e4ae0bbad3@haskell.org> #13733: Simplify constraints on RULES LHS -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | 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): Oh, yes, the library author can! But someone downstream does not have the ability to change the {{{ instance Eq [a] where x == y = rhs }}} to the above format. Similarly if they want to write {{{ data T = … deriving Show }}} In both cases I would consider consider your approach an work-around that, well, works around the fact that an instance method does not have a Haskell-adressable name. So what am I proposing?… now, before I propose something, let me phrase clearly what I want to achieve: **I want to write rules that apply to an instance method.** (Your approach does not quite achieve that. What it does achieve is that I no longer want to address instance methods, as I can now adress `eqT`, which works fine in many cases. But this does not work if the instance declaration is out of my control.) There may be several ways of achieving this goal. One way would be: **Simplify constraints of rules with the current instances and apply class-op rules on the LHS of rules.** This way, the user’s rule {{{ forall (xs :: [Integer]). xs == xs = True }}} gets desugared to {{{ forall (xs_a1Hd :: [Integer]). == @ [Integer] ($fEq[] @ Integer $fEqInteger) xs_a1Hd xs_a1Hd = GHC.Types.True }}} (compare that with the rule above, which has a pattern variable $dEq_a1Jv for the `Eq [Integer]` dictionary), and then gentle simplification (including class-op) on the left turns this into {{{ forall (xs_a1Hd :: [Integer]). GHC.Classes.$fEq[]_$c== @Integer $fEqInteger xs_a1Hd xs_a1Hd = GHC.Types.True }}} which – how convenient – is precisely the code we want to match, in the form the simplifier puts it. This machinery should allow the rule author to address any concrete instance method, in his module or an imported module, by using the class method with a sufficiently precise type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 22:55:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 22:55:03 -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.9803c73812616373ff2bc315ceb20f14@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: | Differential Rev(s): Phab:D892 Wiki Page: | Phab:D896 -------------------------------------+------------------------------------- Changes (by TobyGoodwin): * Attachment "ghc10397.tar" added. rwbarton's simple code to reproduce the compiler performance problem -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 23:01:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 23:01:01 -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.ddae9b1fc0c53f7b4151d5b1c6cfc4e2@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: | Differential Rev(s): Phab:D892 Wiki Page: | Phab:D896 -------------------------------------+------------------------------------- Comment (by TobyGoodwin): Argh! (1) I only just saw this message a couple of days ago. Not sure why I didn't get / read / act upon email from trac. Argh! (2) I never meant to delete it from my website, I musta just been trigger happy one day. And for some reason it had never been added to the git repo that backs the site. After a deal of searching, I did manage to find a copy. I've reinstated it on my website, and have attached it to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 23:20:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 23:20:30 -0000 Subject: [GHC] #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted In-Reply-To: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> References: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> Message-ID: <060.0325c08a688f121566fb772e59e4e6fb@haskell.org> #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: simplifier | ticks Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: dynamic-paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * Attachment "sbug.hs" added. simplified version (26 lines) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 22 23:25:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 May 2017 23:25:42 -0000 Subject: [GHC] #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted In-Reply-To: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> References: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> Message-ID: <060.526a3f8a01462a9f91edc088050cf3cb@haskell.org> #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: simplifier | ticks Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: dynamic-paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): added attachment , simplified version of bug with 26 lines, sbug.hs. The problem can be reproduced with {{{ ghc -c sbug.hs -O -fprof-auto -prof -static }}} adding {{{ -fsimpl-tick-factor=1000 }}} still results in the error: Simplifier ticks exhausted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 00:12:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 00:12:52 -0000 Subject: [GHC] #13731: DeriveFunctor and friends don't understand type families In-Reply-To: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> References: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> Message-ID: <065.87c8ed7e8be4bbdb663de77221e2db84@haskell.org> #13731: DeriveFunctor and friends don't understand type families -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): > So it's not that it must be a data type; it can be a saturated type- family application. Am I missing something? In the original example, the type family instance is: {{{#!hs type instance ExtensionType ListExtension a = [a] }}} And the instance we're deriving is: {{{#!hs deriving instance Functor (Test ListExtension) }}} In other words, the field of `Extend` will have type `ExtensionType ListExtension a`. This is a fully saturated type family application, right? So surely the rule you've proposed doesn't quite capture the essence of this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 02:59:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 02:59:20 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.2a5616f2cabcf341483f90aa49cae7e5@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Replying to [comment:24 bgamari]: > > what is stopping GHCi supporting unsafe FFI calls? > > If I understand Simon correctly, the answer is probably "nothing". However, it's more a question of whether we want to change the semantics of "unsafe" foreign calls (something which would require the involvement of the Haskell Prime committee, if to be done properly). I can see the argument for `unsafe` not placing any new obligations on the compiler and think there's little reason to push for such a change. > > I do think, however, that it is important that we have a `unsafenogc` call type for the reason you describe. That's a reasonable solution. But as simon pointed out, we're too vague on `unsafe` FFI calls before, it's not a big deal to give a more clear semantics, is it? After all we have been relying that semantics for years, it's more costly to add new FFI keyword and change all the libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 03:24:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 03:24:45 -0000 Subject: [GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 In-Reply-To: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> References: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> Message-ID: <062.cebeadf23f956fcd1afd5cf14ae2262f@haskell.org> #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | ConstraintKinds, KindSignatures 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): * priority: normal => highest * cc: ezyang (added) Comment: This regression was introduced in commit 31398fbc6d9ee0bd95de64b08becc38faf188972 (Test for type synonym loops on TyCon). Might you know what is going on here, ezyang? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 03:46:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 03:46:15 -0000 Subject: [GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 In-Reply-To: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> References: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> Message-ID: <062.fdadd6c2b660317cdda2bdc9cb334c08@haskell.org> #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | ConstraintKinds, KindSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: @@ -6,0 +6,29 @@ + + Compiling the attached file fails gives the error: + + {{{ + [[1 of 1] Compiling CKBug ( CKBug.hs, interpreted ) + + CKBug.hs:33:4: error: + • Expected a type, but + ‘(PropagIOConstraint l a, + Missing (PropagIOVector l) (PropagIONullable l a), + Elem (PropagIONullable l a) ~ a)’ has kind + ‘Constraint’ + • In the type ‘((PropagIOConstraint l a, + Missing (PropagIOVector l) (PropagIONullable l a), + Elem (PropagIONullable l a) ~ a))’ + In the type declaration for ‘CanSerialize’ + | + 33 | (( PropagIOConstraint l a + | ^^^^^^^^^^^^^^^^^^^^^^^^... + + CKBug.hs:42:4: error: + • Expected a constraint, + but ‘(CanSerialize l Double, CanSerialize l Int)’ has kind ‘*’ + • In the type ‘(CanSerialize l Double, CanSerialize l Int)’ + In the type declaration for ‘CanSerializePropagTypes’ + | + 42 | ( CanSerialize l Double + | ^^^^^^^^^^^^^^^^^^^^^^^... + }}} New description: The attached module compiles without errors with GHC 8.0.1 but needs an explicit kind signature with GHC 8.2.1-rc2. Mentioned in this [https://mail.haskell.org/pipermail/ghc- devs/2017-May/014222.html ghc-dev thread]. Compiling the attached file fails gives the error: {{{ [[1 of 1] Compiling CKBug ( CKBug.hs, interpreted ) CKBug.hs:33:4: error: • Expected a type, but ‘(PropagIOConstraint l a, Missing (PropagIOVector l) (PropagIONullable l a), Elem (PropagIONullable l a) ~ a)’ has kind ‘Constraint’ • In the type ‘((PropagIOConstraint l a, Missing (PropagIOVector l) (PropagIONullable l a), Elem (PropagIONullable l a) ~ a))’ In the type declaration for ‘CanSerialize’ | 33 | (( PropagIOConstraint l a | ^^^^^^^^^^^^^^^^^^^^^^^^... CKBug.hs:42:4: error: • Expected a constraint, but ‘(CanSerialize l Double, CanSerialize l Int)’ has kind ‘*’ • In the type ‘(CanSerialize l Double, CanSerialize l Int)’ In the type declaration for ‘CanSerializePropagTypes’ | 42 | ( CanSerialize l Double | ^^^^^^^^^^^^^^^^^^^^^^^... }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 04:14:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 04:14:21 -0000 Subject: [GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 In-Reply-To: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> References: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> Message-ID: <062.7262f7ccf725f1bbe7f42b7ec4d64cde@haskell.org> #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | ConstraintKinds, KindSignatures 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 ezyang): Here is a more minimized example: {{{ {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE UndecidableSuperClasses #-} {-# LANGUAGE FlexibleContexts #-} module CKBug where import GHC.Exts (Constraint) type A l = (D l -- :: Constraint) -- Uncommenting this line allows GHC 8.2.1 to compile this ) type B l = ( A l, A l ) class B l => C l where type D l :: Constraint }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 04:50:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 04:50:59 -0000 Subject: [GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 In-Reply-To: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> References: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> Message-ID: <062.e33bc4193f7e77b1101e1c3b3462f3ad@haskell.org> #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | ConstraintKinds, KindSignatures 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 ezyang): So, the proximal cause of the error is that we're kind-checking A, B, C and D in one SCC where 8.0 wasn't previously, but one might imagine kind inference should still have come up with the correct kinds. We have a problem with the fact that `( A l, A l )` is overloaded: GHC doesn't know whether or not this is `Constraint -> Constraint -> Constraint`, or `* -> * -> *`. It decides the latter, and then you get a type error. Here's a relevant note from GHC source code: {{{ Note [Inferring tuple kinds] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Give a tuple type (a,b,c), which the parser labels as HsBoxedOrConstraintTuple, we try to figure out whether it's a tuple of kind * or Constraint. Step 1: look at the expected kind Step 2: infer argument kinds If after Step 2 it's not clear from the arguments that it's Constraint, then it must be *. Once having decided that we re-check the Check the arguments again to give good error messages in eg. `(Maybe, Maybe)` Note that we will still fail to infer the correct kind in this case: type T a = ((a,a), D a) type family D :: Constraint -> Constraint While kind checking T, we do not yet know the kind of D, so we will default the kind of T to * -> *. It works if we annotate `a` with kind `Constraint`. }}} This is a pretty similar situation. In the old world order, we first added a provisional kind for `D` to the environment before computing the kinds for type synonyms, which is why `A l` was correctly kinded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 05:47:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 05:47:32 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.32860c70cf71255ef94a2beea5ad5558@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Comment (by dfeuer): I made the big hammer smaller (see Phab:D3606). Things don't go utterly disastrous, but there are still a few modules over a gigabyte (max somewhere around 1700M). I'm not sure exactly which ones; is there a way to find out without doing a single-threaded build? I'll try to do some profiling and see if I can figure out what's going wrong, exactly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 06:57:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 06:57:55 -0000 Subject: [GHC] #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException In-Reply-To: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> References: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> Message-ID: <065.8710234472287b24f8d2f707dcc626f2@haskell.org> #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by svenpanne): Hmmm, taking a step back, the author of a `foreign import` has to answer the following questions: * Is it OK for the foreign call that (part of) it might run in another OS thread? * Can the foreign call block? * Can the foreign call cause a GC? The last item is probably the same question as: Can the foreign call call back into Haskell? For OpenGL-related calls the answers are: * All OpenGL-related code **must** run in a single thread. There is some arcane Kung Fu in newer OpenGL revisions to allow a bit of multithreading, but it is rarely used and must be done in an explicit manner. * The vast majority of OpenGL calls can't block, and even if they can: Due to the single thread requirement above, it is OK to block everything. * More recent OpenGL versions have the a facility to register debugging callbacks which can fire at any time, so basically all OpenGL calls can cause a GC. All OpenGL calls are done dynamically via native function pointers, something like: {{{#!haskell foreign import ccall "dynamic" dyn376 :: FunPtr (Ptr a -> GLsizei -> Ptr GLsizei -> Ptr GLchar -> IO ()) -> Ptr a -> GLsizei -> Ptr GLsizei -> Ptr GLchar -> IO () }}} `safe` is the default, so this should be correct. The GLUT binding is basically implemented the same way, with the same restrictions imposed by the native API. So the bug IMHO in GHCi is that it somehow silently does some thread switches behind the scenes, although the original program did not talk about multithreading at all. Requiring `runInBoundThread` here doesn't seem right. I think part of the confusion in this ticket and #8281 is that it is highly unclear what `safe` and `unsafe` should actually mean nowadays. In the old days, `safe` just meant "Hey, I can call back into Haskell land, better take care of your data structures for GC etc.". I have no idea what it is supposed to mean in detail today, but it definitely shouldn't be a license for thread migration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 08:28:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 08:28:31 -0000 Subject: [GHC] #13731: DeriveFunctor and friends don't understand type families In-Reply-To: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> References: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> Message-ID: <065.5096ef29ea10c61a8ba8a8d42064205a@haskell.org> #13731: DeriveFunctor and friends don't understand type families -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:4 simonpj]: > If you reduce the arity of `ExtensionType1 the `deriving` clause works fine (as it should) Ah, nothing to do with injective type families -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 08:29:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 08:29:10 -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.f1977b1027394c7687d50fdc7c158acb@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.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 09:01:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 09:01:09 -0000 Subject: [GHC] #13743: Colourise command output In-Reply-To: <051.41e540f3ba1bbaf7e0918d0f79f0c13f@haskell.org> References: <051.41e540f3ba1bbaf7e0918d0f79f0c13f@haskell.org> Message-ID: <066.1146b63dd284a868c548a573d30ef897@haskell.org> #13743: Colourise command output -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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: #8809 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:3 bgamari]: > I would much rather have a general mechanism for integrating with GHCi, allowing users to more easily extend and customize its functionality. I'm all for that -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 13:18:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 13:18:10 -0000 Subject: [GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 In-Reply-To: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> References: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> Message-ID: <062.a6afa67953b8f6e18822b38800f1ca9a@haskell.org> #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | ConstraintKinds, KindSignatures 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): GHC does a very limited form of type-directed name resolution to tell the difference between `(,) :: Type -> Type -> Type` and `(,) :: Constraint -> Constraint -> Constraint`. Type-directed name resolution and type inference hate each other with a passion, so sometimes there's collateral damage in the fight. Bottom line: this design is an infelicity of `ConstraintKinds` in GHC. A fix would be to parameterize `(,)` by a `Constraintiness` parameter, as discussed [https://github.com/ghc-proposals/ghc-proposals/pull/32 here]. Then type inference would be predictable. Short of that solution, I'm not sure what guarantees we can promise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 13:39:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 13:39:30 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.cd8bb5ce85465a0e228ffd2024be067c@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Comment (by bgamari): I really wish that the build system could record RTS statistics on a per- file basis (e.g. perhaps just emitting a log file per GHC process). That would make collecting this sort of thing much easier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 13:43:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 13:43:32 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.eab2667eb718ce109921620a6bda050c@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > But as simon pointed out, we're too vague on unsafe FFI calls before, it's not a big deal to give a more clear semantics, is it? I absolutely agree that the documentation should be improved either way. It's possible that #13730 is also being bit by this same confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 13:45:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 13:45:15 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2313625=3A_GHC_internal_error=3A_?= =?utf-8?q?=E2=80=98Y=E2=80=99_is_not_in_scope_during_type_checki?= =?utf-8?q?ng=2C_but_it_passed_the_renamer?= In-Reply-To: <049.ad31bbf13fa6a8340cd37900420f039f@haskell.org> References: <049.ad31bbf13fa6a8340cd37900420f039f@haskell.org> Message-ID: <064.6eda7026d5ef7dddd1f7a36ebc57f5e3@haskell.org> #13625: GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.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: | polykinds/T13625 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Merged to `ghc-8.2` as 2fb2b60ebc6a649b8345bbb491a253972c973978. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 13:48:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 13:48:52 -0000 Subject: [GHC] #9287: changed dependency generation In-Reply-To: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> References: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> Message-ID: <060.f217734fb0d7e3fc345109513861c4cc@haskell.org> #9287: changed dependency generation -------------------------------------+------------------------------------- Reporter: maeder | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Driver | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #9749, #7381 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as e84b18dfa98c3d2fc9c9288203113a2fbca406ba. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 13:51:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 13:51:00 -0000 Subject: [GHC] #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules In-Reply-To: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> References: <042.855c9299e7cba61a761532f783db3f4e@haskell.org> Message-ID: <057.cb50243da97a81580fff7b05c66690dd@haskell.org> #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules -------------------------------------+------------------------------------- Reporter: hvr | Owner: Yuras Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3598 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 14:10:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 14:10:36 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.6a3db3a05cabb248d37231e928e625bd@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 14:13:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 14:13:24 -0000 Subject: [GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 In-Reply-To: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> References: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> Message-ID: <062.37efb820b77f06098b3e3c7274d1b26b@haskell.org> #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | ConstraintKinds, KindSignatures 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 Iceland_jack): Replying to [comment:5 goldfire]: > A fix would be to parameterize `(,)` by a `Constraintiness` parameter, as discussed [https://github.com/ghc-proposals/ghc-proposals/pull/32 here]. Any idea how much work adding it is? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 14:20:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 14:20:45 -0000 Subject: [GHC] #13747: Can't use 'instance' keyword in associated type family instance Message-ID: <042.cfa21cd9140248a25075b778770d0326@haskell.org> #13747: Can't use 'instance' keyword in associated type family instance -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #associated-instances The manual on type families says:] > When an associated data or type synonym family instance is declared within a type class instance, we (optionally) may drop the instance keyword in the family instance" But that doesn't work for me. Using {{{ class Myclass a where type family MyFamily a :: * }}} then the code {{{ instance Myclass Mytype where type instance MyFamily Mytype = Int }}} doesn't compile but {{{ instance Myclass Mytype where type MyFamily Mytype = Int }}} I'd expect to be able to use the `instance` keyword here. I'd prefer this to be treated as an implementation bug instead of a doc bug, because I think it can be useful to be explicit for the ease of reading (and it work works the same way for class declaration, as the example also demonstrates). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 14:57:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 14:57:40 -0000 Subject: [GHC] #13746: Typeable changes in base-4.10 break ChasingBottoms's test suite In-Reply-To: <045.32f3840a089a8e740875e5633a95d4d2@haskell.org> References: <045.32f3840a089a8e740875e5633a95d4d2@haskell.org> Message-ID: <060.1f5937b3ef56247c9f2e98c493df53ae@haskell.org> #13746: Typeable changes in base-4.10 break ChasingBottoms's test suite -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3605 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6166b59fadb8714cd497902c8469fd2b3b6caf46/ghc" 6166b59f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6166b59fadb8714cd497902c8469fd2b3b6caf46" base: Fix a few TODOs in Typeable.Internal Test Plan: Validate Reviewers: austin, hvr, dfeuer Reviewed By: dfeuer Subscribers: rwbarton, thomie GHC Trac Issues: #13746 Differential Revision: https://phabricator.haskell.org/D3605 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 15:11:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 15:11:23 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.ee2494bd8b6925dcc5d7d4724698bf34@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:40 bgamari]: > I really wish that the build system could record RTS statistics on a per-file basis (e.g. perhaps just emitting a log file per GHC process). That would make collecting this sort of thing much easier. We already emit some extra output (mostly for debugging purposes) to `-dumpdir dir`, so there'd be precedent to use output files for logging data, rather than dump it to stdout only. So one way would be to extend `-Rghc-timing` to optionally take a filename, e.g. `-Rghc-timing=rts- stats.log`; similarly for other statistics David pointed out (e.g. optimiser stats). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 15:22:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 15:22:02 -0000 Subject: [GHC] #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException In-Reply-To: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> References: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> Message-ID: <065.bc60f2957e4ebcfd69684c2a3c4d739f@haskell.org> #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by RyanGlScott): svenpanne, you are correct that this used to work. I just tried this program with GHC 7.10.3 and 8.0.1, and it worked successfully. The only issue was this it gave me this warning: {{{ $ ~/Software/ghc-8.0.1/bin/ghci HsGLUT.o GLUT2.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/rscott/.ghci [1 of 1] Compiling Main ( GLUT2.hs, interpreted ) Ok, modules loaded: Main. λ> main 2017-05-23 08:20:34.277 ghc[59156:853268] WARNING: nextEventMatchingMask should only be called from the Main Thread! This will throw an exception in the future. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 15:30:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 15:30:57 -0000 Subject: [GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 In-Reply-To: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> References: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> Message-ID: <062.9a4e501f3801b4085dd4cd1afb07d97d@haskell.org> #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | ConstraintKinds, KindSignatures 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): Adding it: maybe a day's work. (That's quite a lot, in the scheme of things.) Maintaining it forever: more than that. Nevertheless, I do think this is where we're headed... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 15:32:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 15:32:09 -0000 Subject: [GHC] #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException In-Reply-To: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> References: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> Message-ID: <065.cdf1e91954c2aeadce1373610b25e07c@haskell.org> #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by RyanGlScott): There's an extremely similar issue in Racket as well (https://github.com/racket/racket/issues/1491), with the warning appearing in Racket v6.5 and v6.6, and the error popping up in version v6.7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 16:01:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 16:01:54 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.d18c5aa522e992be09ae0edaaa07ef89@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I suggested to @bgamari today that it might be possible to support `unsafe` foreign calls in GHCi with the same behaviour as compiled code (i.e. no GC during the call guaranteed) by avoiding the `suspendThread()` / `resumeThread()` calls that the interpreter makes in the bci_CCALL byte code implementation. We'd need to include a flag with the byte code to indicate that the call is unsafe, but there's already a flag being passed for interruptible so there's room for another flag in the same word. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 16:35:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 16:35:44 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.d65455024831cd4363f8e3a3baf4e83f@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): BTW, this is pretty much the exact code that GHC emits with `-ddump-deriv` if you try to write this `C (Wrap f)` instance with `GeneralizedNewtypeDeriving`: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE PolyKinds #-} {-# OPTIONS_GHC -ddump-deriv #-} module Works where newtype Wrap f a = Wrap (f a) deriving C class C f where c :: f a }}} {{{ GHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Works ( Works.hs, interpreted ) ==================== Derived instances ==================== Derived class instances: instance forall k (f :: k -> *). Works.C f => Works.C (Works.Wrap f) where Works.c = GHC.Prim.coerce @(forall (a_a1tD :: k_a1uE). f_a1tE a_a1tD) @(forall (a_a1tD :: k_a1uE). Works.Wrap f_a1tE a_a1tD) Works.c Derived type family instances: }}} This reveals a pretty-printing bug, as the explicitly quantified kind variable `k` referred to by a different name `k_a1uE` later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 16:35:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 16:35:59 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.81eb534341c13018d13dddb7088e11c2@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): There are two workarounds that I'm aware of. One is to explicitly quantify the kind variable `k` in the instance declaration: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Coerce import Data.Kind (Type) newtype Wrap f a = Wrap (f a) class C f where c :: f a instance forall k (f :: k -> Type). C f => C (Wrap f) where c = coerce @(forall (a :: k). f a) @(forall (a :: k). C f a) c }}} (This, of course, requires that you turn on `TypeInType`.) The other workaround is to leave off the kind annotations in the instance altogether: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} module Bug where import Data.Coerce newtype Wrap f a = Wrap (f a) class C f where c :: f a instance C f => C (Wrap f) where c = coerce @(forall a. f a) @(forall a. C f a) c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 17:02:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 17:02:56 -0000 Subject: [GHC] #13748: Variables pretty-printed from -ddump-deriv are not scoped properly Message-ID: <050.b0e6834a7632959673c4cff72181e4bd@haskell.org> #13748: Variables pretty-printed from -ddump-deriv are not scoped properly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This bug is present on GHC 8.0.1, 8.0.2, 8.2.1 and HEAD, and originally noted in https://ghc.haskell.org/trac/ghc/ticket/13738#comment:2. Take this code: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE PolyKinds #-} {-# OPTIONS_GHC -ddump-deriv #-} module Works where newtype Wrap f a = Wrap (f a) deriving C class C f where c :: f a }}} When you compile it with GHC 8.0.2, you'll get this unsavory output: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Works ( Works.hs, interpreted ) ==================== Derived instances ==================== Derived instances: instance forall k_a14U (f_a14V :: k_a14U -> *). Works.C f_a14V => Works.C (Works.Wrap f_a14V) where Works.c = GHC.Prim.coerce @(forall (a_a13F :: k_a14u). f_a13G a_a13F) @(forall (a_a13F :: k_a14u). Works.Wrap f_a13G a_a13F) Works.c GHC.Generics representation types: }}} This is wrong, since the quantified variables in the instance head (`k_a14U` and `f_a14V`) do not match the occurrences that they bind (`k_a14u` and `f_a13G`). This is somewhat easier to see on GHC 8.2.1 or HEAD, since the binding sites are printed without uniques: {{{ GHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Works ( Works.hs, interpreted ) ==================== Derived instances ==================== Derived class instances: instance forall k (f :: k -> *). Works.C f => Works.C (Works.Wrap f) where Works.c = GHC.Prim.coerce @(forall (a_a1tD :: k_a1uE). f_a1tE a_a1tD) @(forall (a_a1tD :: k_a1uE). Works.Wrap f_a1tE a_a1tD) Works.c Derived type family instances: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 17:03:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 17:03: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.60e471ee4b572df0483f6d85decfe388@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've opened #13748 for the issue described in https://ghc.haskell.org/trac/ghc/ticket/13738#comment:2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 17:26:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 17:26:10 -0000 Subject: [GHC] #8703: Use guard pages rather than heap checks In-Reply-To: <046.cc8df1f4c44d21b3204aafaf538413fa@haskell.org> References: <046.cc8df1f4c44d21b3204aafaf538413fa@haskell.org> Message-ID: <061.dd13706eb7ccca5022941c6634ccd4fe@haskell.org> #8703: Use guard pages rather than heap checks -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 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 varosi): I'm not that into GHC runtime and implications, but we could make some discussions on this topic and put it as opened issue for future work? Here is some talk: https://www.reddit.com/r/haskell/comments/6bpf3p/guard_pages_instead_of_heapstack_limit_checks_in/ Sorry about the question, but why GHC's heap is linked list? Why not use linear virtual memory? Thread's stack could be linear, too. This will make much more easier and faster to access it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 18:08:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 18:08:12 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.a8566b4b413073d059185c56248c718f@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I am working on github/haskell/cabal commit 0b5f13d71e3282df03495e1db75cd8375b0879ab I believe I have not been testing with rc2, but various releases from the rc2 branch obtained from https://launchpad.net/~hvr/+archive/ubuntu/ghc. I replicated this again with ghc-8.2.0.20170521. I am running ubuntu 16.04 with all my packages upgraded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 20:24:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 20:24:40 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.f52d38f0f39fb787fe832282c65b9d5f@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Rev(s): Phab:D1130, #7666, #8809 | Phab:D1132 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Note that adinapoli has been doing some great work on this: https://github.com/haskell/pretty/pull/43. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 21:55:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 21:55:18 -0000 Subject: [GHC] #13731: DeriveFunctor and friends don't understand type families In-Reply-To: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> References: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> Message-ID: <065.21222ba283a49c54e10bcb99f5091d85@haskell.org> #13731: DeriveFunctor and friends don't understand type families -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Consider the instance we want: {{{ instance Functor (Test ListExtension) where fmap f (Extend x) = Extend (fmap f x) }}} > Am I missing something? From the inner `fmap` we get `[W] Functor (ExtensionType ListExtension)`. If `ExtensionType` has arity 2, that would be an un-saturated type family. But if it has arity 1 it is saturated, and reduces to `[]`, so all is well. > ... the field of `Extend` will have type `ExtensionType ListExtension a`. This is a fully saturated type family application Yes, it's saturated in the field, but the use of `fmap` requires us to decompose the type application, we it must be decomposable. It's only decomposable if `ExtensionType` has arity 1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 22:04:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 22:04:01 -0000 Subject: [GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 In-Reply-To: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> References: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> Message-ID: <062.814ce6b2dc930ded806bd81d806f68b1@haskell.org> #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | ConstraintKinds, KindSignatures 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): A bit more detail.... It's all a result of the ambiguity between tuples and constraints. * `A`, `B`, `C`, and `D` are all mutually recursive * When inferring the kind for them, they get initial kinds {{{ A :: k1 -> k2 B :: k3 -> k4 C :: k5 -> Constraint D :: k5 -> Constraint }}} where the `ki` are kind unification variables * Then we happen visit them in order `C` (and `D`), `B`, `A`. * So when kind-checking `B` we have not yet figured out `A`'s kind * And becuase of the tuple/constraint ambiguity, we prematurely choose that the tuple `(A l, A l)` will be a `BoxedTuple` not a `ConstraintTuple`. Something rather similar comes up with the empty tuple; we have an open ticket for that, #9547 (maybe others). What we really want, of course, is to defer the choice until we have worked out the kinds of `A`, `B`, `C`, and `D`; and there is no difficulty in principle with doing that. But it's tricky at the moment because we use one piece of code (`TcHsType.tc_hs_type`) for both kind checking (working out what the kinds of each type constructor are) and desugaring (producing a `Type` from a `HsType`. In the first of these steps we don't need to aggressively commit to which kind of tuple we want; in the latter step we do. This will become straightforward when we adopt #13737. Meanwhile, there's a decent workaround, so I'll park this one for now. I don't think there is an easy solution in the current setup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 22:09:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 22:09:05 -0000 Subject: [GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 In-Reply-To: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> References: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> Message-ID: <062.34b525de3b9b79434738ff465c2f9cba@haskell.org> #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | ConstraintKinds, KindSignatures 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): * priority: highest => normal Comment: Bumping the priority down based on the previous discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 22:10:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 22:10:45 -0000 Subject: [GHC] #13731: DeriveFunctor and friends don't understand type families In-Reply-To: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> References: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> Message-ID: <065.0b6070a8c24563df0f91dabaf8f2f490@haskell.org> #13731: DeriveFunctor and friends don't understand type families -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:7 simonpj]: > Yes, it's saturated in the field, but the use of `fmap` requires us to decompose the type application, we it must be decomposable. It's only decomposable if `ExtensionType` has arity 1. Thank you, this is the part that I wasn't understanding. So would you be happy with this error message? {{{ • Can't make a derived instance of ‘Functor (Test ListExtension)’: Constructor ‘Extend’ must use the last type variable only as the last argument of a data type or a saturated type family }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 22:12:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 22:12:36 -0000 Subject: [GHC] #13749: Panic (initTc: unresolved constraints) on some bad code Message-ID: <046.9731ac2abaa6ea508d1cebf5f6199012@haskell.org> #13749: Panic (initTc: unresolved constraints) on some bad code -------------------------------------+------------------------------------- Reporter: uranium | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was just refactoring some code, and partway through, before it was all compiling, I hit the below error. The code's probably just terrible in an interestingly new way; I'm pretty inexperienced at Haskell. I'll attach the file. Prelude> :r [1 of 1] Compiling Main ( /home/uranium/projects/server/src/Main.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] get_aGsK :: t_aGsJ[tau:1] (CHoleCan: get) [W] execState_aGsX :: t_aGsW[tau:1] (CHoleCan: execState) [W] get_aGvL :: t_aGvK[tau:1] (CHoleCan: get) [W] lift_aGvU :: t_aGvT[tau:1] (CHoleCan: lift) [W] put_aGw3 :: t_aGw2[tau:1] (CHoleCan: put) [W] cellType_aGwy :: t_aGwx[tau:1] (CHoleCan: cellType) [W] insts_aGwB :: t_aGwA[tau:1] (CHoleCan: insts) [W] ports_aGwE :: t_aGwD[tau:1] (CHoleCan: ports) [W] conns_aGwH :: t_aGwG[tau:1] (CHoleCan: conns) [W] annos_aGwK :: t_aGwJ[tau:1] (CHoleCan: annos) [W] comms_aGwN :: t_aGwM[tau:1] (CHoleCan: comms)} 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 May 23 22:13:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 22:13:08 -0000 Subject: [GHC] #13749: Panic (initTc: unresolved constraints) on some bad code In-Reply-To: <046.9731ac2abaa6ea508d1cebf5f6199012@haskell.org> References: <046.9731ac2abaa6ea508d1cebf5f6199012@haskell.org> Message-ID: <061.c4c8abe388bd3c50ce11cc801ee41698@haskell.org> #13749: Panic (initTc: unresolved constraints) on some bad code -------------------------------------+------------------------------------- Reporter: uranium | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by uranium): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 22:13:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 22:13:45 -0000 Subject: [GHC] #13749: Panic (initTc: unresolved constraints) on some bad code In-Reply-To: <046.9731ac2abaa6ea508d1cebf5f6199012@haskell.org> References: <046.9731ac2abaa6ea508d1cebf5f6199012@haskell.org> Message-ID: <061.4077c7bacfe33b4d22e574a30e636db1@haskell.org> #13749: Panic (initTc: unresolved constraints) on some bad code -------------------------------------+------------------------------------- Reporter: uranium | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by uranium): * Attachment "server.cabal" added. Cabal file, in case it helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 22:22:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 22:22:27 -0000 Subject: [GHC] #13731: DeriveFunctor and friends don't understand type families In-Reply-To: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> References: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> Message-ID: <065.f4fded57bcd69e5a2333820598f5dcec@haskell.org> #13731: DeriveFunctor and friends don't understand type families -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): You should ask users not me! But looking at {{{ Extend :: ExtensionType ext a -> Test ext a }}} a user might say that `ExtentionType ext a` ''does'' use `a` as the last arg of a saturated type-family application, namely `ExtensionType ext a`! An what is "the last type variable"? Guessing wildly, what about {{{ Illegal use of type variable 'a' in the first argument of `Extend`. Such uses must be of form `ty a` where `ty` is a data type or saturated type family application. }}} I'm not sure if that's better... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 22:27:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 22:27:15 -0000 Subject: [GHC] #13749: Panic (initTc: unresolved constraints) on some bad code In-Reply-To: <046.9731ac2abaa6ea508d1cebf5f6199012@haskell.org> References: <046.9731ac2abaa6ea508d1cebf5f6199012@haskell.org> Message-ID: <061.1cc6066bd7fc061b6cd32dedac4115c8@haskell.org> #13749: Panic (initTc: unresolved constraints) on some bad code -------------------------------------+------------------------------------- Reporter: uranium | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple 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. Note that this panic is usually caused by using identifiers that aren't in-scope (in your case, `get`, `execState`, etc.) in just the right way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 23 23:01:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 May 2017 23:01:31 -0000 Subject: [GHC] #13749: Panic (initTc: unresolved constraints) on some bad code In-Reply-To: <046.9731ac2abaa6ea508d1cebf5f6199012@haskell.org> References: <046.9731ac2abaa6ea508d1cebf5f6199012@haskell.org> Message-ID: <061.32e971b1c789b86c21e9a55c53393da7@haskell.org> #13749: Panic (initTc: unresolved constraints) on some bad code -------------------------------------+------------------------------------- Reporter: uranium | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by uranium): Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 01:00:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 01:00:53 -0000 Subject: [GHC] #13750: GHC produces incorrect coercions in hairy code Message-ID: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> #13750: GHC produces incorrect coercions in hairy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Andres Löh has been working with an optimized version of generics-sop, and ran into segfaults. He was able to reduce the test case to the attached (still not tiny) one, and could reduce it no further. He discovered the following utterly bogus definition in `-ddump-simpl` (with -O): {{{ Main.gshowP_$dAll :: All MyShow GHC.Exts.Any [GblId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}] Main.gshowP_$dAll = ghc-prim-0.5.0.0:GHC.Classes.$p1(%,%) @ (All MyShow GHC.Exts.Any) @ (All (All MyShow) GHC.Exts.Any) (ghc-prim-0.5.0.0:GHC.Classes.C:(%%) `cast` (Sub (Sym (Main.D:R:AllFk_c[][0] <[*]>_N _N)) ; Sym (Main.N:All[0] <[*]>_N _N <'[]>_N) ; Sub (Nth:1 (Sub (Sym (Main.D:R:AllFkc:[0] <[*]>_N _N <'[Char]>_N <'[]>_N)) ; (AllF <[*]>_N _N ((':) <[*]>_N (UnsafeCo nominal '[Char] GHC.Exts.Any) (UnsafeCo nominal '[] GHC.Exts.Any))_N)_R ; Sub (Main.D:R:AllFkc:[0] <[*]>_N _N _N _N))) ; Main.N:All[0] <[*]>_N _N (UnsafeCo nominal GHC.Exts.Any (GHC.Exts.Any : GHC.Exts.Any)) ; Sub (Main.D:R:AllFkc:[0] <[*]>_N _N _N _N) :: (() :: Constraint :: Constraint) ~R# ((All MyShow GHC.Exts.Any, All (All MyShow) GHC.Exts.Any) :: Constraint))) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 01:01:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 01:01:35 -0000 Subject: [GHC] #13750: GHC produces incorrect coercions in hairy code In-Reply-To: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> References: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> Message-ID: <060.a19e146afd6553d8aec17e1b1f7f5af2@haskell.org> #13750: GHC produces incorrect coercions in hairy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "segfault-investigation.cabal" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 01:01:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 01:01:47 -0000 Subject: [GHC] #13750: GHC produces incorrect coercions in hairy code In-Reply-To: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> References: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> Message-ID: <060.038a8cb14ac53f955781ca49a2002622@haskell.org> #13750: GHC produces incorrect coercions in hairy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "SegfaultAllInOne.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 01:01:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 01:01:59 -0000 Subject: [GHC] #13750: GHC produces incorrect coercions in hairy code In-Reply-To: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> References: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> Message-ID: <060.ff4d227339b45ac890ada89cae554210@haskell.org> #13750: GHC produces incorrect coercions in hairy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "NS.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 01:06:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 01:06:05 -0000 Subject: [GHC] #13750: GHC produces incorrect coercions in hairy code In-Reply-To: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> References: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> Message-ID: <060.86987f3ea5a57db71d395d63dcd1aa0b@haskell.org> #13750: GHC produces incorrect coercions in hairy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): This is a regression, as it works in 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 01:08:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 01:08:18 -0000 Subject: [GHC] #13750: GHC produces incorrect coercions in hairy code In-Reply-To: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> References: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> Message-ID: <060.7a60692e8f4dd98b7cd827b897e1447d@haskell.org> #13750: GHC produces incorrect coercions in hairy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 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 dfeuer): * version: 8.3 => 8.2.1-rc2 * milestone: 8.4.1 => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 03:31:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 03:31:16 -0000 Subject: [GHC] #13750: GHC produces incorrect coercions in hairy code In-Reply-To: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> References: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> Message-ID: <060.abd7624c6b5d240f7cd240cca6021bc3@haskell.org> #13750: GHC produces incorrect coercions in hairy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 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 bgamari): * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 03:31:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 03:31:57 -0000 Subject: [GHC] #13750: GHC produces incorrect coercions in hairy code In-Reply-To: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> References: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> Message-ID: <060.e42fea810c1d786b3dc2066cbb8fc946@haskell.org> #13750: GHC produces incorrect coercions in hairy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #13429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) * related: => #13429 Comment: Commit a920404fb12fb52a59e4f728cce4d662a418c5f8 (Fix TcSimplify.decideQuantification for kind variables) caused this regression. On a related note, that same commit also caused another class of program to loop at runtime in https://ghc.haskell.org/trac/ghc/ticket/13429#comment:16, so there's definitely something fishy with this commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 03:32:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 03:32:57 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.1a407b099062b4fe252889c618952f30@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #13750 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13750 Comment: See also #13750, in which the same commit that caused this ticket also caused a program to start //segfaulting//. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 07:40:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 07:40:48 -0000 Subject: [GHC] #13750: GHC produces incorrect coercions in hairy code In-Reply-To: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> References: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> Message-ID: <060.b86d9fa4d3961d65d7a5c42abf26a072@haskell.org> #13750: GHC produces incorrect coercions in hairy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #13429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by edsko): * cc: edsko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 08:37:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 08:37:53 -0000 Subject: [GHC] #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException In-Reply-To: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> References: <050.f6283f68597bb13f67605132a145b9f1@haskell.org> Message-ID: <065.5f96ff9b382ad0bdca39e61d26e940ba@haskell.org> #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by svenpanne): Even the warning when using GHCi 7.10.3/8.0.1 looks a bit scary: Some GLUT code doesn't seem to be running in the main OS thread, although the example code doesn't involve any multithreading. GHCi shouldn't do these secret thread migrations: Apart from GLUT and OpenGL there are surely a lot of other libraries/frameworks out there which don't like such a thing... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 09:46:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 09:46:12 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms In-Reply-To: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> References: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> Message-ID: <066.352c8de7ae14596353f3bc226779748c@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | 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 simonpj): * status: new => closed * resolution: => invalid Comment: > But re the original Description, I agree that the bidirectional definition should go through I was wrong. Actually what is happening is quite reasonable. GHC is rejecting a unidirectional pattern with a signature (bidirectional is red herring): {{{ pattern LLam :: (forall a. a -> PLambda a) -> Lam pattern LLam x <- L (Lam x) }}} Why rejected? Well, if `LLam` had the type claimed by the signature, this would be ok {{{ f1 (LLam x) = (x 'c', x True) }}} since `x :: forall a. a -> PLambda a`. But if you expand the syononym, thus {{{ f2 (L (Lam x)) = (x 'c', x True) }}} it's clear that `f2` should be rejected. (And it is; try it.) If you doubt that it should be, try to desugar it: {{{ f2 = \(v:Lam). case v of L (w :: forall b. PLambda b) -> case (w @ty) of Lam (x :: ty -> PLambda ty) -> (x 'c', x True) }}} We pattern match on `f2`'s argument to extract a polymorphic `w`. Then we must apply `w` to some type `ty` before we can do any more; but now the `x` we get from pattern matching is not polymorphic. Conclusion: it's working fine. I'll close, but re-open if you disagree -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 09:51:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 09:51:55 -0000 Subject: [GHC] #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted In-Reply-To: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> References: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> Message-ID: <060.87314eea89f153a1a484a3e936d519d3@haskell.org> #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: simplifier | ticks Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: dynamic-paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => Research needed Comment: Aha! Dimitrios and I identified this problem with `TypeRep`, and wrote about this in Section 7 of [https://www.microsoft.com/en- us/research/publication/typed-reflection-in-haskell/ Typed reflection in Haskell]. This example probably comes straight from that section. Divergence is absolutely expected here; and the simplifier-tick mechanism correctly prevents the compiler from hanging. Of course, it would be better to spot the problem and not inline the function, but I don't know how to do that. An interesting research problem. Meanwhile, since there is no immediate prospect of solving this, and it's not causing any problems in practice, I'll move to milestone "research needed". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 10:26:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 10:26:24 -0000 Subject: [GHC] #10421: exponential blowup in inlining (without INLINE pragmas) In-Reply-To: <047.3eae2ebffed9a4a3ca74833c7f8bcec3@haskell.org> References: <047.3eae2ebffed9a4a3ca74833c7f8bcec3@haskell.org> Message-ID: <062.0240e0ddf4b6f2fecec7e4fb282917de@haskell.org> #10421: exponential blowup in inlining (without INLINE pragmas) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 TobyGoodwin): * Attachment "ghc10397.tar" added. here is the missing reproducer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 11:29:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 11:29:25 -0000 Subject: [GHC] #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted In-Reply-To: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> References: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> Message-ID: <060.632d93e1942d3de070b16d72aa80dbf9@haskell.org> #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: simplifier | ticks Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: dynamic-paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Is it a bug that it only diverges with "-fprof-auto -auto"? It compiles fine without those options. Yes, the code does come from that paper, as mentioned in a comment in the non-simplified version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 12:10:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 12:10:07 -0000 Subject: [GHC] #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted In-Reply-To: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> References: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> Message-ID: <060.f82d457a7650b0e801fb3affd71c65c5@haskell.org> #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: simplifier | ticks Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: dynamic-paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It diverges for me (with HEAD) even without profiling. I can't explain why it doesn't for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 12:54:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 12:54:10 -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.141abca91251c6ed89ae2c8d2331a36e@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: | Differential Rev(s): Phab:D892 Wiki Page: | Phab:D896 -------------------------------------+------------------------------------- Comment (by bgamari): Thanks TobyGoodwin! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 13:34:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 13:34:37 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms In-Reply-To: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> References: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> Message-ID: <066.9d38eb6f911e93a6d28ff64017fc0467@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): There is where my intuition breaks down. Writing this works, so higher- rank types + pattern synonyms are fine {{{#!hs newtype A = A (forall xx. xx -> xx) pattern PatA :: (forall xx. xx -> xx) -> A pattern PatA a = A a a :: A -> A a (PatA f) = A f }}} but I don't understand why this is different {{{#!hs newtype Endo a = Endo (a -> a) newtype B = B (forall xx. Endo xx) pattern PatB :: (a -> a) -> PatB pattern PatB f <- B (Endo f) b :: B -> forall xx. xx -> xx b (B (Endo f)) = f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 14:50:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 14:50:13 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms In-Reply-To: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> References: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> Message-ID: <066.e9a9d153748da358b3800a295969cf4a@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's quite different! As I suggest above, try writing it without the pattern synonym! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 16:00:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 16:00:50 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms In-Reply-To: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> References: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> Message-ID: <066.f6cde0dd0a6776ee7650a8d1c0a1ff3b@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Ah what confused me was that they both (''seemingly'') allow extracting a polymorphic function {{{#!hs type Id = forall xx. xx -> xx one :: A -> Id one (A f) = f two :: B -> Id two (B (Endo f)) = f }}} But this doesn't work: (like your `f2 (L (Lam x)) = (x 'c', x True)` example demonstrates) {{{#!hs -- works einn :: A -> (Int -> Int, () -> ()) einn (A f) = (f, f) -- fails tveir :: B -> (Int -> Int, () -> ()) tveir (B (Endo f)) = (f, f) }}} With your desugaring and #11350 {{{#!hs A (\@x -> id @x) B (\@x -> Endo @x (id @x)) }}} it becomes clearer to me. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 16:38:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 16:38:10 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms In-Reply-To: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> References: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> Message-ID: <066.76105053ec870d89954740cb50324389@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): A coworker at work helped me reach this {{{#!hs newtype A = A (forall xx. xx -> xx) newtype Endo a = Endo { appEndo :: a -> a } newtype B = B (forall xx. Endo xx) pattern PatB :: (forall xx. xx -> xx) -> B pattern PatB f <- ((\(B f) -> A (appEndo f)) -> A f) where PatB f = B (Endo f) }}} which works, similarly with `PLambda` {{{#!hs data PLambda a = Lam { unLam :: a -> PLambda a } | ... newtype LAM = LAM (forall xx. xx -> PLambda xx) newtype Lam = L (forall a. PLambda a) get :: Lam -> LAM get (L f) = LAM (unLam f) pattern LLAM :: (forall a. a -> PLambda a) -> Lam pattern LLAM f <- (get -> LAM f) where LLAM f = L (Lam f) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 17:00:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 17:00:05 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.efe5f7d1feb6cb360b20a0f4f769cac7@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): I'm getting 2 minute compile times when linking profiled GHC HEAD. Running with `-v` reveals that GHC is stuck on gcc doing linking Here's the stuck command: https://phabricator.haskell.org/P151, it takes 135s to complete. When I remove `-Wl,--gc-sections`, it's only 11s. It's part of this GHC invocation: {{{ "inplace/bin/ghc-stage1" -o ghc/stage2/build/tmp/ghc-stage2 -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -O0 -H64m -Wall -hide-all-packages - i -ighc/. -ighc/stage2/build -Ighc/stage2/build -ighc/stage2/build/ghc/autogen -Ighc/stage2/build/ghc/autogen -optP- DGHCI -optP-include -optPghc/stage2/build/ghc/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id array-0.5.1.2 -package-id bytestring-0.10.8.2 -package-id directory-1.3.0.2 -package-id process-1.6.0.0 -package-id filepath-1.4.1.2 -pack age-id ghc-boot-8.3 -package-id ghc-8.3 -package-id unix-2.7.2.2 -package- id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id ghci-8.3 -package-id haskeline-0.7.4.0 -packa ge-id time-1.8.0.1 -package-id transformers-0.5.2.0 -Wall -fno-warn-name- shadowing -XHaskell2010 -O -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-inst ances -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build -split-sections -static -prof -eventlog -O0 -H64m -Wall -hide-all-packages -i -ighc/. -ighc/ stage2/build -Ighc/stage2/build -ighc/stage2/build/ghc/autogen -Ighc/stage2/build/ghc/autogen -optP-DGHCI -optP-include -optPghc/stage2/build/ghc/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id array-0.5.1.2 -package-id bytestring-0.10.8.2 -package-id directory-1.3.0.2 -package-id process-1.6.0.0 -package-id filepath-1.4.1.2 -package-id ghc-boot- 8.3 -package-id ghc-8.3 -package-id unix-2.7.2.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id ghci-8.3 -package-id haskeline-0.7.4.0 -package-id time-1.8.0 .1 -package-id transformers-0.5.2.0 -Wall -fno-warn-name-shadowing -XHaskell2010 -O -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances ghc/stage 2/build/Main.p_o ghc/stage2/build/GHCi/UI.p_o ghc/stage2/build/GHCi/UI/Info.p_o ghc/stage2/build/GHCi/UI/Monad.p_o ghc/stage2/build/GHCi/UI/Tags.p_o ghc/stage2/build/hschooks.p_o -v -keep- tmp-files }}} My gcc version: {{{ $ gcc --version gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11) Copyright (C) 2015 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. }}} @doug: Can you run the command that hangs with: `cabal build cabal-install --ghc-options='-v'` to check if it's an instance of the same problem? If it's also stuck on `gcc` you can run it with `cabal build cabal-install --ghc-options='-v -keep-tmp-files'` and run the `gcc` command by itself. Then try removing `-Wl,--gc-sections`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 17:32:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 17:32:15 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.830f8d4bf21fa9188a30680c52cad251@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Running the ld command with `--print-gc-sections` gives me 254934 lines. I don't know if that's big or small. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 17:34:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 17:34:28 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.1b9e65c1574007d29833bdee66daee2e@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): > but what about a type class and typed quasiquotes? How would this work in order to get type of the quasiquote? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 18:25:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 18:25:26 -0000 Subject: [GHC] #13751: Runtime crash with <> after concurrent stressing of STM computatinos. Message-ID: <046.2e620bb56fd39fe88732c85fa515dde8@haskell.org> #13751: Runtime crash with <> after concurrent stressing of STM computatinos. -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 10414 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For reproduction, see stack project at https://github.com/robinp/bugreports/tree/master/blackhole. Copying its readme here: ### Compiler & OS GHC 7.10.3, 8.0.1, 8.0.2 (didn't check others). Linux: 4.10.13-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux 4-core ### What does the code do? TLDR endlessly forks a batch of 8 threads, and waits for them to finish. Each thread calls `observeDuration` on an irrelevant IO action. `observeDuration` measures the time, then updates some data structures in `STM` context in a `TVar`. After a short while (usually within 1 minute), the program aborts with `<>`. See below for a more detailed investigation. ### To run stack install # Restart if doesn't terminate in a minute. loop-exe +RTS -N4 -Ds > debug 2> debug.out ; beep ### Observe `debug` shows the metering batches run for a while, then get stuck. `debug.out` contains `<>`. My debug log reading fu is poor, but in less cleaned-up versions of the program it was more trivial to see that two threads get blocked on each others blackhole. In the current log there is mentioning of blackholes, but also MVars, and I don't see what's going on. ### Tracking down When built with profiling (remove `--eventlog --debug` from cabal file, then `stack clean` then `stack build --profile`), and running with `+RTS -N4 -xc` the following stack traces appear: *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.meter, called from Main.main *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Prometheus.Metric.Summary.observe, called from Prometheus.Metric.Summary.observeDuration, called from Main.meter.action, called from Main.meter.cfork, called from Main.meter, called from Main.main *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Prometheus.Metric.Summary.observe, called from Prometheus.Metric.Summary.observeDuration, called from Main.meter.action, called from Main.meter.cfork, called from Main.meter, called from Main.main *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.meter, called from Main.mainPrometheus.Metric.Summary.observe, called from Prometheus.Metric.Summary.observeDuration, called from Main.meter.action, called from Main.meter.cfork, called from Main.meter, called from Main.main *** Exception (reporting due to +RTS -xc): (IND_STATIC), stack trace: Prometheus.Metric.Summary.observe, called from Prometheus.Metric.Summary.observeDuration, called from Main.meter.action, called from Main.meter.cfork, called from Main.meter, called from Main.main loop-exe: loop-exe: <> <> loop-exe: thread blocked indefinitely in an MVar operation An other stack trace from an other run as bonus (these two are representative): *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Prometheus.Metric.Summary.invariant, called from Prometheus.Metric.Summary.compress, called from Prometheus.Metric.Summary.observe, called from Prometheus.Metric.Summary.observeDuration, called from Main.meter.action, called from Main.meter.cfork, called from Main.meter, called from Main.main *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Prometheus.Metric.Summary.invariant, called from Prometheus.Metric.Summary.compress, called from Prometheus.Metric.Summary.observe, called from Prometheus.Metric.Summary.observeDuration, called from Main.meter.action, called from Main.meter.cfork, called from Main.meter, called from Main.main loop-exe: <> *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.meter, called from Main.main *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.meter, called from Main.main loop-exe: thread blocked indefinitely in an MVar operation I tried to even simplify by removing `prometheus-client` dep, but it seems that the kind of computation done in Prometheus.Metric.Summary.observe, namely putting a lazy computation inside a data type stored in a TVar, are needed to trigger the blackholing. When I tried to simplify those operations, or bang the remaining few fields of the data type, the error didn't reproduce (at least couldn't reproduce as quick as it usually does). The relevant pieces of code from prometheus-client's P.M.Summary module. Note: I manually replaced the `MonadMonitor` constraint with plain IO in that call chain, but it didn't have much effect. {{{#!hs data Estimator = Estimator { estCount :: !Int64 , estSum :: !Double , estQuantiles :: [Quantile] , estItems :: [Item] } deriving (Show) newtype Summary = MkSummary (STM.TVar Estimator) observeDuration :: IO a -> Metric Summary -> IO a observeDuration io metric = do start <- getCurrentTime result <- io end <- getCurrentTime let dt = fromRational $ toRational $ end `diffUTCTime` start withSummary metric dt return result observe :: MonadMonitor m => Double -> Metric Summary -> m () observe v s = withSummary s (insert v) withSummary :: MonadMonitor m => Metric Summary -> (Estimator -> Estimator) -> m () withSummary (Metric {handle = MkSummary valueTVar}) f = doIO $ STM.atomically $ do STM.modifyTVar' valueTVar compress STM.modifyTVar' valueTVar f insert :: Double -> Estimator -> Estimator insert = ... compress :: Estimator -> Estimator compress = ... }}} I checked `insert` and `compress` and they don't seem to be able to loop in any edge case, so this bug is likely an RTS thing. ### Related tickets I found: https://ghc.haskell.org/trac/ghc/ticket/10218 GHC creates incorrect code which throws <> https://ghc.haskell.org/trac/ghc/ticket/10414 : Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 18:54:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 18:54:16 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.12d4bc255e526b86a1e9d7e64d4d0b79@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I just tried building a profiled executable with -fwhole-archive-hs-libs, which seems to only control the -Wl,--gc-sections flag, and it is much faster. I'll replicate my previous setup and try this later today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 19:56:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 19:56:23 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.9aad5ddc88e907f05b3675865d4e4de4@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by facundo.dominguez: @@ -30,1 +30,1 @@ - let __ghc_qq_ = $(parseExp java " 0.0 ") + let __ghc_qq_ = $(quoteExp java " 0.0 ") New description: It happens with inline-java that {{{ [java| 0.0 |] }}} produces a static method in java {{{ Object fresh_name() { return 0.0; } }}} where {{{ double fresh_name() { return 0.0; } }}} would be preferred. This is better because the user would get an error if the expression does not match the expected result type. Examining the type that GHC expects of the quasiquote would allow to build the later variant. However, GHC provides no access to it. The quasiquote desugars as follows: {{{ [java| 0.0 |] ====> $(parseExp java " 0.0 ") }}} We have experimented with a patch that desugars instead like {{{ [java| 0.0 |] ====> let __ghc_qq_ = $(quoteExp java " 0.0 ") in __ghc_qq_ }}} The quasiquoter can learn then of the expected type by doing: {{{ do qqName <- getCurrentQuasiQuoteName addModFinalizer $ reify qqName >>= ... where getCurrentQuasiQuoteName :: Q Name getCurrentQuasiQuoteName = do loc <- TH.location return $ mkName $ "__ghc_qq_" ++ hash loc }}} Where `getCurrentQuasiQuoteName` can be provided in `Language.Haskell.TH.Quote`. This addresses the same concern that I initially intended to solve with the more complex proposal in #12778. I hope to submit a patch this week, but it would be useful if people want to provide some feedback meanwhile. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 19:59:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 19:59:53 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.fedc7a871f2d8b05bed5754943f62dde@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by facundo.dominguez: @@ -23,1 +23,1 @@ - $(parseExp java " 0.0 ") + $(quoteExp java " 0.0 ") New description: It happens with inline-java that {{{ [java| 0.0 |] }}} produces a static method in java {{{ Object fresh_name() { return 0.0; } }}} where {{{ double fresh_name() { return 0.0; } }}} would be preferred. This is better because the user would get an error if the expression does not match the expected result type. Examining the type that GHC expects of the quasiquote would allow to build the later variant. However, GHC provides no access to it. The quasiquote desugars as follows: {{{ [java| 0.0 |] ====> $(quoteExp java " 0.0 ") }}} We have experimented with a patch that desugars instead like {{{ [java| 0.0 |] ====> let __ghc_qq_ = $(quoteExp java " 0.0 ") in __ghc_qq_ }}} The quasiquoter can learn then of the expected type by doing: {{{ do qqName <- getCurrentQuasiQuoteName addModFinalizer $ reify qqName >>= ... where getCurrentQuasiQuoteName :: Q Name getCurrentQuasiQuoteName = do loc <- TH.location return $ mkName $ "__ghc_qq_" ++ hash loc }}} Where `getCurrentQuasiQuoteName` can be provided in `Language.Haskell.TH.Quote`. This addresses the same concern that I initially intended to solve with the more complex proposal in #12778. I hope to submit a patch this week, but it would be useful if people want to provide some feedback meanwhile. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 20:20:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 20:20:01 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.6423dc1aacbc2c51267d661077e2fba9@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * cc: niteria (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 20:20:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 20:20:16 -0000 Subject: [GHC] #9438: panic: loading archives not supported In-Reply-To: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> References: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> Message-ID: <057.3404066a7b872d12d081b05a55ffae46@haskell.org> #9438: panic: loading archives not supported -------------------------------------+------------------------------------- Reporter: egl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #8164 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * os: MacOS X => Unknown/Multiple Comment: This is not an OS X-exclusive error, as you can trigger it with any GHC build that has `DYNAMIC_GHC_PROGRAMS=YES`. For instance, on Linux: {{{ $ ghci -L/usr/lib/llvm-3.9/lib -lLLVMBPFCodeGen GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:11:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:11:24 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.d3eacc927d99764763868ce7a3b7f92b@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "run-test" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:11:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:11:37 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.5bd71126c95ec22f65f1223c6b324f28@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "out" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:15:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:15:13 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.14b5222ecafbe3d576228391f2c258d6@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I have attached a script and my output that exhibits a large slowdown in linking a trivial profiled executable. It times linking a file Main.hs with {{{main = return ()}}} with ghc-8.0.2 and ghc-8.2.0.2017.0522. It shows that the linking times irrespective of -fwhole-archive-hs-libs has slowed considerably, and that -fwhole-archive-hs-libs slows down linking by 4-5x on both ghc versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:17:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:17:21 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.55cf806aca4cd199727ce28ac3ba2f28@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "run-test" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:17:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:17:21 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "run-test" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:26:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:26:12 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.8e79fd1b6183133851ce4280f3d4eee4@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "run-test.2" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:26:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:26:30 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "run-test" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:26:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:26:30 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.27117c724f9375451ae755ec8b15a130@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "run-test" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:26:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:26:42 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "out" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:26:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:26:42 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.26add54bf01479230249ee985f0f8cca@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "out" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:35:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:35:50 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.1743b6a93456f445c79640a13c99bdc9@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is a change to the source language, so you should really make a [https://github.com/ghc-proposals/ghc-proposals GHC propsal] for it. That way you would get good feedback. Is the current TH finaliser design (with the recent modificadtions you put in) written up anywhere? If not, it would be good to do that at the same time. I Utterly Hate the idea of making up a funny name based on the hash of a location, and then having to guess what it is (inside your function `getCurrentQuasiQuoteName`). Yurgh. Could you not arrange that your Java parser, instead of producing some Haskell expression `e`, produced the Haskell expression `let my_name = e in my_name`, where `my_name` is a TH name that you generate. Now you know what it is! But now you'll tell me that it's not in scope in the typechecker's environment when it encounters the quasi-quotes... but then quasi-quotes run in the renamer anyway. I'm very lost as you can see, but the current design just smells wrong to me. There are lots of clever people around GHC. Perhaps if you explain the original problem, and your current solution, someone may have a good idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:35:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:35:52 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms In-Reply-To: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> References: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> Message-ID: <066.d236bbeb776d326fff4c32591e4fd468@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Your `get` is partial, so matching on `LLAM` will throw an exception (instead of failing) when it doesn't match. It's possible to accomplish your purpose thus: {{{#!hs data Yeah = Yeah (forall a. a -> PLambda a) | Nah getYeah :: Lam -> Yeah getYeah l@(L (Lam _)) = Yeah (case l of L (Lam f) -> f; _ -> error "impossible") getYeah _ = Nah pattern LLam :: (forall a. a -> PLambda a) -> Lam pattern LLam x <- (getYeah -> Yeah x) }}} It's pretty ugly, though. You have to first pattern match to determine that the constructor is `Lam`, then pattern match on the same value again under the `Yeah` constructor to capture the polymorphism. If there's a way to avoid that, I don't see it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:37:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:37:55 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.4e031e2c75b96f95887b796c65316404@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "run-test" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:37:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:37:55 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "run-test" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:41:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:41:14 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms In-Reply-To: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> References: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> Message-ID: <066.d9e197cca3d1c270232012e405330875@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think what you'd really want would be to have something like {{{#!hs data PLambda' = Var' (forall a. a) | ... | Lam' (forall a. a -> PLambda a) | ... }}} and then have some non-disgusting way to produce a function {{{#!hs convert :: Lam -> PLambda' }}} As I said, though, I don't see a nice way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:41:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:41:46 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms In-Reply-To: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> References: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> Message-ID: <066.5fe71794174ac8e990e66d8379028afd@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | 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 dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:44:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:44:11 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "run-test" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:44:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:44:11 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.9de453b4516e4b92c1514f826938c20f@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "run-test" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:45:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:45:53 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "out" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:45:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:45:53 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.5b5226f4fc961ee36a887fbcf2bfbbb7@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "out" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:50:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:50:52 -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.d023f549b04a3dcac572365a41110629@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: | Differential Rev(s): Phab:D892 Wiki Page: | Phab:D896 -------------------------------------+------------------------------------- Comment (by simonpj): So is the problem solved (by comment:28) or not? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 21:50:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 21:50:53 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.51ea8c15730940ab344f510e7e33299e@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: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch * differential: => Phab:D3610 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 22:04:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 22:04:02 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.857185a7ed84ecec03d289acaef1d43a@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: QuasiQuotes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12778 | Differential Rev(s): Phab:D3610 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I just submitted the patch with the work in progress I have. But I'm fine further discussing a proposal. > I Utterly Hate the idea of making up a funny name based on the hash of a location ... Well, I hope the programmer doesn't have to do it. The function `getCurrentQuasiQuoteName` would be provided in the template-haskell package for that sake. I hope the test in https://phabricator.haskell.org/D3610 makes clear how it works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 22:25:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 22:25:31 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "out" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 22:25:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 22:25:31 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.81daeb4111af1bc7948d9af5fa41da21@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "out" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 22:25:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 22:25:44 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.2d68a20ffbf053e7d5de06a083915cee@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "run-test" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 24 22:25:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 May 2017 22:25:44 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "run-test" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 01:59:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 01:59:35 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.de18aaebd1b62633599193eb7640aa8c@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks for the script, duog! It'll help me figure out what commit(s) introduced this regression. I did some quick testing on my Ubuntu machine with `gcc-4.8.4`. As baselines, I tested GHC 8.0.2: {{{ real 0m0.299s user 0m0.256s sys 0m0.028s }}} and GHC 8.2.1-rc2: {{{ (Without -fwhole-archive-hs-libs) real 0m12.946s user 0m12.816s sys 0m0.136s (With -fwhole-archive-hs-libs) real 0m2.676s user 0m2.436s sys 0m0.220s }}} I noticed a significant difference around commit b207b536ded40156f9adb168565ca78e1eef2c74 (Generalize kind of the (->) tycon). Before that commit, we have: {{{ Commit efeaf9e436109cb35b491e08b5407c0598108186 (Bump nofib submodule) ------ (Without -fwhole-archive-hs-libs) real 0m4.686s user 0m4.600s sys 0m0.068s (With -fwhole-archive-hs-libs) real 0m0.055s user 0m0.040s sys 0m0.008s }}} And after: {{{ Commit b207b536ded40156f9adb168565ca78e1eef2c74 (Generalize kind of the (->) tycon) ------ (Without -fwhole-archive-hs-libs) real 0m13.047s user 0m12.948s sys 0m0.104s (With -fwhole-archive-hs-libs) real 0m2.696s user 0m2.480s sys 0m0.196s }}} However, the times for commit efeaf9e436109cb35b491e08b5407c0598108186 are still not at parity with GHC 8.0.2, so an earlier commit must have contributed as well. I'll try to track down which one(s). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 02:43:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 02:43:20 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.8482a1b09ce041897b2175f3eec52cbf@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): So... apparently this patch fixes the problem, but I haven't quite figured out why. {{{ diff --git a/compiler/iface/TcIface.hs b/compiler/iface/TcIface.hs index 3a6a4070d2..50fafcdadf 100644 --- a/compiler/iface/TcIface.hs +++ b/compiler/iface/TcIface.hs @@ -908,7 +908,8 @@ tcIfaceDataCons tycon_name tycon tc_tybinders if_cons ; ~(eq_spec, theta, arg_tys, stricts) <- forkM (mk_doc dc_name) $ do { eq_spec <- tcIfaceEqSpec spec ; theta <- tcIfaceCtxt ctxt - ; arg_tys <- mapM tcIfaceType args + ; arg_tys <- forkM (mk_doc dc_name <+> text "arg_tys") + $ mapM tcIfaceType args ; stricts <- mapM tc_strict if_stricts -- The IfBang field can mention -- the type itself; hence inside forkM }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 03:43:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 03:43:30 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.bd0d00f3bf14694253bb805ff33c63d2@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): A bit of good news: I build the commit of `cereal` from just before its `GSerialize` class was split in two. I confirmed that the test case in https://github.com/GaloisInc/cereal/pull/54 caused tick exhaustion in 8.0.2. I found that it worked just fine with a recent GHC build, and continued to do so even when I substantially increased the size of the test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 06:23:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 06:23:19 -0000 Subject: [GHC] #13752: Odd pattern synonym type errors Message-ID: <045.1606ca3f9f49f5ab3dc0f32f4ec61304@haskell.org> #13752: Odd pattern synonym type errors -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose we have {{{#!hs newtype Arrange = Arrange {getArrange :: [Int] -> [Int]} }}} If I write {{{#!hs pattern Heh :: (c ~ ((~) Int)) => (forall a. c a => [a] -> [a]) -> Arrange pattern Heh f <- Arrange f }}} I get {{{ • Couldn't match type ‘[Int] -> [Int]’ with ‘forall a. Int ~ a => [a] -> [a]’ Expected type: forall a. c a => [a] -> [a] Actual type: [Int] -> [Int] • In the declaration for pattern synonym ‘Heh’ }}} It surprises me that these don't match. I can hack around that a bit: {{{#!hs newtype Help = Help {getHelp :: forall a. Int ~ a => [a] -> [a]} pattern Heh :: (c ~ ((~) Int)) => (forall a. c a => [a] -> [a]) -> Arrange pattern Heh f <- ((\x -> Help (getArrange x)) -> Help f) }}} Now this compiles, and I can use it in a variety of ways, but not quite all. If I write {{{#!hs pattern Heh' :: ([Int] -> [Int]) -> Arrange pattern Heh' f <- Heh f }}} I get {{{ Haha.hs:78:23: error: • Couldn't match expected type ‘[Int] -> [Int]’ with actual type ‘forall a. Int ~ a => [a] -> [a]’ • In the declaration for pattern synonym ‘Heh'’ | 78 | pattern Heh' f <- Heh f | ^ }}} This strikes me as perhaps even more surprising. I can hack around that too, of course, but yuck! {{{#!hs pattern Heh' :: ([Int] -> [Int]) -> Arrange pattern Heh' f <- ((\(Heh g) -> g @ Int) -> f) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 07:55:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 07:55:10 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.c2a39e30bccf03af9dafb11cdabac76b@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, so we conclude that the original problem is now fixed? (Albeit we don't quite know how.) If so, great; but let's add a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 08:03:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 08:03:16 -0000 Subject: [GHC] #13306: Problems with type inference for static expressions In-Reply-To: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> References: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> Message-ID: <059.c6da5d13fc7d60372ac7f1363111d34b@haskell.org> #13306: Problems with type inference for static expressions -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): Here's another much simpler test case: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE StaticPointers #-} {-# OPTIONS_GHC -Wall #-} import GHC.StaticPtr data U :: * -> * where UBool :: U Bool UInt :: U Int toDouble :: U a -> StaticPtr (a -> Double) toDouble UBool = static (\x -> if x then 1 else 0) toDouble UInt = static fromIntegral }}} The first line yields "Couldn't match expected type `Bool` with actual type `a`", and the second line yields "No instance for (`Integral a`)". Writing {{{#!hs toDouble UInt = static (fromIntegral :: Int -> Double) }}} instead yields "Couldn't match type `a` with `Int`; but {{{#!hs toDouble UInt = static fromIntegral :: StaticPtr (Int -> Double) }}} ''is'' accepted. If we instead use {{{#!hs fakeStatic :: a -> StaticPtr a fakeStatic = undefined }}} then of course {{{#!hs toDouble :: U a -> StaticPtr (a -> Double) toDouble UBool = fakeStatic (\x -> if x then 1 else 0) toDouble UInt = fakeStatic fromIntegral }}} is accepted as is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 08:47:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 08:47:33 -0000 Subject: [GHC] #13752: Odd pattern synonym type errors In-Reply-To: <045.1606ca3f9f49f5ab3dc0f32f4ec61304@haskell.org> References: <045.1606ca3f9f49f5ab3dc0f32f4ec61304@haskell.org> Message-ID: <060.fda3166dffa2793060c1270b67707cd1@haskell.org> #13752: Odd pattern synonym type errors -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 10:59:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 10:59:26 -0000 Subject: [GHC] #13752: Odd pattern synonym type errors In-Reply-To: <045.1606ca3f9f49f5ab3dc0f32f4ec61304@haskell.org> References: <045.1606ca3f9f49f5ab3dc0f32f4ec61304@haskell.org> Message-ID: <060.90550f9edce430a6c807b51b1c1f64ee@haskell.org> #13752: Odd pattern synonym type errors -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c9977385dca9536f18374242f713b1048a38dec5/ghc" c997738/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c9977385dca9536f18374242f713b1048a38dec5" Pattern synonyms and higher rank types This patch fixes two separate bugs which contributed to making Trac #13752 go wrong 1. We need to use tcSubType, not tcUnify, in tcCheckPatSynDecl.tc_arg. Reason: Note [Pattern synonyms and higher rank types] 2. TcUnify.tc_sub_type had a special case designed to improve error messages; see Note [Don't skolemise unnecessarily]. But the special case was too liberal, and ended up using unification (which led to rejecting the program) when it should instead taken the normal path (which accepts the program). I fixed this by making the test more conservative. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 11:01:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 11:01:45 -0000 Subject: [GHC] #13751: Runtime crash with <> after concurrent stressing of STM computatinos. In-Reply-To: <046.2e620bb56fd39fe88732c85fa515dde8@haskell.org> References: <046.2e620bb56fd39fe88732c85fa515dde8@haskell.org> Message-ID: <061.8248c08e2a892e963f7e5f1320569020@haskell.org> #13751: Runtime crash with <> after concurrent stressing of STM computatinos. -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: 10414 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * priority: normal => highest * component: Compiler => Runtime System * milestone: => 8.2.1 Comment: This definitely looks bad. Thanks for reporting and for making a test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 11:30:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 11:30:36 -0000 Subject: [GHC] #13718: diagnostic colors: differentiate between message head and message body In-Reply-To: <044.d0c2ce3e08b76e30b998d2f85762a984@haskell.org> References: <044.d0c2ce3e08b76e30b998d2f85762a984@haskell.org> Message-ID: <059.7feda4319c7cff7468e3f49cbd099d10@haskell.org> #13718: diagnostic colors: differentiate between message head and message body -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13444 | Differential Rev(s): phab:D3599 Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): Thanks! For the record, using {{{GHC_COLORS="message=0:header=1"}}} now gets me the coloring I wanted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 11:34:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 11:34:26 -0000 Subject: [GHC] #13752: Odd pattern synonym type errors In-Reply-To: <045.1606ca3f9f49f5ab3dc0f32f4ec61304@haskell.org> References: <045.1606ca3f9f49f5ab3dc0f32f4ec61304@haskell.org> Message-ID: <060.a64a60e2c65daafa25dabf8379b1b421@haskell.org> #13752: Odd pattern synonym type errors -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | patsyn/should_compile/T13752, | T13752a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => patsyn/should_compile/T13752, T13752a * status: new => merge Comment: A bit of a dark corner, but could merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 12:04:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 12:04:50 -0000 Subject: [GHC] #13753: Improve GHC's ghc package environment lookup logic Message-ID: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> #13753: Improve GHC's ghc package environment lookup logic -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Documentation for package enviroments which describes the current lookup logic: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.html #package-environments There's two things I'd like to improve: 1. Define a special magic "null" environment, which instructs GHC to ignore any package environment files. To this end, I propose to use the name `-` (i.e. a single dash), as that is more portable than using the empty string for environment variables. In other words: * `-package-env -` or * `GHC_ENVIRONMENT=-` (unless a `-package-env` flag which has higher priority overrides it) would prevent GHC from interpreting any package environment files. 2. Provide a way to disambiguate environment names (i.e. those that are looked up in `$HOME/.ghc/arch-os-version/environments/name`) and environment files arguments. Currently, if you say `GHC_ENVIRONMENT=test` then a local file `test` would shadow the environment named `test` which would result in rather confusing errors. Instead I suggest to have package-env identifiers be interpreted as "names" by default, and only if they look like relative or absolute paths (i.e. `./foobar` or `/home/foo/...`) be interpreted as file locations (relative to $CWD). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 13:55:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 13:55:57 -0000 Subject: [GHC] #13754: ghc-8.0.2+ rejects more instance declarations Message-ID: <045.2c073fad5538a664e246f9600c2e9877@haskell.org> #13754: ghc-8.0.2+ rejects more instance declarations -------------------------------------+------------------------------------- Reporter: zilinc | 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: -------------------------------------+------------------------------------- Sorry for the vague title. For a program (sorry again but I failed to shrink it further): {{{ {-# language ExistentialQuantification, KindSignatures, DataKinds, GADTs, UndecidableInstances, AllowAmbiguousTypes #-} class Pretty a where pretty :: a -> String prettyList :: [a] -> String prettyList = concatMap pretty data Def e = forall t. FunDef (Type t) (e t) data Nat = Z | S Nat data F (t :: Nat) where FZ :: F (S Z) FS :: F n -> F (S n) data Type (t :: Nat) = TVar (F t) data Expr (t :: Nat) e = Fun (Type t) | App (e t) (e t) data TE t = TE (Type t) (Expr t TE) -- all methods left undefined, as they're insignificant instance Pretty t => Pretty [t] where pretty = undefined instance (Pretty (e t)) => Pretty (Def e) where pretty (FunDef t e) = undefined instance Pretty (Type t) where pretty (TVar t) = undefined instance Pretty (e t) => Pretty (Expr t e) where pretty (Fun t) = undefined pretty (App e1 e2) = undefined instance Pretty (TE t) where pretty (TE t e) = undefined }}} ghc-8.0.1 is happy with it, whereas later versions (tested with 8.0.2 and 8.2.1-rc2) reject it. The error msg is: {{{ GHCInstance1.hs:27:10: error: • Could not deduce (Pretty (e t0)) arising from a use of ‘Main.$dmprettyList’ from the context: Pretty (e t) bound by the instance declaration at GHCInstance1.hs:27:10-41 The type variable ‘t0’ is ambiguous Relevant bindings include prettyList :: [Def e] -> String (bound at GHCInstance1.hs:27:10) • In the expression: Main.$dmprettyList @Def e In an equation for ‘prettyList’: prettyList = Main.$dmprettyList @Def e In the instance declaration for ‘Pretty (Def e)’ }}} If I comment out the `prettyList` method from the class definition, then all happy. I'm not sure if it's a bug in 8.0.1 or a regression (and hard to reason about the behaviours). If it was the later, how should I migrate from 8.0.1? The `Pretty` class is a library (e.g. ansi-wl-pprint) so no way I can change it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 14:03:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 14:03:29 -0000 Subject: [GHC] #13755: GHC-8.0.2+ spits out $dm names in error messages Message-ID: <045.94799c1fd2792bf520b6bd3c5f2df5b1@haskell.org> #13755: GHC-8.0.2+ spits out $dm names in error messages -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (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: -------------------------------------+------------------------------------- Example (copied from #12881) {{{ {-# LANGUAGE FlexibleInstances #-} module Bug where class Arbitrary a where shrink :: a -> [a] shrink _ = [] instance Arbitrary a instance Arbitrary Int }}} Error message is: {{{ GHCInstance.hs:10:10: error: • Overlapping instances for Foo Int arising from a use of ‘Main.$dmfoo’ Matching instances: instance Foo a -- Defined at GHCInstance.hs:9:10 instance Foo Int -- Defined at GHCInstance.hs:10:10 • In the expression: Main.$dmfoo @Int In an equation for ‘foo’: foo = Main.$dmfoo @Int In the instance declaration for ‘Foo Int’ }}} Another example: code in #13754 description. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 14:32:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 14:32:04 -0000 Subject: [GHC] #13756: Typo in user guide suggests that there's an -O* option Message-ID: <042.6a3b1c429314348df414591c312b566f@haskell.org> #13756: Typo in user guide suggests that there's an -O* option -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | 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: -------------------------------------+------------------------------------- In https://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide /options-optimise.html it still correctly said: {{{ No -O*-type option specified: This is taken to mean: “Please compile quickly ... }}} But in https://downloads.haskell.org/~ghc/latest/docs/html/users_guide /using-optimisation.html#ghc-flag--O* it says: {{{ -O* This is taken to mean: “Please compile quickly ... }}} The `No -O*-type option specified:` bit must have been accidentally dropped in the conversion to the new user guide format. (I dared put this into 8.2.1 because it's probably trivial to fix if one understands the syntax language that the user guide is written in.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 14:43:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 14:43:44 -0000 Subject: [GHC] #13754: ghc-8.0.2+ rejects more instance declarations In-Reply-To: <045.2c073fad5538a664e246f9600c2e9877@haskell.org> References: <045.2c073fad5538a664e246f9600c2e9877@haskell.org> Message-ID: <060.f4e26b420c522cf02e20a7733a3c7a68@haskell.org> #13754: ghc-8.0.2+ rejects more instance declarations -------------------------------------+------------------------------------- Reporter: zilinc | 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): The error message is not great, but here is what is happening. The default method in the class decl generates {{{ $dmpretttyList :: forall a. Pretty a => [a] -> SDoc $dmprettyList = concatMap pretty }}} That seems reasonable. Now in the instance decl it's as if you had written {{{ instance (Pretty (e t)) => Pretty (Def e) where pretty = ... prettyList = $dmprettyList @(Def e) }}} From the call to `$dmprettyList` we get a "wanted" constraint `Pretty (Def e)`. That simplifies, via the instance decl itself, to `Pretty (e t0)`, where `t0` is a fresh unification varaible. Hence the message you see. But your instance declaration is deeply strange anyway, becuase the `t` is completely unconstrained. Having a "given" `(Pretty (e t)` isn't much use if we know nothing about `t`. (There is nothing wrong with the class, just the instance.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 14:52:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 14:52:17 -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.9258b115905fcf1aef16799b3fad4fad@haskell.org> #13753: Improve GHC's ghc package environment lookup logic -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 14:59:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 14:59:21 -0000 Subject: [GHC] #13755: GHC-8.0.2+ spits out $dm names in error messages In-Reply-To: <045.94799c1fd2792bf520b6bd3c5f2df5b1@haskell.org> References: <045.94799c1fd2792bf520b6bd3c5f2df5b1@haskell.org> Message-ID: <060.bd0a6330a7302600e2b784fe544f7424@haskell.org> #13755: GHC-8.0.2+ spits out $dm names in error messages -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 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: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -17,2 +17,3 @@ - • Overlapping instances for Foo Int - arising from a use of ‘Main.$dmfoo’ + T13755.hs:9:10: error: + • Overlapping instances for Arbitrary Int + arising from a use of ‘Bug.$dmshrink’ @@ -20,5 +21,5 @@ - instance Foo a -- Defined at GHCInstance.hs:9:10 - instance Foo Int -- Defined at GHCInstance.hs:10:10 - • In the expression: Main.$dmfoo @Int - In an equation for ‘foo’: foo = Main.$dmfoo @Int - In the instance declaration for ‘Foo Int’ + instance Arbitrary a -- Defined at T13755.hs:8:10 + instance Arbitrary Int -- Defined at T13755.hs:9:10 + • In the expression: Bug.$dmshrink @Int + In an equation for ‘shrink’: shrink = Bug.$dmshrink @Int + In the instance declaration for ‘Arbitrary Int’ New description: Example (copied from #12881) {{{ {-# LANGUAGE FlexibleInstances #-} module Bug where class Arbitrary a where shrink :: a -> [a] shrink _ = [] instance Arbitrary a instance Arbitrary Int }}} Error message is: {{{ GHCInstance.hs:10:10: error: T13755.hs:9:10: error: • Overlapping instances for Arbitrary Int arising from a use of ‘Bug.$dmshrink’ Matching instances: instance Arbitrary a -- Defined at T13755.hs:8:10 instance Arbitrary Int -- Defined at T13755.hs:9:10 • In the expression: Bug.$dmshrink @Int In an equation for ‘shrink’: shrink = Bug.$dmshrink @Int In the instance declaration for ‘Arbitrary Int’ }}} Another example: code in #13754 description. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 15:00:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 15:00:21 -0000 Subject: [GHC] #13755: GHC-8.0.2+ spits out $dm names in error messages In-Reply-To: <045.94799c1fd2792bf520b6bd3c5f2df5b1@haskell.org> References: <045.94799c1fd2792bf520b6bd3c5f2df5b1@haskell.org> Message-ID: <060.9660d91cafdb86481e77cdbc8b9118ec@haskell.org> #13755: GHC-8.0.2+ spits out $dm names in error messages -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 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 simonpj): I agree it's not great. But it's hard even to say what we'd ''like'' it to say, given that the error arises from filling in the default methods. What would you like it to say? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 17:34:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 17:34:12 -0000 Subject: [GHC] #13752: Odd pattern synonym type errors In-Reply-To: <045.1606ca3f9f49f5ab3dc0f32f4ec61304@haskell.org> References: <045.1606ca3f9f49f5ab3dc0f32f4ec61304@haskell.org> Message-ID: <060.2978f7305ff7adb25bbb02176eab6634@haskell.org> #13752: Odd pattern synonym type errors -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | patsyn/should_compile/T13752, | T13752a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Wow, that was fast! Thanks! It may be a dark corner today. However, if my proposal to add type signatures to pattern synonym builders ends up going through with the committee-requested restriction to allow the signatures to vary only in constraints, I think we'll likely see more such code as people hack around the restriction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 20:08:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 20:08:19 -0000 Subject: [GHC] #13755: GHC-8.0.2+ spits out $dm names in error messages In-Reply-To: <045.94799c1fd2792bf520b6bd3c5f2df5b1@haskell.org> References: <045.94799c1fd2792bf520b6bd3c5f2df5b1@haskell.org> Message-ID: <060.d524647de861b46c817c2a0784162b6c@haskell.org> #13755: GHC-8.0.2+ spits out $dm names in error messages -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #10087 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #10087 Comment: #10087 is very closely related to this ticket. The context of #10087 is a bit different since it was talking about `DefaultSignatures`, e.g., {{{#!hs {-# LANGUAGE DefaultSignatures #-} class C a where reflexive :: a -> Bool default reflexive :: Eq a => a -> Bool reflexive x = x == x data D instance C D where }}} {{{ /home/abel/play/haskell/bugs/DefaultSig.hs:10:10: No instance for (Eq D) arising from a use of ‘Main.$gdmreflexive’ In the expression: Main.$gdmreflexive In an equation for ‘reflexive’: reflexive = Main.$gdmreflexive In the instance declaration for ‘C D’ }}} The consensus on that ticket is that we should instead print an error message to the effect of: {{{ No instance for (Eq D) arising from the generic default method for `reflexive` In the instance declaration for ‘C D’ }}} Following the same principle, I think an ideal error message for your particular example would be: {{{ • Overlapping instances for Arbitrary Int arising from a default implementation of `shrink` ... • In the instance declaration for ‘Arbitrary Int’ }}} Do you agree, zilinc? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 20:09:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 20:09:19 -0000 Subject: [GHC] #10087: DefaultSignatures: error message mentions internal name In-Reply-To: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> References: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> Message-ID: <066.868b14a38ee236c19de36b3352924c8f@haskell.org> #10087: DefaultSignatures: error message mentions internal name -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #13755 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13755 Comment: See also #13755, which deals with default implementations instead of generic default implementations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 20:30:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 20:30:14 -0000 Subject: [GHC] #8703: Use guard pages rather than heap checks In-Reply-To: <046.cc8df1f4c44d21b3204aafaf538413fa@haskell.org> References: <046.cc8df1f4c44d21b3204aafaf538413fa@haskell.org> Message-ID: <061.55746d3438358d63d47412548ccfc64e@haskell.org> #8703: Use guard pages rather than heap checks -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 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 simonmar): For rationale on why GHC's heap is divided into blocks, see this paper: http://simonmar.github.io/bib/papers/parallel-gc.pdf Changing the structure of the heap is a MASSIVE change. If you really think it's worthwhile, I suggest building a proof-of-concept prototype and obtain some measurements. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 21:21:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 21:21:54 -0000 Subject: [GHC] #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted In-Reply-To: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> References: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> Message-ID: <060.c3b083f5d0c584a39aed0db8da9d5557@haskell.org> #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: simplifier | ticks Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: dynamic-paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): I think we get different results because I am using rc2 and you are using head. With the testsuite distributed with rc2 divergence is classified as failure when it seems it should be classified as success -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 21:43:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 21:43:15 -0000 Subject: [GHC] #8703: Use guard pages rather than heap checks In-Reply-To: <046.cc8df1f4c44d21b3204aafaf538413fa@haskell.org> References: <046.cc8df1f4c44d21b3204aafaf538413fa@haskell.org> Message-ID: <061.e472c660d402d3e879af6b6638317288@haskell.org> #8703: Use guard pages rather than heap checks -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 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 simonpj): FWIW I believe that in other systems (e.g. ML) they started using guard pages, and moved away from it becuase it was SO HARD to make it work: on different archiectures and OSs, accommodating the non-standard calling conventions we use; dealing with correct GC of the registers that are saved on the trap; dealing with the fact that the stack we have is tiny, unlike the OS stack. If I had 1,000 hours to invest, I would invest it elsewhere. I'm not saying you couldn't make progress here, just that I think you'll find a better cost/benefit ratio elsewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 22:56:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 22:56:50 -0000 Subject: [GHC] #13729: ghc does not pick up TH changes across package boundaries In-Reply-To: <048.c28ecbc30553d679f691354a7861c80a@haskell.org> References: <048.c28ecbc30553d679f691354a7861c80a@haskell.org> Message-ID: <063.dd689026c2c80523145b56ce881d042d@haskell.org> #13729: ghc does not pick up TH changes across package boundaries -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 25 23:06:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 May 2017 23:06:00 -0000 Subject: [GHC] #13755: GHC-8.0.2+ spits out $dm names in error messages In-Reply-To: <045.94799c1fd2792bf520b6bd3c5f2df5b1@haskell.org> References: <045.94799c1fd2792bf520b6bd3c5f2df5b1@haskell.org> Message-ID: <060.a791223f7de77b457094bdc5af32f6a5@haskell.org> #13755: GHC-8.0.2+ spits out $dm names in error messages -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #10087 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zilinc): Thanks Ryan --- I didn't know the internal name leakage had been an issue for quite a while. As a '''user''', if I didn't know what `$dm` or `$gdm` means, it could be hard to see `$dgmreflective` actually refers to `reflective`, esp. there's no delimiter between the prefix and the real name. The bottom line for me, personally, is to avoid the `$` prefixes (stepping back even further, if we couldn't, at least explain it in the user guide). If we could do better, Ryan's suggestion makes perfect sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 03:01:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 03:01:57 -0000 Subject: [GHC] #13747: Can't use 'instance' keyword in associated type family instance In-Reply-To: <042.cfa21cd9140248a25075b778770d0326@haskell.org> References: <042.cfa21cd9140248a25075b778770d0326@haskell.org> Message-ID: <057.232f6a4d60f676fba170c16daaafd6ca@haskell.org> #13747: Can't use 'instance' keyword in associated type family instance -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomer Comment: This sounds reasonable to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 03:50:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 03:50:04 -0000 Subject: [GHC] #13754: ghc-8.0.2+ rejects more instance declarations In-Reply-To: <045.2c073fad5538a664e246f9600c2e9877@haskell.org> References: <045.2c073fad5538a664e246f9600c2e9877@haskell.org> Message-ID: <060.55ae42af6778222be6d12323c9fb4d51@haskell.org> #13754: ghc-8.0.2+ rejects more instance declarations -------------------------------------+------------------------------------- Reporter: zilinc | 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 zilinc): Thanks Simon for the excellent explanation. So shall I conclude it's a bug which has been fixed in GHC-8.0.2 (and thus close this ticket)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 03:51:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 03:51:05 -0000 Subject: [GHC] #13754: ghc-8.0.2+ rejects more instance declarations In-Reply-To: <045.2c073fad5538a664e246f9600c2e9877@haskell.org> References: <045.2c073fad5538a664e246f9600c2e9877@haskell.org> Message-ID: <060.d7a0dd360af38b4ab197ac1af0fedf69@haskell.org> #13754: ghc-8.0.2+ rejects more instance declarations -------------------------------------+------------------------------------- Reporter: zilinc | 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 zilinc): * version: 8.0.2 => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 08:38:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 08:38:04 -0000 Subject: [GHC] #13754: ghc-8.0.2+ rejects more instance declarations In-Reply-To: <045.2c073fad5538a664e246f9600c2e9877@haskell.org> References: <045.2c073fad5538a664e246f9600c2e9877@haskell.org> Message-ID: <060.e1f39eb2186c07c91477d4b5f8410861@haskell.org> #13754: ghc-8.0.2+ rejects more instance declarations -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: > So shall I conclude it's a bug which has been fixed in GHC-8.0.2 More "it wasn't a bug in the first place". Except for the bad error message, which is covered by #13755 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 08:54:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 08:54:55 -0000 Subject: [GHC] #13754: ghc-8.0.2+ rejects more instance declarations In-Reply-To: <045.2c073fad5538a664e246f9600c2e9877@haskell.org> References: <045.2c073fad5538a664e246f9600c2e9877@haskell.org> Message-ID: <060.6be5dc34c0291427af5bc370c4cc7127@haskell.org> #13754: ghc-8.0.2+ rejects more instance declarations -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zilinc): Replying to [comment:4 simonpj]: > > So shall I conclude it's a bug which has been fixed in GHC-8.0.2 > > More "it wasn't a bug in the first place". > Sorry I don't get you then --- why it's not rejected by earlier (<8.0.2) versions of GHC? Can you please give some hints? If I hadn't tried GHC-8.0.2 I would never uncover this bug in my program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 08:55:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 08:55:09 -0000 Subject: [GHC] #13674: Poor error message which masks occurs-check failure In-Reply-To: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> References: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> Message-ID: <065.777a5f3af0d1081354c768ffa4131f40@haskell.org> #13674: Poor error message which masks occurs-check failure -------------------------------------+------------------------------------- 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c2eea089e7978416c6882a5456117db27b8f45ba/ghc" c2eea08/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c2eea089e7978416c6882a5456117db27b8f45ba" Make isInsolubleOccursCheck more aggressive Consider type family F a :: * -> * Then (a ~ F Int a) is an insoluble occurs check, and can be reported as such. Previous to this patch, TcType.isInsolubleOccursCheck was treating any type-family application (including an over-saturated one) as unconditionally not-insoluble. This really only affects error messages, and then only slightly. I tripped over this when investigating Trac #13674. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 08:55:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 08:55:09 -0000 Subject: [GHC] #13674: Poor error message which masks occurs-check failure In-Reply-To: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> References: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> Message-ID: <065.b7fa30b34ea9dd59226aa6b94bb88004@haskell.org> #13674: Poor error message which masks occurs-check failure -------------------------------------+------------------------------------- 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8dc6d645fc3384b3b8ded0578939f5c855dd2ed5/ghc" 8dc6d645/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8dc6d645fc3384b3b8ded0578939f5c855dd2ed5" Re-engineer Given flatten-skolems The big change here is to fix an outright bug in flattening of Givens, albeit one that is very hard to exhibit. Suppose we have the constraint forall a. (a ~ F b) => ..., (forall c. ....(F b)...) ... Then - we'll flatten the (F) b to a fsk, say (F b ~ fsk1) - we'll rewrite the (F b) inside the inner implication to 'fsk1' - when we leave the outer constraint we are suppose to unflatten; but that fsk1 will still be there - if we re-simplify the entire outer implication, we'll re-flatten the Given (F b) to, say, (F b ~ fsk2) Now we have two fsks standing for the same thing, and that is very wrong. Solution: make fsks behave more like fmvs: - A flatten-skolem is now a MetaTyVar, whose MetaInfo is FlatSkolTv - We "fill in" that meta-tyvar when leaving the implication - The old FlatSkol form of TcTyVarDetails is gone completely - We track the flatten-skolems for the current implication in a new field of InertSet, inert_fsks. See Note [The flattening story] in TcFlatten. In doing this I found various other things to fix: * I removed the zonkSimples from TcFlatten.unflattenWanteds; it wasn't needed. But I added one in TcSimplify.floatEqualities, which does the zonk precisely when it is needed. * Trac #13674 showed up a case where we had - an insoluble Given, e.g. a ~ [a] - the same insoluble Wanted a ~ [a] We don't use the Given to rewwrite the Wanted (obviously), but we therefore ended up reporting Can't deduce (a ~ [a]) from (a ~ [a]) which is silly. Conclusion: when reporting errors, make the occurs check "win" See Note [Occurs check wins] in TcErrors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 08:56:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 08:56:52 -0000 Subject: [GHC] #13754: ghc-8.0.2+ rejects more instance declarations In-Reply-To: <045.2c073fad5538a664e246f9600c2e9877@haskell.org> References: <045.2c073fad5538a664e246f9600c2e9877@haskell.org> Message-ID: <060.90509d6fa355130aa5fcc9a22afef0f0@haskell.org> #13754: ghc-8.0.2+ rejects more instance declarations -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > why it's not rejected by earlier (<8.0.2) versions of GHC I'm not certain, but I think it's because they had a slightly different implementation of instance declarations that had a fragile special case that happened to work. But it's better now; more robust. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 08:59:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 08:59:05 -0000 Subject: [GHC] #13674: Poor error message which masks occurs-check failure In-Reply-To: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> References: <050.bcca1a73e13f9b43aac8d00cb594eecd@haskell.org> Message-ID: <065.bc7b041aac49bd2432c18e57a868b7cc@haskell.org> #13674: Poor error message which masks occurs-check failure -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | indexed_types/should_fail/T13674 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed_types/should_fail/T13674 * resolution: => fixed Comment: This was a very interesting ticket that showed up quite a deep bug. Thanks! I don't think this is worth merging. It's a very dark corner, the change is significant, and there's a chance that I've done something wrong (notwithstanding validate). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 09:35:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 09:35:00 -0000 Subject: [GHC] #13755: GHC-8.0.2+ spits out $dm names in error messages In-Reply-To: <045.94799c1fd2792bf520b6bd3c5f2df5b1@haskell.org> References: <045.94799c1fd2792bf520b6bd3c5f2df5b1@haskell.org> Message-ID: <060.caf889e57748b375535c94821bf313af@haskell.org> #13755: GHC-8.0.2+ spits out $dm names in error messages -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #10087 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Fixing this infelicity isn't fundamentally hard, but it's a bit fiddly. I can advise if anyone (Ryan?) wants to take it up. The challenge is this: * In an instance declaration, the default method {{{ reflextive = $dgmreflective @ty }}} is generated as `HsSyn Name`; and then fed to the type checker. There are excellent reasons for doing this, rather than (say) generating something in already-typechecked form. * (Something similar happens for ordinary default methods, but it'd be `$dmreflective`. * When typechecking this binding the typechecker doesn't a-prori know that it's special, with a funny name in it. * So the typechecker needs to "know" somehow that this `Id` is special. One way to do that would be to add a form of `IdDetails` to say "I'm a default method Id". Then the "arising from ..." stuff could print a better message. * That would not be hard; these Ids are built in one place, by `mkDefaultMethodIds`. I have not worked out all the details, but am happy to advise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 09:57:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 09:57:49 -0000 Subject: [GHC] #13757: Are you for or against writing "otherwise" as a keyword? Message-ID: <044.a4fc99e00f379531d171337bd3da9d21@haskell.org> #13757: Are you for or against writing "otherwise" as a keyword? -------------------------------------+------------------------------------- Reporter: vanto | 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: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{otherwise}}} is frequently used and therefore should have been written as a keyword.\\ {{{otherwise}}} was coded in prelude like this {{{otherwise = True}}}\\ So what is the reason that {{{otherwise}}} was not coded as a keyword?\\ \\ To understand you have to go back. It seems that this has been done to minimize the number of keywords.\\ Today it seems surprising. And I wonder why we wrote the conditional expression with {{{if}}}{{{then}}}{{{else}}}? That's three additional keywords.\\ \\ It would have been better to write the conditional expression as in Sasl {{{condition -> exp1 ; exp22}}} (By adapting the operators of course.)\\ Let's go back to {{{otherwise}}} . And take a look at this code.\\ {{{ otherwise :: Bool otherwise = Prelude.otherwise sig :: Integer -> Integer sig n | a = -1 | b = 0 | Main.otherwise = 1 where { a = n < 0; b = n == 0 } z :: Bool z = if Main.otherwise == Prelude.otherwise then True else False main :: IO () main = do { print (sig 0); print (z) } }}} This code works but the compiler result is different by adding or removing the first two lines of code.\\ For me it is urgent that {{{otherwise}}} become a keyword as in Miranda. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 12:22:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 12:22:37 -0000 Subject: [GHC] #13677: Incorrect parenthesization of type in error message In-Reply-To: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> References: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> Message-ID: <065.6e79d9c73771e400b412f64570105bf2@haskell.org> #13677: Incorrect parenthesization of type in error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3570 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ad14efd539377aaf472ad69449dcaf3e679b0e51/ghc" ad14efd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ad14efd539377aaf472ad69449dcaf3e679b0e51" Some tidying up of type pretty-printing Triggered by the changes in #13677, I ended up doing a bit of refactoring in type pretty-printing. * We were using TyOpPrec and FunPrec rather inconsitently, so I made it consisent. * That exposed the fact that we were a bit undecided about whether to print a + b -> c + d vs (a+b) -> (c+d) and similarly a ~ [b] => blah vs (a ~ [b]) => blah I decided to make TyOpPrec and FunPrec compare equal (in BasicTypes), so (->) is treated as equal precedence with other type operators, so you get the unambiguous forms above, even though they have more parens. We could readily reverse this decision. See Note [Type operator precedence] in BasicTypes * I fixed a bug in pretty-printing of HsType where some parens were omitted by mistake. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 12:23:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 12:23:31 -0000 Subject: [GHC] #13677: Incorrect parenthesization of type in error message In-Reply-To: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> References: <050.2586ea02d4ecbaa22baa1d92c228ffbd@haskell.org> Message-ID: <065.e0919bd9ca1c760951683a095a3dd648@haskell.org> #13677: Incorrect parenthesization of type in error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3570 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): PS: no need to merge this... just tidying up -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 13:18:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 13:18:33 -0000 Subject: [GHC] #10421: exponential blowup in inlining (without INLINE pragmas) In-Reply-To: <047.3eae2ebffed9a4a3ca74833c7f8bcec3@haskell.org> References: <047.3eae2ebffed9a4a3ca74833c7f8bcec3@haskell.org> Message-ID: <062.75ac780fec6ce3db46b42c364ca99068@haskell.org> #10421: exponential blowup in inlining (without INLINE pragmas) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thank you! Looking at the code, it looks just like #13253. Clearly something is wrong here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 13:18:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 13:18:54 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.32143a8230179516e338bb2ba0dbe65d@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | 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): See #10421 for another example. We should investigate this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 13:23:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 13:23:09 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.1cb6d047381158a5ceb85e660085691b@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF -------------------------------------+------------------------------------- Reporter: tibbe | Owner: kavon Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kavon): * owner: (none) => kavon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 15:28:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 15:28:28 -0000 Subject: [GHC] #13750: GHC produces incorrect coercions in hairy code In-Reply-To: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> References: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> Message-ID: <060.f8673f11d79869b9b3381ec457c686b9@haskell.org> #13750: GHC produces incorrect coercions in hairy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #13429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well this is embarrassing. I did take a quick look. The test program is littered with `unsafeCoerce` which makes it harder to determine where things actually go wrong. I still think the "decideQuantification" patch is fine; I think it is just exposing bugs elsewhere. I discovered that (like #13429), adding `-fno-specialise` (to switch off the specialiser) makes it work again. So that may be a workaround for Andres. I'm not against reverting the "decideQauntification" patch as an expedient way to make the release work; but that would re-introduce the bugs that the patch cured. I'm on holiday now for a week, I'm afraid. It'd be great if someone was able to characterise more precisely what is going wrong. At the moment I have no clue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 15:31:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 15:31:29 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.712b3529fb1d6a5fa6fe169363e83989@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #13750 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Further to comment:17 I have made no further progress, and now I'm away for a week. Hmm. I think that disabling specialisation (by `specImports`) for imported dictinoary functions would probably cure it, at some modest cost in optimisation. Might be worth a try as a temporary expedient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 15:31:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 15:31:49 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.175cffe52651f6e067028a0277d82d6d@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: rwbarton (added) Comment: Commit 283acec1d7307fdbd8cd7b3f1d984a036366d6b4 (Make split sections by default work again) is what caused the other regression. Before that commit, I obtained these times with duog's script: {{{ (Without -fwhole-archive-hs-libs) real 0m0.306s user 0m0.260s sys 0m0.028s (With -fwhole-archive-hs-libs) real 0m0.056s user 0m0.036s sys 0m0.012s }}} Notice that the `-fwhole-archive-hs-libs` times are pretty much identical to the GHC 8.0.2 times I found in comment:9. After that commit, I obtained: {{{ (Without -fwhole-archive-hs-libs) real 0m4.656s user 0m4.548s sys 0m0.088s (With -fwhole-archive-hs-libs) real 0m0.056s user 0m0.040s sys 0m0.008s }}} Which is basically identical to the times I found pre- b207b536ded40156f9adb168565ca78e1eef2c74. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 16:18:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 16:18:42 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.0967cd040d22bf5a2b91aedf73c188bb@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For reference, I decided to compare two builds of GHC 8.2.1-rc2 with and without reverting commit 283acec1d7307fdbd8cd7b3f1d984a036366d6b4, and the difference is astounding. If you revert commit 283acec1d7307fdbd8cd7b3f1d984a036366d6b4, you get: {{{ (Without -fwhole-archive-hs-libs) real 0m0.277s user 0m0.224s sys 0m0.036s (With -fwhole-archive-hs-libs) real 0m5.447s user 0m5.104s sys 0m0.328s }}} And if you use plain 8.2.1-rc2 (without reverting commit 283acec1d7307fdbd8cd7b3f1d984a036366d6b4), you get: {{{ (Without -fwhole-archive-hs-libs) real 0m13.648s user 0m12.716s sys 0m0.156s (With -fwhole-archive-hs-libs) real 0m3.077s user 0m2.500s sys 0m0.216s }}} So that commit at least explains the differences without the use of the `-fwhole-archive-hs-libs` flag. However, it doesn't account for the jump in times _with_ the the `-fwhole-archive-hs-libs` flag. I'll try investigating that next. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 16:26:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 16:26:23 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.058266edd0972d7ae9a85a9940e54dde@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Oops, please ignore the noise about `-fwhole-archive-hs-libs` above. I forgot that the commit which introduced `-fwhole-archive-hs-libs` (a6874e546294173c166859769dd8054887a6ded7) didn't come until //after// 283acec1d7307fdbd8cd7b3f1d984a036366d6b4 (Make split sections by default work again), so the times I got above were just from GHC erroring out. (I suppressed the stdout/stderr to avoid flooding my terminal, so I didn't notice this happening.) Also, an observation that I meant to make earlier is that I think that b207b536ded40156f9adb168565ca78e1eef2c74 (Generalize kind of the (->) tycon), which I singled out in comment:9, is a red herring. I think commit 283acec1d7307fdbd8cd7b3f1d984a036366d6b4 (Make split sections by default work again) is the true culprit that causes a bad constant factor for each additional linked symbol, and commit b207b536ded40156f9adb168565ca78e1eef2c74 just happened to add a bunch of extra symbols. This is further evidenced by the fact that reverting 283acec1d7307fdbd8cd7b3f1d984a036366d6b4 alone brings the link time back down to the same as what I get with GHC 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 16:34:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 16:34:58 -0000 Subject: [GHC] #13751: Runtime crash with <> after concurrent stressing of STM computations (was: Runtime crash with <> after concurrent stressing of STM computatinos.) In-Reply-To: <046.2e620bb56fd39fe88732c85fa515dde8@haskell.org> References: <046.2e620bb56fd39fe88732c85fa515dde8@haskell.org> Message-ID: <061.2f7d79d9f57a869ba38cc1e9e995d25e@haskell.org> #13751: Runtime crash with <> after concurrent stressing of STM computations -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: 10414 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 17:04:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 17:04:14 -0000 Subject: [GHC] #13751: Runtime crash with <> after concurrent stressing of STM computations In-Reply-To: <046.2e620bb56fd39fe88732c85fa515dde8@haskell.org> References: <046.2e620bb56fd39fe88732c85fa515dde8@haskell.org> Message-ID: <061.5d09f4f720dc336859c1aa27e8cc2db1@haskell.org> #13751: Runtime crash with <> after concurrent stressing of STM computations -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: 10414 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For the sake of making it easier to run, I'm attaching a version without any dependencies. To run it: {{{ ghc -fforce-recomp -O -threaded Main.hs ./Main +RTS -N4 -RTS }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 17:04:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 17:04:40 -0000 Subject: [GHC] #13751: Runtime crash with <> after concurrent stressing of STM computations In-Reply-To: <046.2e620bb56fd39fe88732c85fa515dde8@haskell.org> References: <046.2e620bb56fd39fe88732c85fa515dde8@haskell.org> Message-ID: <061.636d0e0190a24f9e79b54bcdd8ac090d@haskell.org> #13751: Runtime crash with <> after concurrent stressing of STM computations -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: 10414 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 17:52:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 17:52:36 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms In-Reply-To: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> References: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> Message-ID: <066.1403e7a64b09ba8678973c66a5ec026e@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): `f (B endo) = A (appEndo endo)` works while this doesn't {{{#!hs f :: B -> A f (B (appEndo -> f)) = A f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 18:04:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 18:04:31 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms In-Reply-To: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> References: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> Message-ID: <066.27cc43f8f92b10764db8561a53bca2e3@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:12 Iceland_jack]: > `f (B endo) = A (appEndo endo)` works while this doesn't > > {{{#!hs > f :: B -> A > f (B (appEndo -> f)) = A f > }}} That's not surprising. We don't have impredicative types, so `appEndo x` always produces a monomorphic result. You have to unpack the `Endo` under the `A` constructor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 19:08:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 19:08:21 -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.45b60456da7915a3919f5d6b990e970a@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.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "regex-tdfa-reduced.tar.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 19:11:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 19:11:38 -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.e428a64488ce9c1c218030d617228963@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.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've attached a minimized version of `regex-tdfa-1.2.2` with no external dependencies. Moreover, the slowdown in GHC 8.2 seems primarily concentrated at the `*Engine` files, so I only included what was necessary to support one of them. Here are the times that I got: {{{ $ time /opt/ghc/8.0.2/bin/ghc -O2 -fforce-recomp TextRegexTDFANewDFAEngine_FA.hs real 0m10.139s user 0m9.996s sys 0m0.116s $ time /opt/ghc/8.2.1/bin/ghc -O2 -fforce-recomp TextRegexTDFANewDFAEngine_FA.hs real 0m18.072s user 0m17.912s sys 0m0.156s }}} The `TextRegexTDFANewDFAEngine_FA.hs` file in particular is what is contributing to the difference in time, as all other modules take about the same time to compile on 8.0.2 and 8.2.1-rc2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 20:19:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 20:19:55 -0000 Subject: [GHC] #13758: Deriving can't find an instance that holds, standalone deriving works Message-ID: <051.5d9757ff2c244834bf6245b82974e50e@haskell.org> #13758: Deriving can't find an instance that holds, standalone deriving works -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using [https://hackage.haskell.org/package/generic-deriving-1.11.2/docs /Generics-Deriving-Monoid.html generic-deriving] works {{{#!hs {-# Language ScopedTypeVariables, GeneralizedNewtypeDeriving, DeriveGeneric, UndecidableInstances, StandaloneDeriving, FlexibleContexts #-} import GHC.Generics import Generics.Deriving.Monoid hiding (GMonoid) import Data.Coerce import Data.Constraint import Data.Semigroup newtype GenericMonoid a = GenericMonoid a instance (Generic a, Monoid' (Rep a)) => Semigroup (GenericMonoid a) where (<>) = coerce (mappenddefault :: a -> a -> a) instance (Generic a, Monoid' (Rep a)) => Monoid (GenericMonoid a) where mempty = coerce (memptydefault :: a) mappend = coerce (mappenddefault :: a -> a -> a) data Urls = Urls String String String deriving (Show, Generic) newtype UrlsDeriv = UD (GenericMonoid Urls) deriving instance Semigroup UrlsDeriv deriving instance Monoid UrlsDeriv }}} but changing that to {{{#!hs newtype UrlsDeriv = UD (GenericMonoid Urls) deriving (Semigroup, Monoid) }}} fails {{{ $ ghci -ignore-dot-ghci tWqD.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tWqD.hs, interpreted ) Ok, modules loaded: Main. *Main> :r [1 of 1] Compiling Main ( tWqD.hs, interpreted ) tWqD.hs:26:13: error: • No instance for (Monoid' (Rep Urls)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Semigroup UrlsDeriv) tWqD.hs:26:24: error: • No instance for (Monoid' (Rep Urls)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Monoid UrlsDeriv) Failed, modules loaded: none. }}} This feels familiar but I couldn't quickly. I can't recall if this behavior is intended so I'm filing a ticket just in case. It even following proof of `Monoid' (Rep Urls)` and a dummy quasiquote `pure []` separating it them, {{{#!hs {-# Language ..., TemplateHaskell #-} ... doo :: Dict (Monoid' (Rep Urls)) doo = Dict pure [] newtype UrlsDeriv = UD (GenericMonoid Urls) deriving Monoid }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 20:20:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 20:20:20 -0000 Subject: [GHC] #13758: Deriving can't find an instance that holds, standalone deriving works In-Reply-To: <051.5d9757ff2c244834bf6245b82974e50e@haskell.org> References: <051.5d9757ff2c244834bf6245b82974e50e@haskell.org> Message-ID: <066.9369e47448f989c9828129c05ac02961@haskell.org> #13758: Deriving can't find an instance that holds, standalone deriving works -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -1,3 +1,0 @@ - Using [https://hackage.haskell.org/package/generic-deriving-1.11.2/docs - /Generics-Deriving-Monoid.html generic-deriving] works - @@ -10,0 +7,2 @@ + -- https://hackage.haskell.org/package/generic-deriving-1.11.2/docs + /Generics-Deriving-Monoid.html New description: {{{#!hs {-# Language ScopedTypeVariables, GeneralizedNewtypeDeriving, DeriveGeneric, UndecidableInstances, StandaloneDeriving, FlexibleContexts #-} import GHC.Generics -- https://hackage.haskell.org/package/generic-deriving-1.11.2/docs /Generics-Deriving-Monoid.html import Generics.Deriving.Monoid hiding (GMonoid) import Data.Coerce import Data.Constraint import Data.Semigroup newtype GenericMonoid a = GenericMonoid a instance (Generic a, Monoid' (Rep a)) => Semigroup (GenericMonoid a) where (<>) = coerce (mappenddefault :: a -> a -> a) instance (Generic a, Monoid' (Rep a)) => Monoid (GenericMonoid a) where mempty = coerce (memptydefault :: a) mappend = coerce (mappenddefault :: a -> a -> a) data Urls = Urls String String String deriving (Show, Generic) newtype UrlsDeriv = UD (GenericMonoid Urls) deriving instance Semigroup UrlsDeriv deriving instance Monoid UrlsDeriv }}} but changing that to {{{#!hs newtype UrlsDeriv = UD (GenericMonoid Urls) deriving (Semigroup, Monoid) }}} fails {{{ $ ghci -ignore-dot-ghci tWqD.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tWqD.hs, interpreted ) Ok, modules loaded: Main. *Main> :r [1 of 1] Compiling Main ( tWqD.hs, interpreted ) tWqD.hs:26:13: error: • No instance for (Monoid' (Rep Urls)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Semigroup UrlsDeriv) tWqD.hs:26:24: error: • No instance for (Monoid' (Rep Urls)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Monoid UrlsDeriv) Failed, modules loaded: none. }}} This feels familiar but I couldn't quickly. I can't recall if this behavior is intended so I'm filing a ticket just in case. It even following proof of `Monoid' (Rep Urls)` and a dummy quasiquote `pure []` separating it them, {{{#!hs {-# Language ..., TemplateHaskell #-} ... doo :: Dict (Monoid' (Rep Urls)) doo = Dict pure [] newtype UrlsDeriv = UD (GenericMonoid Urls) deriving Monoid }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 20:22:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 20:22:36 -0000 Subject: [GHC] #13758: Deriving can't find an instance that holds, standalone deriving works In-Reply-To: <051.5d9757ff2c244834bf6245b82974e50e@haskell.org> References: <051.5d9757ff2c244834bf6245b82974e50e@haskell.org> Message-ID: <066.76d25ac2ffd344f61dd37ae23b45b851@haskell.org> #13758: Deriving can't find an instance that holds, standalone deriving works -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -0,0 +1,2 @@ + This works: + @@ -70,2 +72,2 @@ - It even following proof of `Monoid' (Rep Urls)` and a dummy quasiquote - `pure []` separating it them, + ---- + '''Magically''' having `pure []` separate them, works: @@ -84,1 +86,1 @@ - deriving Monoid + deriving (Semigroup, Monoid) New description: This works: {{{#!hs {-# Language ScopedTypeVariables, GeneralizedNewtypeDeriving, DeriveGeneric, UndecidableInstances, StandaloneDeriving, FlexibleContexts #-} import GHC.Generics -- https://hackage.haskell.org/package/generic-deriving-1.11.2/docs /Generics-Deriving-Monoid.html import Generics.Deriving.Monoid hiding (GMonoid) import Data.Coerce import Data.Constraint import Data.Semigroup newtype GenericMonoid a = GenericMonoid a instance (Generic a, Monoid' (Rep a)) => Semigroup (GenericMonoid a) where (<>) = coerce (mappenddefault :: a -> a -> a) instance (Generic a, Monoid' (Rep a)) => Monoid (GenericMonoid a) where mempty = coerce (memptydefault :: a) mappend = coerce (mappenddefault :: a -> a -> a) data Urls = Urls String String String deriving (Show, Generic) newtype UrlsDeriv = UD (GenericMonoid Urls) deriving instance Semigroup UrlsDeriv deriving instance Monoid UrlsDeriv }}} but changing that to {{{#!hs newtype UrlsDeriv = UD (GenericMonoid Urls) deriving (Semigroup, Monoid) }}} fails {{{ $ ghci -ignore-dot-ghci tWqD.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tWqD.hs, interpreted ) Ok, modules loaded: Main. *Main> :r [1 of 1] Compiling Main ( tWqD.hs, interpreted ) tWqD.hs:26:13: error: • No instance for (Monoid' (Rep Urls)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Semigroup UrlsDeriv) tWqD.hs:26:24: error: • No instance for (Monoid' (Rep Urls)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Monoid UrlsDeriv) Failed, modules loaded: none. }}} This feels familiar but I couldn't quickly. I can't recall if this behavior is intended so I'm filing a ticket just in case. ---- '''Magically''' having `pure []` separate them, works: {{{#!hs {-# Language ..., TemplateHaskell #-} ... doo :: Dict (Monoid' (Rep Urls)) doo = Dict pure [] newtype UrlsDeriv = UD (GenericMonoid Urls) deriving (Semigroup, Monoid) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 20:30:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 20:30:50 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.5e53b9c17a9ba9e0a230b83594732393@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): That patch is a one-liner to a configure script that sets SplitSections=Yes by default while building ghc. Perhaps the problem is caused by how the libraries being linked with SplitSections=YES? If bgamari had SplitSections = NO in his .mk, then this would explain why he couldn't replicate the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 21:50:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 21:50:08 -0000 Subject: [GHC] #13758: Deriving can't find an instance that holds, standalone deriving works In-Reply-To: <051.5d9757ff2c244834bf6245b82974e50e@haskell.org> References: <051.5d9757ff2c244834bf6245b82974e50e@haskell.org> Message-ID: <066.93805c5172295f4fb527886cff4b0323@haskell.org> #13758: Deriving can't find an instance that holds, standalone deriving works -------------------------------------+------------------------------------- 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: #2721, #8165 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #2721, #8165 Comment: Hah! You tickled a bug that I originally ran into when I was working on the fix for #2721/#8165 (making `GeneralizedNewtypeDeriving` work for classes with associated type families). The issue was that we weren't updating the type family instance environment early enough in type checking, which resulted in the strange staging error you experienced. I had thought that the only way to trigger that bug was with classes with associated type families, but you have just proven me wrong! The fix made it into GHC 8.2.1, and this program does indeed typecheck with that version. However, I'll keep this ticket open for now, as this program makes for a good GHC regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 22:11:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 22:11:35 -0000 Subject: [GHC] #13751: Runtime crash with <> after concurrent stressing of STM computations In-Reply-To: <046.2e620bb56fd39fe88732c85fa515dde8@haskell.org> References: <046.2e620bb56fd39fe88732c85fa515dde8@haskell.org> Message-ID: <061.28f5adfec676d83b29b90692f7735b3b@haskell.org> #13751: Runtime crash with <> after concurrent stressing of STM computations -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: 10414 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): fwiw above reproduces in 8.2.1-rc2 on a Mac with 4 cpus -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 22:16:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 22:16:59 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.4bc9989b0cbc549e1f59778594d95f0b@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): See https://phabricator.haskell.org/D1242#40188 Is it plausible that profiling libraries would have 100x more sections than non-profiling libraries? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 22:49:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 22:49:05 -0000 Subject: [GHC] #13758: Deriving can't find an instance that holds, standalone deriving works In-Reply-To: <051.5d9757ff2c244834bf6245b82974e50e@haskell.org> References: <051.5d9757ff2c244834bf6245b82974e50e@haskell.org> Message-ID: <066.258e96c908a63382536e67ec4aef94dd@haskell.org> #13758: Deriving can't find an instance that holds, standalone deriving works -------------------------------------+------------------------------------- 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: #2721, #8165 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"c82314085f2721915ea143a53f09de111aee7edb/ghc" c8231408/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c82314085f2721915ea143a53f09de111aee7edb" Add regression test for #13758 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 22:50:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 22:50:16 -0000 Subject: [GHC] #13758: Deriving can't find an instance that holds, standalone deriving works In-Reply-To: <051.5d9757ff2c244834bf6245b82974e50e@haskell.org> References: <051.5d9757ff2c244834bf6245b82974e50e@haskell.org> Message-ID: <066.79190f33e73a8143d2f6383fd35473fd@haskell.org> #13758: Deriving can't find an instance that holds, standalone deriving works -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T13758 Blocked By: | Blocking: Related Tickets: #2721, #8165 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => deriving/should_compile/T13758 * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 22:57:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 22:57:53 -0000 Subject: [GHC] #13756: Typo in user guide suggests that there's an -O* option In-Reply-To: <042.6a3b1c429314348df414591c312b566f@haskell.org> References: <042.6a3b1c429314348df414591c312b566f@haskell.org> Message-ID: <057.94f6c7667e7e84ed2555c154aaa32fc9@haskell.org> #13756: Typo in user guide suggests that there's an -O* option -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | 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): Eek! This accidentally snuck through in commit 4fd6207ec6960c429e6a1bcbe0282f625010f52a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 26 23:28:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 May 2017 23:28:05 -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.58acb459455ad7886a5c118856313055@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.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: A sizeable chunk of that increase in time came from commit 2effe18ab51d66474724d38b20e49cc1b8738f60 (The Early Inline Patch): {{{ Commit 55efc9718b520ef354e32c15c4b49cdfecce412f (Combine identical case alternatives in CSE) ----- real 0m10.682s user 0m10.392s sys 0m0.272s Commit 2effe18ab51d66474724d38b20e49cc1b8738f60 (The Early Inline Patch) ----- real 0m13.742s user 0m13.524s sys 0m0.204s }}} What's responsible for the other ~5 seconds remains to be investigated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 01:29:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 01:29:31 -0000 Subject: [GHC] #12648: Stack overflow when using monad-unlift In-Reply-To: <042.64fc702f7ceb8c3f9f9373656fec25e1@haskell.org> References: <042.64fc702f7ceb8c3f9f9373656fec25e1@haskell.org> Message-ID: <057.17eca8cf2508458f2d3318f3e55452e0@haskell.org> #12648: Stack overflow when using monad-unlift -------------------------------------+------------------------------------- Reporter: nh2 | 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: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"27f6f388ef1a3cd694008150fe513e3e7be2e6ad/ghc" 27f6f388/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="27f6f388ef1a3cd694008150fe513e3e7be2e6ad" Add regression test for #12648 Commit ce97b7298d54bdfccd9dcf366a69c5617b4eb43f (the fix for #12175) also fixed #12648. Let's add a regression test so that it stays fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 01:29:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 01:29:31 -0000 Subject: [GHC] #12175: Instance resolution regression In-Reply-To: <047.eebbfe30afafd756d0e37026c57d7434@haskell.org> References: <047.eebbfe30afafd756d0e37026c57d7434@haskell.org> Message-ID: <062.dfc6715fbf2c85217652f91c25170e1f@haskell.org> #12175: Instance resolution regression -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T12175 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"27f6f388ef1a3cd694008150fe513e3e7be2e6ad/ghc" 27f6f388/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="27f6f388ef1a3cd694008150fe513e3e7be2e6ad" Add regression test for #12648 Commit ce97b7298d54bdfccd9dcf366a69c5617b4eb43f (the fix for #12175) also fixed #12648. Let's add a regression test so that it stays fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 01:31:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 01:31:37 -0000 Subject: [GHC] #12648: Stack overflow when using monad-unlift In-Reply-To: <042.64fc702f7ceb8c3f9f9373656fec25e1@haskell.org> References: <042.64fc702f7ceb8c3f9f9373656fec25e1@haskell.org> Message-ID: <057.bd973222acd8262c3b688cdbc6df5afd@haskell.org> #12648: Stack overflow when using monad-unlift -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T12648 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => typecheck/should_fail/T12648 * resolution: => fixed Comment: Fortunately, commit ce97b7298d54bdfccd9dcf366a69c5617b4eb43f (Expand given superclasses more eagerly) happened to fix this bug, and it made it in time for GHC 8.0.2. To be on the safe side, I've added a regression test as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 11:21:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 11:21:55 -0000 Subject: [GHC] #13759: Strange error message for deriving Data Message-ID: <044.c89c9d7f67d761ccca1e7e03774533ee@haskell.org> #13759: Strange error message for deriving Data -------------------------------------+------------------------------------- Reporter: alanz | 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: -------------------------------------+------------------------------------- The following code {{{#!hs {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE FlexibleInstances #-} import Data.Data data Pass = Parsed | Renamed | Typechecked deriving (Data) data GHC (c :: Pass) deriving instance Data (GHC 'Parsed) deriving instance Data (GHC 'Renamed) deriving instance Data (GHC 'Typechecked) -- Type synonyms as a shorthand for tagging type GhcPs = GHC 'Parsed type GhcRn = GHC 'Renamed type GhcTc = GHC 'Typechecked }}} loads fine in `ghci-8.2.0.20170507`. In `ghc-8.0.2` and current master (as at https://github.com/ghc/ghc/tree/wip/new-tree-one-param-2) it gives {{{#!hs alanz at alanz-laptop:~/tmp/ghc-bug-data-deriving$ ghci-8.0.2 Main.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/alanz/.ghci [1 of 1] Compiling Main ( Main.hs, interpreted ) Main.hs:16:1: error: Multiple declarations of ‘$tFl4AgeEJ0Vk5ONrnm56S3r’ Declared at: Main.hs:16:1 Main.hs:17:1 Main.hs:16:1: error: Multiple declarations of ‘$tFl4AgeEJ0Vk5ONrnm56S3r’ Declared at: Main.hs:15:1 Main.hs:17:1 Main.hs:16:1: error: Duplicate type signatures for ‘$tFl4AgeEJ0Vk5ONrnm56S3r’ at Main.hs:15:1-36 Main.hs:16:1-37 Main.hs:17:1-41 Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 14:39:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 14:39:27 -0000 Subject: [GHC] #12991: panic when using IrredPreds in a type checker plugin. In-Reply-To: <043.3217b821d2aaafeace19f4825d72c2ca@haskell.org> References: <043.3217b821d2aaafeace19f4825d72c2ca@haskell.org> Message-ID: <058.4c7d844f1a253995dbcdbd956fa3e097@haskell.org> #12991: panic when using IrredPreds in a type checker plugin. -------------------------------------+------------------------------------- Reporter: owen | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, I might have spoke too soon. It now //compiles//, but sadly, the compiled program segfaults when run. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 15:05:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 15:05:21 -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.99ba139fd1ee183e36a0c5ffcc5665e8@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.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Found it. The other culprit is commit 6eb52cfc2e31df2561860f43d41766464ccfe8af (Improve SetLevels for join points): {{{ Commit 871b63e4ea95d4c516d31378d0475167e75caa01 (Improve pretty-printing of types) ----- real 0m13.918s user 0m13.708s sys 0m0.192s Commit 6eb52cfc2e31df2561860f43d41766464ccfe8af (Improve SetLevels for join points) ----- real 0m19.008s user 0m18.804s sys 0m0.188s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 15:08:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 15:08:53 -0000 Subject: [GHC] #13760: Review: Fix test output after 'Some tidying up of type pretty-printing' Message-ID: <044.e609de3b6a065e0d1641964a95c538d0@haskell.org> #13760: Review: Fix test output after 'Some tidying up of type pretty-printing' -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The commit https://github.com/ghc/ghc/commit/09d5c993aae208e3d34a9e715297922b6ea42b3f updates the output for T7861.stderr so that the test passes after https://github.com/ghc/ghc/commit/ad14efd539377aaf472ad69449dcaf3e679b0e51 Review that fixing the test is the correct option here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 15:33:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 15:33:45 -0000 Subject: [GHC] #13759: Strange error message for deriving Data In-Reply-To: <044.c89c9d7f67d761ccca1e7e03774533ee@haskell.org> References: <044.c89c9d7f67d761ccca1e7e03774533ee@haskell.org> Message-ID: <059.f1ff869a1211c506f56f1a8b736c2b06@haskell.org> #13759: Strange error message for deriving Data -------------------------------------+------------------------------------- Reporter: alanz | 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: #12245 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12245 Comment: I'm not sure what changes you did on your local branch to make this fail, but on GHC HEAD (as of commit 09d5c993aae208e3d34a9e715297922b6ea42b3f), that program typechecks. Do you have commit 895eefa8447a2886e77fdedcbca8047263c88db7 (Make unique auxiliary function names in deriving) in your local branch? That's what fixed #12245, which I would consider this ticket to be a duplicate of. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 19:14:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 19:14:47 -0000 Subject: [GHC] #13735: RankNTypes don't work with PatternSynonyms In-Reply-To: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> References: <051.bb0ddcb5ba3daf0a4c66989d25f71854@haskell.org> Message-ID: <066.de73e7cb87d2e2d2bda9b7b50099dbc3@haskell.org> #13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Very cool -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 20:31:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 20:31:32 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.719347d45d3cecfac55d5853d2b4103a@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Well, I certainly can't rule it out. Surely if this is the case it is avoidable, however. Can you run `objdump` on an affected object file? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 20:32:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 20:32:54 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.9db6324a271370f542740d7a9a9b373d@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Compile-time performance bug * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 20:37:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 20:37:18 -0000 Subject: [GHC] #13761: Can't create poly-kinded GADT with TypeInType enabled, but can without Message-ID: <050.2f1e1c074cee1d6dee365ff75365056c@haskell.org> #13761: Can't create poly-kinded GADT with TypeInType enabled, but can without -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Surprisingly, this compiles without `TypeInType`: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} module Works where import Data.Kind data T :: k -> Type where MkT :: T Int }}} But once you add `TypeInType`: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data T :: k -> Type where MkT :: T Int }}} then it stops working! {{{ GHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:11:12: error: • Expected kind ‘k’, but ‘Int’ has kind ‘*’ • In the first argument of ‘T’, namely ‘Int’ In the type ‘T Int’ In the definition of data constructor ‘MkT’ | 11 | MkT :: T Int | ^^^ }}} This bug is present in GHC 8.0.1, 8.0.2, 8.2.1, and HEAD. What's strange about this bug is that is requires that you write `T` with an explicit kind signature. If you write `T` like this: {{{#!hs data T (a :: k) where MkT :: T Int }}} Then it will work with `TypeInType` enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 20:43:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 20:43:27 -0000 Subject: [GHC] #13762: TypeInType is not documented in the users' guide flag reference Message-ID: <050.78435b52d9dc2514bd12b6fce932038d@haskell.org> #13762: TypeInType is not documented in the users' guide flag reference -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At least, not as of http://git.haskell.org/ghc.git/blob/09d5c993aae208e3d34a9e715297922b6ea42b3f:/utils/mkUserGuidePart/Options/Language.hs. We should fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 20:56:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 20:56:12 -0000 Subject: [GHC] #13762: TypeInType is not documented in the users' guide flag reference In-Reply-To: <050.78435b52d9dc2514bd12b6fce932038d@haskell.org> References: <050.78435b52d9dc2514bd12b6fce932038d@haskell.org> Message-ID: <065.1c3d253dd6dfe1979d8dc8fb9c9d850b@haskell.org> #13762: TypeInType is not documented in the users' guide flag reference -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3614 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3614 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 21:04:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 21:04:44 -0000 Subject: [GHC] #8440: Get rid of the remaining static flags In-Reply-To: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> References: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> Message-ID: <067.804bc1c2367b5a34868b6c60602055bf@haskell.org> #8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => new * resolution: fixed => Comment: Oops, it looks like there are still a couple of references to static flags in the flag reference. I've submitted Phab:D3615 for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 21:05:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 21:05:00 -0000 Subject: [GHC] #8440: Get rid of the remaining static flags In-Reply-To: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> References: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> Message-ID: <067.91e15aede6e4393fb83c5ac5adef2652@haskell.org> #8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2839, Wiki Page: | Phab:D3615 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: Phab:D2839 => Phab:D2839, Phab:D3615 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 27 21:22:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 May 2017 21:22:27 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.fd823c7320e6406faf522e4288bb3ef7@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I tried `objdump`-ing object files produced by 8.0.2 and 8.2.1, and they look almost identical. I have to wonder how much of this is due to GCC differences. For comparison, I just tried compiling a simple profiled executable on my machine with GCC 6.2.0, and the whole process only took about 1.5 seconds. (Compare that to the 13-second times that I experienced on my other machine with GCC 4.8.4.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 03:38:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 03:38:54 -0000 Subject: [GHC] #13763: Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an array Message-ID: <048.3858df3b3399782d9452f01ad23b4ddd@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: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (NCG) | 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: -------------------------------------+------------------------------------- Testing GHC 8.0.1 against the RC 8.2.0.20170507 I've distilled a smallish test-case from a much larger case in my 'hashabler' library, and validated that the same modifications also make that regression disappear in the real case. It's probably possible to get this smaller but I don't know if I'll have time to work on it more for a while: repro3.hs: {{{#!hs {-# LANGUAGE BangPatterns #-} module Main(main) where import Criterion.Main import qualified Data.Primitive as P import Data.Bits import Data.Word import Control.DeepSeq main :: IO () main = do defaultMain [ env (newByteArr64 5) $ \ ~bs -> bench "ByteArray 5" $ nf (hashTextSip 99) bs , env (newByteArr64 8) $ \ ~bs -> bench "ByteArray 8" $ nf (hashTextSip 99) bs , env (newByteArr64 512) $ \ ~bs -> bench "ByteArray 512" $ nf (hashTextSip 99) bs , env (newByteArr64 1000000) $ \ ~bs -> bench "ByteArray 1000000" $ nf (hashTextSip 99) bs ] instance NFData P.ByteArray where rnf _ = () newByteArr64 n = P.newAlignedPinnedByteArray (8*n) 8 >>= P.unsafeFreezeByteArray sipRound :: Word64 -> Word64 -> Word64 -> Word64 -> (Word64, Word64, Word64, Word64) {-# INLINE sipRound #-} sipRound v0 v1 v2 v3 = (v3 `xor` v0, v0 `xor` v1, v1 `xor` v2, v2 `xor` v3) hashTextSip :: Word64 -> P.ByteArray -> Word64 {-# INLINE hashTextSip #-} hashTextSip h = \ ba -> let !lenWord16 = P.sizeofByteArray ba `unsafeShiftR` 1 !word16sRem = lenWord16 .&. 3 !word16sIx = lenWord16-word16sRem !ixFinal = lenWord16-1 !word16sIxWd = word16sIx `unsafeShiftR` 2 -- `div` 4 hash4Word16sLoop hAcc@(!w0,!w1,!w2,!w3) !ix | ix == word16sIxWd = hashRemainingWord16s hAcc word16sIx | otherwise = let w64Dirty = P.indexByteArray ba ix w64 = clean4xWord16ChunkLE w64Dirty in hash4Word16sLoop (sipRound (w0 `xor` w64) w1 w2 w3) (ix + 1) -- NOTE: Removing this causes regression to disappear as well. hashRemainingWord16s (!w0,!w1,!w2,!w3) !ix | ix > ixFinal = w0 | otherwise = let w16 = P.indexByteArray ba ix in hashRemainingWord16s (sipRound (w0 `xor` (fromIntegral (w16 :: Word16))) w1 w2 w3) (ix+1) in hash4Word16sLoop (h,1,2,3) 0 clean4xWord16ChunkLE :: Word64 -> Word64 {-# INLINE clean4xWord16ChunkLE #-} clean4xWord16ChunkLE w64Dirty = -- NOTE: no regression when just this (8.2 is faster) -- (((byteSwap64 w64Dirty) `unsafeShiftR` 8) .&. 0x00FF00FF00FF00FF) -- ...but this is a big regression: (((byteSwap64 w64Dirty) `unsafeShiftR` 8) .&. 0x00FF00FF00FF00FF) .|. (((byteSwap64 w64Dirty) `unsafeShiftL` 8) .&. 0xFF00FF00FF00FF00) }}} Here are the results of the benchmark above on my machine: On GHC **8.0.1**: {{{ benchmarking ByteArray 5 time 24.70 ns (24.00 ns .. 26.25 ns) 0.987 R² (0.967 R² .. 1.000 R²) mean 24.44 ns (24.13 ns .. 25.80 ns) std dev 1.859 ns (318.3 ps .. 4.227 ns) variance introduced by outliers: 86% (severely inflated) benchmarking ByteArray 8 time 32.66 ns (32.58 ns .. 32.76 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 32.79 ns (32.64 ns .. 33.09 ns) std dev 683.7 ps (365.4 ps .. 1.175 ns) variance introduced by outliers: 31% (moderately inflated) benchmarking ByteArray 512 time 1.428 μs (1.382 μs .. 1.522 μs) 0.986 R² (0.970 R² .. 1.000 R²) mean 1.398 μs (1.384 μs .. 1.454 μs) std dev 91.12 ns (4.475 ns .. 193.9 ns) variance introduced by outliers: 76% (severely inflated) benchmarking ByteArray 1000000 time 2.658 ms (2.653 ms .. 2.663 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 2.672 ms (2.665 ms .. 2.691 ms) std dev 35.00 μs (10.88 μs .. 59.58 μs) }}} And on **GHC 8.2** RC: {{{ benchmarking ByteArray 5 time 23.78 ns (23.68 ns .. 23.88 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 23.83 ns (23.76 ns .. 23.95 ns) std dev 298.8 ps (183.2 ps .. 482.5 ps) variance introduced by outliers: 14% (moderately inflated) benchmarking ByteArray 8 time 35.81 ns (35.44 ns .. 36.27 ns) 0.999 R² (0.998 R² .. 1.000 R²) mean 35.56 ns (35.45 ns .. 35.94 ns) std dev 596.8 ps (134.5 ps .. 1.184 ns) variance introduced by outliers: 22% (moderately inflated) benchmarking ByteArray 512 time 1.706 μs (1.698 μs .. 1.716 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 1.701 μs (1.698 μs .. 1.707 μs) std dev 13.27 ns (5.825 ns .. 24.41 ns) benchmarking ByteArray 1000000 time 3.322 ms (3.284 ms .. 3.377 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 3.296 ms (3.287 ms .. 3.332 ms) std dev 44.62 μs (20.55 μs .. 87.29 μs) }}} Looking at the core wasn't fruitful, but I think dumping the asm shows that this is a case of bad (or worse) register allocation. I've attached two screenshots showing the instructions added (in blue), when moving from the one-line `clean4xWord16ChunkLE` to the two-line version, for both 8.0 and 8.2 (there wasn't anything in the diff besides instances of this change). It looks in the 8.2 version like we've decided we're out of registers and need to use the stack. In my real code I'm seeing 35% regression on very long Text, as well as 21% regression on very long ByteString; the latter implementation is similarly structured to `hashTextSip`, but doesn't call `clean4xWord16ChunkLE` but does do a byteswap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 03:40:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 03:40:28 -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.976d807740c3302ccf53cfd627daa9e7@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: normal | Milestone: Component: Compiler (NCG) | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jberryman): * Attachment "repro3.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 03:41:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 03:41:20 -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.d56961aa4206d291ca35cab7aea0ca9a@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: normal | Milestone: Component: Compiler (NCG) | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jberryman): * Attachment "8.0.1.regressing_and_non_regressing_asm_diff.png" added. Adding the second line (which causes regression in 8.2) on 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 03:42:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 03:42:37 -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.3069ec1353ad91d52f2d35a3ca425c39@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: normal | Milestone: Component: Compiler (NCG) | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jberryman): * Attachment "8.2.rc.regressing_and_non_regressing_asm_diff.png" added. Adding the second line (which causes regression in 8.2) on 8.2.1, illustrating register spilling -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 10:54:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 10:54:09 -0000 Subject: [GHC] #13238: Harmonise pretty printing of parens in hsSyn In-Reply-To: <044.f41c6dada67f65332c2039335ba24d88@haskell.org> References: <044.f41c6dada67f65332c2039335ba24d88@haskell.org> Message-ID: <059.7f9769e647eff411332e936effd4ddea@haskell.org> #13238: Harmonise pretty printing of parens in hsSyn -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"3b23f680c2b1f80b693eb8896fb21e4bbf8edc7e/ghc" 3b23f680/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3b23f680c2b1f80b693eb8896fb21e4bbf8edc7e" Remove HsContext from ppr_mono_ty, and remove ppParendHsType This is a cleanup after Trac #13238, as the context was no longer being used. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 15:04:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 15:04:31 -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.85e177e8604ec80f149f69a6c82d95f2@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: normal | Milestone: Component: Compiler (NCG) | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks for the nice bug report! I'm attaching a version of the program with no external dependencies, which will be useful as I track down which commit caused this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 15:04:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 15:04:46 -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.2624f85ef9ab6416b2fa4afad9d02ed0@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: normal | Milestone: Component: Compiler (NCG) | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "repro3_reduced.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 15:38:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 15:38:36 -0000 Subject: [GHC] #13757: Are you for or against writing "otherwise" as a keyword? In-Reply-To: <044.a4fc99e00f379531d171337bd3da9d21@haskell.org> References: <044.a4fc99e00f379531d171337bd3da9d21@haskell.org> Message-ID: <059.b80dfee21ed7c1abafd65600dcebb6db@haskell.org> #13757: Are you for or against writing "otherwise" as a keyword? -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * Attachment "specimen of proposal.txt" added. Specimen of New Proposal in GHC Trac -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 15:39:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 15:39:03 -0000 Subject: [GHC] #13764: Creating a ticket named "New proposal" in GHC Trac. Message-ID: <044.fd2283d580e269372d43530d3844cede@haskell.org> #13764: Creating a ticket named "New proposal" in GHC Trac. -------------------------------------+------------------------------------- Reporter: vanto | Owner: hvr Type: feature | Status: new request | Priority: normal | Milestone: Component: Trac & Git | 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: -------------------------------------+------------------------------------- Instead of going to GitHub to make a proposal, I suggest instead to do it in GHC TRAC by creating a new ticket named {{{New Proposal}}} I think it's easier.\\ Of course all the boxes of the ticket will not be for information.\\ Either you write directly in the ticket or you write in a file attached to the ticket.\\ The attached file would be a template.\\ Of course if the text file is too long it can be shared in several parts.\\ In Trac one can managed the time spent since the opening of the proposal.\\ They can also be archived.\\ Making simple is my creed.\\ To be honest I don't understand anything about GitHub and making a proposal in GitHub is complicated.\\ So I created a specimen of proposal attached to ticket number #13757 to show you that it is feasible.\\ And I invite you already to criticize this specimen of proposal in the legal time and to give a conclusive answer in the attached ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 17:16:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 17:16:20 -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.5cc06b0566d7a36de2d129257c19d586@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: normal | Milestone: 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 RyanGlScott): * keywords: => JoinPoints Comment: Commit 8d5cf8bf584fd4849917c29d82dcf46ee75dd035 (Join points) is the culprit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 17:20:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 17:20:05 -0000 Subject: [GHC] #13757: Are you for or against writing "otherwise" as a keyword? In-Reply-To: <044.a4fc99e00f379531d171337bd3da9d21@haskell.org> References: <044.a4fc99e00f379531d171337bd3da9d21@haskell.org> Message-ID: <059.d2bcac5222a8ffc23e931c6f9b9a2450@haskell.org> #13757: Are you for or against writing "otherwise" as a keyword? -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => closed * resolution: => duplicate Comment: Duplicate of #13669 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 17:21:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 17:21:32 -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.b7b5f7ada5bc2566916a40135c3c51bb@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: normal | Milestone: Component: Compiler (NCG) | Version: 8.2.1-rc2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Looking at the `-ddump-simpl` output, there are some noticeable differences in the Core emitted by 8.0.2 and 8.2.1-rc2. From 8.0.2, we have: {{{ -- RHS size: {terms: 137, types: 72, coercions: 5} main1 :: State# RealWorld -> (# State# RealWorld, () #) main1 = \ (s :: State# RealWorld) -> case newAlignedPinnedByteArray# 8000000# 8# (s `cast` ...) of _ { (# ipv, ipv1 #) -> case unsafeFreezeByteArray# ipv1 ipv of _ { (# ipv2, ipv3 #) -> (# ipv2 `cast` ..., let { ipv4 :: Int# ipv4 = uncheckedIShiftRA# (sizeofByteArray# ipv3) 1# } in let { ipv5 :: Int# ipv5 = -# ipv4 (andI# ipv4 3#) } in let { ipv6 :: Int# ipv6 = uncheckedIShiftRA# ipv5 2# } in let { ipv7 :: Int# ipv7 = -# ipv4 1# } in letrec { $whashRemainingWord16s :: Word# -> Word# -> Word# -> Word# -> Int# -> Word# $whashRemainingWord16s = \ (ww :: Word#) (ww1 :: Word#) (ww2 :: Word#) (ww3 :: Word#) (ww4 :: Int#) -> case tagToEnum# (># ww4 ipv7) of _ { False -> case indexWord16Array# ipv3 ww4 of wild1 { __DEFAULT -> let { v0 :: Word# v0 = xor# ww wild1 } in $whashRemainingWord16s (xor# ww3 v0) (xor# v0 ww1) (xor# ww1 ww2) (xor# ww2 ww3) (+# ww4 1#) }; True -> ww }; } in letrec { $whash4Word16sLoop :: Word# -> Word# -> Word# -> Word# -> Int# -> Word# $whash4Word16sLoop = \ (ww :: Word#) (ww1 :: Word#) (ww2 :: Word#) (ww3 :: Word#) (ww4 :: Int#) -> case tagToEnum# (==# ww4 ipv6) of _ { False -> case indexWord64Array# ipv3 ww4 of wild1 { __DEFAULT -> let { v0 :: Word# v0 = xor# ww (or# (and# (uncheckedShiftRL# (byteSwap# wild1) 8#) 71777214294589695##) (and# (uncheckedShiftL# (byteSwap# wild1) 8#) 18374966859414961920##)) } in $whash4Word16sLoop (xor# ww3 v0) (xor# v0 ww1) (xor# ww1 ww2) (xor# ww2 ww3) (+# ww4 1#) }; True -> $whashRemainingWord16s ww ww1 ww2 ww3 ipv5 }; } in case $whash4Word16sLoop 99## 1## 2## 3## 0# of _ { __DEFAULT -> () } #) } } -- RHS size: {terms: 1, types: 0, coercions: 3} main :: IO () main = main1 `cast` ... }}} And from 8.2.1-rc2, we have: {{{ -- RHS size: {terms: 134, types: 77, coercions: 72, joins: 2/8} main1 :: State# RealWorld -> (# State# RealWorld, () #) main1 = \ (s :: State# RealWorld) -> case newAlignedPinnedByteArray# 8000000# 8# (s `cast` ) of { (# ipv, ipv1 #) -> case unsafeFreezeByteArray# ipv1 ipv of { (# ipv2, ipv3 #) -> (# ipv2 `cast` , let { ipv4 :: Int# ipv4 = uncheckedIShiftRA# (sizeofByteArray# ipv3) 1# } in let { ixFinal :: Int# ixFinal = -# ipv4 1# } in let { word16sIx :: Int# word16sIx = -# ipv4 (andI# ipv4 3#) } in let { word16sIxWd :: Int# word16sIxWd = uncheckedIShiftRA# word16sIx 2# } in joinrec { $whashRemainingWord16s :: Word# -> Word# -> Word# -> Word# -> Int# -> () $whashRemainingWord16s (ww :: Word#) (ww1 :: Word#) (ww2 :: Word#) (ww3 :: Word#) (ww4 :: Int#) = case tagToEnum# (># ww4 ixFinal) of { False -> case indexWord16Array# ipv3 ww4 of wild1 { __DEFAULT -> let { v0 :: Word# v0 = xor# ww wild1 } in jump $whashRemainingWord16s (xor# ww3 v0) (xor# v0 ww1) (xor# ww1 ww2) (xor# ww2 ww3) (+# ww4 1#) }; True -> () }; } in joinrec { $whash4Word16sLoop :: Word# -> Word# -> Word# -> Word# -> Int# -> () $whash4Word16sLoop (ww :: Word#) (ww1 :: Word#) (ww2 :: Word#) (ww3 :: Word#) (ww4 :: Int#) = case tagToEnum# (==# ww4 word16sIxWd) of { False -> case indexWord64Array# ipv3 ww4 of wild1 { __DEFAULT -> let { v0 :: Word# v0 = xor# ww (or# (and# (uncheckedShiftRL# (byteSwap# wild1) 8#) 71777214294589695##) (and# (uncheckedShiftL# (byteSwap# wild1) 8#) 18374966859414961920##)) } in jump $whash4Word16sLoop (xor# ww3 v0) (xor# v0 ww1) (xor# ww1 ww2) (xor# ww2 ww3) (+# ww4 1#) }; True -> jump $whashRemainingWord16s ww ww1 ww2 ww3 word16sIx }; } in jump $whash4Word16sLoop 99## 1## 2## 3## 0# #) } } -- RHS size: {terms: 1, types: 0, coercions: 3, joins: 0/0} main :: IO () main = main1 `cast` }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 17:59:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 17:59:34 -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.1f83f75a821390b5905b56be92a349d3@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: normal | Milestone: Component: Compiler (NCG) | Version: 8.2.1-rc2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jberryman): Yeah, I quickly gave up trying to core or downstream output between the two. And I'm aware that we should expect register allocation to be fiddly: the algorithm is simple and suboptimal, so it's likely that from very different core we'd get randomly better or worse generated code, especially if we're pushing our use of registers (I'm not sure if this is really the case here). Still I thought I should report because: - this represents a real regression in my code, and perhaps something like this should be included in ghc benchmarks to motivate improvements to register allocation, and - it might be that something else is going on and we're getting register spilling when we really shouldn't In any case I hope reporting this is not unproductive. Here's a bit more information: I found that the following change (which is more sensible source in any case) results in significantly faster code in both cases and starts to narrow but does not eliminate the regression (we are still using stack in the 8.2 version). A test case with this version is probably better to work with: {{{#!hs clean4xWord16ChunkLE :: Word64 -> Word64 {-# INLINE clean4xWord16ChunkLE #-} clean4xWord16ChunkLE w64Dirty = -- This improves things significantly (and is an improvement in 8.0.1), but -- still regresses: -- For "ByteArray 1000000": -- 8.0.1: 2.663 ms - 2.261 ms -- 8.2 rc: 3.371 ms - 2.728 ms let !w64 = byteSwap64 w64Dirty in ((w64 `unsafeShiftR` 8) .&. 0x00FF00FF00FF00FF) .|. ((w64 `unsafeShiftL` 8) .&. 0xFF00FF00FF00FF00) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 18:31:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 18:31:19 -0000 Subject: [GHC] #13757: Are you for or against writing "otherwise" as a keyword? In-Reply-To: <044.a4fc99e00f379531d171337bd3da9d21@haskell.org> References: <044.a4fc99e00f379531d171337bd3da9d21@haskell.org> Message-ID: <059.4a3c49e798700290bc8f96c1d843e447@haskell.org> #13757: Are you for or against writing "otherwise" as a keyword? -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: closed => new * resolution: duplicate => Comment: I wrote the ticket {{{#13669}}} For now these two tickets must remain open. They talk about two different things. But it is me who brings the same solution that needs to be debated in each separately ticket.\\ I reopen this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 21:03:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 21:03:04 -0000 Subject: [GHC] #13760: Review: Fix test output after 'Some tidying up of type pretty-printing' In-Reply-To: <044.e609de3b6a065e0d1641964a95c538d0@haskell.org> References: <044.e609de3b6a065e0d1641964a95c538d0@haskell.org> Message-ID: <059.fea462bf627c2c9c94914fec3420d6e2@haskell.org> #13760: Review: Fix test output after 'Some tidying up of type pretty-printing' -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Yes, thank you, it's good. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 21:44:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 21:44:23 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.c8cb4da397b22e105e129dd0cdc926f8@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #13750 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lehins): * Attachment "Array.hs" added. Another minimal example of the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 28 21:44:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 May 2017 21:44:59 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.6ed9328841a44251d219b580884099ff@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #13750 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lehins): * Attachment "Main.hs" added. Main file that goes with Array.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 00:19:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 00:19:33 -0000 Subject: [GHC] #13761: Can't create poly-kinded GADT with TypeInType enabled, but can without In-Reply-To: <050.2f1e1c074cee1d6dee365ff75365056c@haskell.org> References: <050.2f1e1c074cee1d6dee365ff75365056c@haskell.org> Message-ID: <065.b31130df1a9265e529b6c03053d7b318@haskell.org> #13761: Can't create poly-kinded GADT with TypeInType enabled, but can without -------------------------------------+------------------------------------- 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another workaround is to explicitly quantify the kind like so: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module Works2 where import Data.Kind data T :: forall (k :: Type). k -> Type where MkT :: T Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 00:39:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 00:39:23 -0000 Subject: [GHC] #13765: GHC cannot parse valid Haskell98 whose first identifier is named signature Message-ID: <045.6f39ae3b9741f78eac1717d65d0a58fa@haskell.org> #13765: GHC cannot parse valid Haskell98 whose first identifier is named signature -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1-rc2 (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: -------------------------------------+------------------------------------- This no longer parses in GHC 8.2: {{{ ezyang at sabre:~$ cat A.hs signature = 2 ezyang at sabre:~$ ghc-8.0 -c A.hs A.hs:1:1: error: The IO action ‘main’ is not defined in module ‘Main’ ezyang at sabre:~$ ghc-head -c A.hs A.hs:1:11: error: parse error on input ‘=’ Perhaps you need a 'let' in a 'do' block? e.g. 'let x = 5' instead of 'x = 5' | 1 | signature = }}} The problem is that signature is only a keyword in the module header and not in the rest of the code, which means that there is a shift/reduce conflict when you have a `signature` at the top of the module. This is fairly benign bug as you can only trigger it when you have no imports; nevertheless, we should fix it. One possibility is to have a completely different parser entry when you are parsing an `hsig` file so that `signature` never occurs in a module header when you parse a normal Haskell file. ISTR this was modestly more irritating to implement but perhaps it is still not too bad. (Note that the shift/reduce conflict still exists, but since you'll never declare a signature without a module header it is essentially irrelevant.) I discovered this when mpickering pointed out that adding 'signature' to the module header increased the number of shift reduce conflicts. (https://github.com/haskell-suite/haskell-src- exts/pull/355#issuecomment-304536290). This wasn't the case in GHC's parser but only accidentally: there is already a shift reduce conflict when you have a top-level Haddock doc block! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 00:39:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 00:39:33 -0000 Subject: [GHC] #13765: GHC cannot parse valid Haskell98 whose first identifier is named signature In-Reply-To: <045.6f39ae3b9741f78eac1717d65d0a58fa@haskell.org> References: <045.6f39ae3b9741f78eac1717d65d0a58fa@haskell.org> Message-ID: <060.3975d6124f336124365b35677d443f15@haskell.org> #13765: GHC cannot parse valid Haskell98 whose first identifier is named signature -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Parser) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => backpack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 00:40:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 00:40:38 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.49dca6f718bbfc28c1e33059db707e1f@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I have done some investigation and think I understand this now. Linking against libraries built with -split-sections is slow, and seems to be superlinear in the number of sections. I have been testing on HEAD, using BuildFlavour = Validate. By default, profiling libraries are not built, and SplitSections = No. Setting BUILD_PROF_LIBS = YES in build.mk and Linking the trivial program is only slightly slower than with 8.0.2 with and without -prof. I have been using the following command to count sections in library files, this is counting the sections in the profiled base I built without SplitSections: {{{ objdump -xw libraries/base/dist-install/build/libHSbase-4.10.0.0_p.a | wc -l 524008 }}} This is counting the sections in the profiled base I got from launchpad: {{{ objdump -xw /opt/ghc/8.2.1/lib/ghc-8.2.0.20170522/base-4.10.0.0/libHSbase-4.10.0.0_p.a | wc -l 1022947 }}} Now setting SplitSections = YES, cleaning and building libraries {{{ objdump -xw libraries/base/dist-install/build/libHSbase-4.10.0.0_p.a | wc -l 1031190 }}} And the test case is as slow as it has been in my previous testing. I tried upgrading my gcc to 6.3.0, and this does not change the results. I haven't tried upgrading ld, I can't see how to do that. It looks like the libraries from launchpad, both profiled and unprofiled, were built with SplitSections = Yes. The prof build flavour does not set SplitSections = No, unlike all of the other ones, so I suspect they came from a prof build. I believe that the above explains what causes linking to be very slow, and why we have had difficulty reliably reproducing it. I don't know why many sections slows linking. My only idea comes from [http://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking]: > Finally, if any of the objects in the library has been included in the link, the library is rescanned again - it's possible that symbols imported by the included object can be found in other objects within the same library. That algorithm sounds quadratic in the worst case. The following are the file sizes produced in various cases (83 has SplitSections libraries): {{{ -rwxr-xr-x 1 doug fileservs 1507544 May 29 00:09 profiled_80 -rwxr-xr-x 1 doug fileservs 1511320 May 29 00:09 profiled_83 -rwxr-xr-x 1 doug fileservs 13138024 May 29 00:09 profiled_nogcsections_83 -rwxr-xr-x 1 doug fileservs 1040752 May 29 00:09 unprofiled_80 -rwxr-xr-x 1 doug fileservs 903616 May 29 00:09 unprofiled_83 -rwxr-xr-x 1 doug fileservs 7923416 May 29 00:09 unprofiled_nogcsections_83 }}} and the times taken to produce them: {{{ 8.0 profiled command real 0m0.183s user 0m0.168s sys 0m0.012s 8.2 profiled command real 0m14.764s user 0m14.616s sys 0m0.144s 8.2 profiled command no gc-section s real 0m2.138s user 0m1.940s sys 0m0.192s 8.0 unprofiled command real 0m0.179s user 0m0.140s sys 0m0.036s 8.2 unprofiled command real 0m1.749s user 0m1.656s sys 0m0.088s 8.2 unprofiled command no gc-sections real 0m1.373s user 0m1.220s sys 0m0.148s }}} ---- I think SplitSections should not be enabled in prof.mk (or any others), at least for libraries. There is good reason to pass -Wl,--gc-sections to the linker always, since it lets you leverage libraries that have been compiled with -split- sections, but perhaps this is too dangerous while we don't understand exactly what causes the slowdown. There should be better interface than -fwhole-archive-hs-libs to disable --gc-sections while doing a profiling build. One or many of: * Don't pass --gc-sections if profiling is enabled * * unless another flag is passed * A warning if -prof is passed without -fwhole-archive-hs-libs * * add another flag that only disables --gc-sections -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 04:18:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 04:18:18 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.111420ba224af890acc7024e642b6b9c@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:50 simonpj]: > OK, so we conclude that the original problem is now fixed? (Albeit we don't quite know how.) > > If so, great; but let's add a regression test. I'm not sure. There were two changes to `binary` relating to this ticket: several `INLINE`s were removed, and the generic classes were split. Are we hoping to be able to reintroduce the inlines ''and'' merge the classes? I don't think we're in a position to do that right now (I tried, and compiling Cabal got quite slow). Are we hoping just to be able to merge the classes? I'll try to see how that looks next. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 06:58:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 06:58:18 -0000 Subject: [GHC] #13764: Creating a ticket named "New proposal" in GHC Trac. In-Reply-To: <044.fd2283d580e269372d43530d3844cede@haskell.org> References: <044.fd2283d580e269372d43530d3844cede@haskell.org> Message-ID: <059.267803bb24a5304ec260ae29702bbb5c@haskell.org> #13764: Creating a ticket named "New proposal" in GHC Trac. -------------------------------------+------------------------------------- Reporter: vanto | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | 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 vanto): Correction : Instead of "Instead of going to GitHub" read "In alternation and in addition to GitHub" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 08:05:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 08:05:23 -0000 Subject: [GHC] #13766: Confusing "reudundant pattern match" in 8.0, no warning at all in 8.2 Message-ID: <044.a0d4ddde4ac467954a614a3fdf55fb65@haskell.org> #13766: Confusing "reudundant pattern match" in 8.0, no warning at all in 8.2 -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | 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 couldn't find an existing ticket about this, so I figured I'd file this even though it's probably an instance of a more general problem. Consider {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -Wall -Woverlapping-patterns #-} module T where class C a where c :: a -> a instance Int ~ Bool => C Int where c = id }}} yields {{{ T.hs:10:3: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘c’: c = ... }}} which I suppose makes _some_ amount of sense but is highly confusing nonetheless :) Now in 8.2 I don't get this warning, but in fact I don't get any warning at all, which I'm not entirely sure is better. In the real code obviously the superclass constraint was far more complicated and it was nice of ghc to warn me (albeit in a roundabout way) that it was unsatisfiable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 08:10:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 08:10:30 -0000 Subject: [GHC] #13750: GHC produces incorrect coercions in hairy code In-Reply-To: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> References: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> Message-ID: <060.4fbbd29c4cc59a5c5409df1b54586f0d@haskell.org> #13750: GHC produces incorrect coercions in hairy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #13429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kosmikus): Simon, thanks for taking a look, and sorry for the "bad" test program. Yes, this very much originated in code littered with unsafeCoerce, which was an experiment, and I already spent several hours to condense it down to the size it currently has. The code compiles and behaves ok with older GHCs. Many further attempts at simplification just make it work (such as reducing to a single module, or simplifying seemingly unrelated functions). I'm fully aware that this is nowhere near a simple and easy to reproduce example. If it helps, I can invest more time to do so. On the other hand, if you have a reasonably clear idea what's going wrong, I'd prefer not to. In the meantime, I'll try the workaround you suggest. All this is in a codebase that's currently just an experiment. If it doesn't work reliably, I cannot move forward with the experiment, but it's not mission critical to me. My main worry is that it looks like it's a regression that might also affect arbitrary other things in subtle ways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 18:03:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 18:03:09 -0000 Subject: [GHC] #13766: Confusing "reudundant pattern match" in 8.0, no warning at all in 8.2 In-Reply-To: <044.a0d4ddde4ac467954a614a3fdf55fb65@haskell.org> References: <044.a0d4ddde4ac467954a614a3fdf55fb65@haskell.org> Message-ID: <059.a29e7149ec030f31c8919a99c4c578f4@haskell.org> #13766: Confusing "reudundant pattern match" in 8.0, no warning at all in 8.2 -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 18:06:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 18:06:45 -0000 Subject: [GHC] #13766: Confusing "redundant pattern match" in 8.0, no warning at all in 8.2 (was: Confusing "reudundant pattern match" in 8.0, no warning at all in 8.2) In-Reply-To: <044.a0d4ddde4ac467954a614a3fdf55fb65@haskell.org> References: <044.a0d4ddde4ac467954a614a3fdf55fb65@haskell.org> Message-ID: <059.2d3df075011a39206a0b963b6b24693d@haskell.org> #13766: Confusing "redundant pattern match" in 8.0, no warning at all in 8.2 -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: 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 Mon May 29 19:15:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 19:15:00 -0000 Subject: [GHC] #13306: Problems with type inference for static expressions In-Reply-To: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> References: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> Message-ID: <059.b468d1c5270b62ef5b0ecd5f7b32ebbc@haskell.org> #13306: Problems with type inference for static expressions -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): (I've created a new wiki page at https://ghc.haskell.org/trac/ghc/wiki/StaticPointers/NeedForPolymorphism to record some examples of programs that rely on polymorphic static values ; I've added the example above as well as another one.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 19:21:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 19:21:25 -0000 Subject: [GHC] #13766: Confusing "redundant pattern match" in 8.0, no warning at all in 8.2 In-Reply-To: <044.a0d4ddde4ac467954a614a3fdf55fb65@haskell.org> References: <044.a0d4ddde4ac467954a614a3fdf55fb65@haskell.org> Message-ID: <059.08ba6cb96e04f7be6929220e372c19bf@haskell.org> #13766: Confusing "redundant pattern match" in 8.0, no warning at all in 8.2 -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: mpickering (added) Comment: Hoo boy, that's pretty scary. To make it worse, because of this bug you can write blatantly nonsensical things like this: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -Wall -Woverlapping-patterns #-} module T where class C a where c :: a instance (a ~ Bool, a ~ Int) => C a where c = 42 + True }}} And it'll compile on GHC 8.2.1-rc2 with no warnings. (I haven't found a way to actually //use// that bogus `c` definition, but still.) The commit that caused this behavior is adb565aa74582969bbcc3b411d6d518b1c76c3cf (Don't return empty initial uncovered set for an unsat context). Matthew, do you know what is going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 19:30:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 19:30:21 -0000 Subject: [GHC] #13766: Confusing "redundant pattern match" in 8.0, no warning at all in 8.2 In-Reply-To: <044.a0d4ddde4ac467954a614a3fdf55fb65@haskell.org> References: <044.a0d4ddde4ac467954a614a3fdf55fb65@haskell.org> Message-ID: <059.f57a767a9a859702162d78c80d4a31a9@haskell.org> #13766: Confusing "redundant pattern match" in 8.0, no warning at all in 8.2 -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: 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): This looks related to some changes to inaccessibility which happened for GHC 8.2. There's more context at #12466, #11066 and #12694, and possibly more (do a search for "inaccessible") -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 19:48:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 19:48:27 -0000 Subject: [GHC] #13766: Confusing "redundant pattern match" in 8.0, no warning at all in 8.2 In-Reply-To: <044.a0d4ddde4ac467954a614a3fdf55fb65@haskell.org> References: <044.a0d4ddde4ac467954a614a3fdf55fb65@haskell.org> Message-ID: <059.84325c78385de1d7cdb87a35e3940729@haskell.org> #13766: Confusing "redundant pattern match" in 8.0, no warning at all in 8.2 -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: 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): This is the expected behaviour, the commit message explains the reasoning. {{{ Previously when the checker encountered an unsatisfiable term of type context it would return an empty initial uncovered set. This caused all pattern matches in the context to be reported as redudant. This is arguably correct behaviour as they will never be reached but it is better to recover and provide accurate warnings for these cases to avoid error cascades. It would perhaps be better to report an error to the user about an inacessible branch but this is certainly better than many confusing redundant match warnings. }}} Warning that the RHS is inaccessible would be valuable but I don't think it's the domain of the pattern match checker to warn indirectly of this by warning of "redundant" clauses. So it looks like the tickets that Edward linked are more relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 20:10:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 20:10:10 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.476cae9f0ffcf88a876e0ed9463044b3@haskell.org> #12759: Latest Debian GCC breaks GHC -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12755, #11834, | Differential Rev(s): Phab:D2707 #9007 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by msuchanek): * Attachment "_log.txt.xz" added. log of failed ghc build -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 20:10:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 20:10:48 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.a85ea41bb8a744c1b936df14b1cfc0d5@haskell.org> #12759: Latest Debian GCC breaks GHC -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12755, #11834, | Differential Rev(s): Phab:D2707 #9007 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by msuchanek): This is still broken in 8.0.2 [ 43s] + /usr/bin/xz -dc /home/abuild/rpmbuild/SOURCES/ghc-8.0.2-src.tar.xz ... [ 48s] checking whether GCC supports -no-pie... yes ... [ 1985s] /usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse- linux/bin/ld: /home/abuild/rpmbuild/BUILD/ghc-8.0.2/rts/dist/build/libHSrts.a(AutoApply.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC [ 1985s] /usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse- linux/bin/ld: final link failed: Nonrepresentable section on output [ 1985s] collect2: error: ld returned 1 exit status [ 1985s] `gcc' failed in phase `Linker'. (Exit code: 1) [ 1985s] make[1]: *** [utils/ghc-cabal/ghc.mk:89: utils/ghc-cabal/dist- install/build/tmp/ghc-cabal] Error 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 20:31:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 20:31:37 -0000 Subject: [GHC] #11834: GHC master, not compiling on Archlinux In-Reply-To: <045.4e01e4471eaa123aed65b47cf92d5739@haskell.org> References: <045.4e01e4471eaa123aed65b47cf92d5739@haskell.org> Message-ID: <060.761d9602fbd1ccb56cef55e1edfb073d@haskell.org> #11834: GHC master, not compiling on Archlinux -------------------------------------+------------------------------------- Reporter: nitrix | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #12759 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by msuchanek): It is also broken on openSUSE. I get the {{{ #define __pic__ 2 #define __PIC__ 2 }}} when I pass -fPIC to gcc but passing -pie or -no-pie to gcc-6 does not change any defines and {{{ #define __pie__ 2 #define __PIE__ 2 }}} are never defined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 20:53:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 20:53:48 -0000 Subject: [GHC] #11834: GHC master, not compiling on Archlinux In-Reply-To: <045.4e01e4471eaa123aed65b47cf92d5739@haskell.org> References: <045.4e01e4471eaa123aed65b47cf92d5739@haskell.org> Message-ID: <060.17d956d5173bdf9776b302c3c887c277@haskell.org> #11834: GHC master, not compiling on Archlinux -------------------------------------+------------------------------------- Reporter: nitrix | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: (Linking) | Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #12759 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * status: new => closed * resolution: => duplicate Comment: Closing as duplicate of #12759 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 20:59:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 20:59:20 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.ade6c748568d02de5be7eeaba5d60e6f@haskell.org> #12759: Latest Debian GCC breaks GHC -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12755, #11834, | Differential Rev(s): Phab:D2707 #9007 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) Comment: msuchanek, I suggest filing new bug so we could investigate why host ghc was failing to build stage2 for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 23:10:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 23:10:15 -0000 Subject: [GHC] #13767: GHCi trips -DS checks at rts/sm/Sanity.c, line 210 Message-ID: <046.e0bf705a7b0da22195c9831465099e74@haskell.org> #13767: GHCi trips -DS checks at rts/sm/Sanity.c, line 210 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Error: {{{ $ echo -e ":quit\n" | ./inplace/bin/ghc-stage2 --interactive +RTS -DS -RTS -ignore-dot-ghci GHCi, version 8.3.20170515: http://www.haskell.org/ghc/ :? for help Prelude> Leaving GHCi. ghc-stage2: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 (GHC version 8.3.20170515 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} Steps to reproduce: * Set `BuildFlavour = prof` in `mk/build.mk` * Add `GhcLibWays += p debug_p thr_debug_p` to `mk/build.mk`, I think you only need `thr_debug_p` * Build GHC * (cd ghc; make re2 GhcDebugged=YES), I think you can build it right away, but I'm not that familiar with the build system * `echo -e ":quit\n" | ./inplace/bin/ghc-stage2 --interactive +RTS -DS -RTS -ignore-dot-ghci` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 29 23:15:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 May 2017 23:15:58 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.3a96794c55e0e4ebc72d7ec1db9f2ccf@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Are we hoping to be able to reintroduce the inlines and merge the classes? Well, the original Description says that compiling Cabal with GHC 8.0 was 26x slower than compiling with GHC 7.8. That's a big difference. How long does it take to compile (the same) Cabal with GHC 8.2? That's the question at hand. If it's still 26x slower (and your comment suggests that it is, albeit maybe not 26x), I'd love to dig a bit into why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 03:43:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 03:43:45 -0000 Subject: [GHC] #11621: GHC doesn't see () as a Constraint in type family In-Reply-To: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> References: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> Message-ID: <066.6c12d7ef5e84d45ff01eb19a64877c32@haskell.org> #11621: GHC doesn't see () as a Constraint in type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by spacekitteh): Has this been fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 03:54:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 03:54:58 -0000 Subject: [GHC] #13695: Highly nested UNPACKed data causes panic In-Reply-To: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> References: <048.6188747b1834bb5f7a44d136150ce01c@haskell.org> Message-ID: <063.a28b13c16ee1f59205f7fa6a9ef45bad@haskell.org> #13695: Highly nested UNPACKed data causes panic ---------------------------------+---------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3990 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in 1e93425ee78481f10f79cb1d39b6cd4f11f38e5d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 03:55:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 03:55:38 -0000 Subject: [GHC] #13705: Failure of improvement for type-family dependencies In-Reply-To: <046.9cec5d52ff4c5a82be0bc369e309b746@haskell.org> References: <046.9cec5d52ff4c5a82be0bc369e309b746@haskell.org> Message-ID: <061.efbadd287b45a370aed31e60166a96d2@haskell.org> #13705: Failure of improvement for type-family dependencies -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T13705 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Merged in aa39137316fcbb555bcb676cb2f89002d97d3e3c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 04:48:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 04:48:37 -0000 Subject: [GHC] #13701: GHCi 2x slower without -keep-tmp-files In-Reply-To: <046.5313c8330fb56c9723008f1f4396a25a@haskell.org> References: <046.5313c8330fb56c9723008f1f4396a25a@haskell.org> Message-ID: <061.cb20ac71ca64711b1d3af3544c5e2da8@haskell.org> #13701: GHCi 2x slower without -keep-tmp-files -------------------------------------+------------------------------------- Reporter: niteria | Owner: duog Type: task | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3620 Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * status: new => patch * differential: => D3620 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 07:46:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 07:46:47 -0000 Subject: [GHC] #13750: GHC produces incorrect coercions in hairy code In-Reply-To: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> References: <045.2957c281e52a0617c4b44226d50f7bbc@haskell.org> Message-ID: <060.108a4b0d616d425f41fc7b399f3d66fd@haskell.org> #13750: GHC produces incorrect coercions in hairy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #13429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kosmikus): I can confirm that `-fno-specialise` also works in the full example as a workaround (but it seems it has to be applied at each use site of one of the critical functions, so it's not an extremely viable workaround for a library). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 07:54:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 07:54:30 -0000 Subject: [GHC] #13751: Runtime crash with <> after concurrent stressing of STM computations In-Reply-To: <046.2e620bb56fd39fe88732c85fa515dde8@haskell.org> References: <046.2e620bb56fd39fe88732c85fa515dde8@haskell.org> Message-ID: <061.fe70b464003280f984de691611ceb802@haskell.org> #13751: Runtime crash with <> after concurrent stressing of STM computations -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: 10414 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I reproduced it too. It does look like a lost wakeup somewhere in the blackhole handling code, but I haven't narrowed it down further yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 11:00:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 11:00:25 -0000 Subject: [GHC] #13768: Incorrect warnings generated by exhaustiveness checker with pattern synonyms / GADT combination Message-ID: <047.c95bd0aba0dc6c9a98656f56c98cf18b@haskell.org> #13768: Incorrect warnings generated by exhaustiveness checker with pattern synonyms / GADT combination -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The module {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE ViewPatterns #-} module PatSynEx where data NS (f :: k -> *) (xs :: [k]) = NS Int data IsNS (f :: k -> *) (xs :: [k]) where IsZ :: f x -> IsNS f (x ': xs) IsS :: NS f xs -> IsNS f (x ': xs) isNS :: NS f xs -> IsNS f xs isNS = undefined pattern Z :: () => (xs' ~ (x ': xs)) => f x -> NS f xs' pattern Z x <- (isNS -> IsZ x) pattern S :: () => (xs' ~ (x ': xs)) => NS f xs -> NS f xs' pattern S p <- (isNS -> IsS p) {-# COMPLETE Z, S #-} data SList :: [k] -> * where SNil :: SList '[] SCons :: SList (x ': xs) go :: SList ys -> NS f ys -> Int go SCons (Z _) = 0 go SCons (S _) = 1 go SNil _ = error "inaccessible" }}} produces the following warnings with both GHC 8.2 and 8.3: {{{ PatSynEx.hs:31:1: warning: [-Woverlapping-patterns] Pattern match has inaccessible right hand side In an equation for ‘go’: go SCons (Z _) = ... | 31 | go SCons (Z _) = 0 | ^^^^^^^^^^^^^^^^^^ PatSynEx.hs:32:1: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘go’: go SCons (S _) = ... | 32 | go SCons (S _) = 1 | ^^^^^^^^^^^^^^^^^^ }}} Neither warning seems correct. The first case is not inaccessible, the second case is not redundant. The catch-all case has always been required with GHC even though it is not really reachable, but that's not the subject of this issue. I tried to simplify the issue further by getting rid of the `f` argument in `NS` and `IsNS`, but that made the issue disappear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 11:19:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 11:19:11 -0000 Subject: [GHC] #13768: Incorrect warnings generated by exhaustiveness checker with pattern synonyms / GADT combination In-Reply-To: <047.c95bd0aba0dc6c9a98656f56c98cf18b@haskell.org> References: <047.c95bd0aba0dc6c9a98656f56c98cf18b@haskell.org> Message-ID: <062.97c277f8a4262fbc351f928f797397e5@haskell.org> #13768: Incorrect warnings generated by exhaustiveness checker with pattern synonyms / GADT combination -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * priority: normal => high * keywords: => PatternSynonyms Comment: I think the problem here is in `mkOneConFull` which makes a substitution by zipping together the `univ_tvs` and `tc_args`. If I print out what these values are in this example I find that.. {{{ univ_tvs [k_a133, xs'_aSi, f_aSj] tc_args [k_a27Q, f_a27S, ys_a27R] }}} which then generates equalities like.. {{{ theta_cs [(f_a27S :: [k_a27Q]) ~ ((x_d2kG : xs_d2kH) :: [k_a27Q])] }}} and the constraint solver reports as unsatisfiable. If I insert a hack to swap these type variables into the "right" order then the program compiles without warning as expected. {{{ univ_tvs [k_a133, xs'_aSi, f_aSj] tc_args [k_a27Q, f_a27S, ys_a27R] theta_cs [(ys_a27R :: [k_a27Q]) ~ ((x_d2ky : xs_d2kz) :: [k_a27Q])] }}} I don't know what the right solution is here as in general there seems no reason for these two lists to appear in the right order. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 11:32:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 11:32:27 -0000 Subject: [GHC] #13769: T9405 sporadic failure Message-ID: <046.c41a91e0dc09202640c731fdee3eb00c@haskell.org> #13769: T9405 sporadic failure -------------------------------------+------------------------------------- Reporter: niteria | 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: -------------------------------------+------------------------------------- I just got a failure on travis with T9405 on https://travis- ci.org/ghc/ghc/builds/237325270. The error: {{{ --- /dev/null 2017-05-29 08:06:46.967079000 +0000 +++ /tmp/ghctest-eo4toy/test spaces/./rts/T9405.run/T9405.run.stderr.normalised 2017-05-29 23:20:55.665885000 +0000 @@ -0,0 +1 @@ +/bin/sh: 4: kill: No such process }}} What I suspect happens is that under some scheduling and with CPU contention, the test instead of timing out just finishes normally. Perhaps increasing the sleep time from `2s` should be enough to mitigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 11:50:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 11:50:44 -0000 Subject: [GHC] #13767: GHCi trips -DS checks at rts/sm/Sanity.c, line 210 In-Reply-To: <046.e0bf705a7b0da22195c9831465099e74@haskell.org> References: <046.e0bf705a7b0da22195c9831465099e74@haskell.org> Message-ID: <061.9881d58ac31c1c95423074cbc21d1add@haskell.org> #13767: GHCi trips -DS checks at rts/sm/Sanity.c, line 210 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by niteria: @@ -18,1 +18,1 @@ - * Add `GhcLibWays += p debug_p thr_debug_p` to `mk/build.mk`, I + * Add `GhcRTSWays += p debug_p thr_debug_p` to `mk/build.mk`, I New description: Error: {{{ $ echo -e ":quit\n" | ./inplace/bin/ghc-stage2 --interactive +RTS -DS -RTS -ignore-dot-ghci GHCi, version 8.3.20170515: http://www.haskell.org/ghc/ :? for help Prelude> Leaving GHCi. ghc-stage2: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 (GHC version 8.3.20170515 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} Steps to reproduce: * Set `BuildFlavour = prof` in `mk/build.mk` * Add `GhcRTSWays += p debug_p thr_debug_p` to `mk/build.mk`, I think you only need `thr_debug_p` * Build GHC * (cd ghc; make re2 GhcDebugged=YES), I think you can build it right away, but I'm not that familiar with the build system * `echo -e ":quit\n" | ./inplace/bin/ghc-stage2 --interactive +RTS -DS -RTS -ignore-dot-ghci` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 12:06:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 12:06:56 -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.2df81df41933f0a5154d20c227ddaf6a@haskell.org> #13767: GHCi trips -DS checks at rts/sm/Sanity.c, line 210 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by niteria: @@ -18,5 +18,3 @@ - * Add `GhcRTSWays += p debug_p thr_debug_p` to `mk/build.mk`, I - think you only need `thr_debug_p` - * Build GHC - * (cd ghc; make re2 GhcDebugged=YES), I think you can build it right away, - but I'm not that familiar with the build system + * Add `GhcRTSWays += thr_debug_p` to `mk/build.mk` + * Build GHC with `./boot; ./configure; GhcDebugged=YES make` + * relink with `(cd ghc; make re2 GhcDebugged=YES)` New description: Error: {{{ $ echo -e ":quit\n" | ./inplace/bin/ghc-stage2 --interactive +RTS -DS -RTS -ignore-dot-ghci GHCi, version 8.3.20170515: http://www.haskell.org/ghc/ :? for help Prelude> Leaving GHCi. ghc-stage2: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 (GHC version 8.3.20170515 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} Steps to reproduce: * Set `BuildFlavour = prof` in `mk/build.mk` * Add `GhcRTSWays += thr_debug_p` to `mk/build.mk` * Build GHC with `./boot; ./configure; GhcDebugged=YES make` * relink with `(cd ghc; make re2 GhcDebugged=YES)` * `echo -e ":quit\n" | ./inplace/bin/ghc-stage2 --interactive +RTS -DS -RTS -ignore-dot-ghci` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 12:13:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 12:13:52 -0000 Subject: [GHC] #13770: HEAD: Type mentioned in error won't show up in pattern signature Message-ID: <048.bec77fc784cc04e5720ed5fc2293fddf@haskell.org> #13770: HEAD: Type mentioned in error won't show up in pattern signature -------------------------------------+------------------------------------- Reporter: heisenbug | 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: -------------------------------------+------------------------------------- I am encountering a stange problem: {{{ ghc-stage2 T13770.hs -c -fprint-explicit-kinds T13770.hs:29:52: error: ? Could not deduce: (r4 :: GHC.Types.RuntimeRep) ~~ ('GHC.Types.LiftedRep :: GHC.Types.RuntimeRep) from the context: (* ~ *, (f :: *) ~~ (arg -> res :: *)) bound by a pattern with pattern synonym: Fun :: forall k (fun :: k). () => forall (arg :: TYPE r1) (res :: TYPE r2). (k ~ *, (fun :: k) ~~ (arg -> res :: *)) => TypeRep (TYPE r1) arg -> TypeRep (TYPE r2) res -> TypeRep k fun, in a pattern binding in 'do' block at T13770.hs:19:19-35 or from: (* :: *) ~~ (TYPE r1 :: *) bound by a pattern with constructor: Refl :: forall k (a :: k). (:~:) k a a, in a pattern binding in 'do' block at T13770.hs:22:19-22 or from: (* :: *) ~~ (TYPE r2 :: *) bound by a pattern with constructor: Refl :: forall k (a :: k). (:~:) k a a, in a pattern binding in 'do' block at T13770.hs:23:19-22 or from: (TYPE r2 ~ *, (res :: TYPE r2) ~~ (arg1 -> res1 :: *)) bound by a pattern with pattern synonym: Fun :: forall k (fun :: k). () => forall (arg :: TYPE r1) (res :: TYPE r2). (k ~ *, (fun :: k) ~~ (arg -> res :: *)) => TypeRep (TYPE r1) arg -> TypeRep (TYPE r2) res -> TypeRep k fun, in a pattern binding in 'do' block at T13770.hs:27:37-41 ?r4? is a rigid type variable bound by a pattern with pattern synonym: Fun :: forall k (fun :: k). () => forall (arg :: TYPE r1) (res :: TYPE r2). (k ~ *, (fun :: k) ~~ (arg -> res :: *)) => TypeRep (TYPE r1) arg -> TypeRep (TYPE r2) res -> TypeRep k fun, in a pattern binding in 'do' block at T13770.hs:27:37-41 When matching the kind of ?arg1? Expected type: TypeRep * (arg1 -> res1) Actual type: TypeRep (TYPE r2) res ? In the second argument of ?postulate?, namely ?fargrep? In a stmt of a 'do' block: Refl <- postulate vrep fargrep In the expression: do A2 satur _ <- a2 retrep vrep fargrep at Fun {} <- pure retrep HRefl <- fargrep `eqTypeRep` retrep Refl <- postulate vrep fargrep .... | 29 | Refl <- postulate vrep fargrep | ^^^^^^^ }}} Notice how `r4` is mentioned in the error message but none of the signatures refer to it. This is confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 12:14:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 12:14:47 -0000 Subject: [GHC] #13770: HEAD: Type mentioned in error won't show up in pattern signature In-Reply-To: <048.bec77fc784cc04e5720ed5fc2293fddf@haskell.org> References: <048.bec77fc784cc04e5720ed5fc2293fddf@haskell.org> Message-ID: <063.4d4b3dd14d341baf87de6380a9513431@haskell.org> #13770: HEAD: Type mentioned in error won't show up in pattern signature -------------------------------------+------------------------------------- Reporter: heisenbug | 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 heisenbug): * Attachment "T13770.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 13:13:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 13:13:03 -0000 Subject: [GHC] #13770: HEAD: Type mentioned in error won't show up in pattern signature In-Reply-To: <048.bec77fc784cc04e5720ed5fc2293fddf@haskell.org> References: <048.bec77fc784cc04e5720ed5fc2293fddf@haskell.org> Message-ID: <063.bd94d1e1cc40f9fdb75f8066971d4c48@haskell.org> #13770: HEAD: Type mentioned in error won't show up in pattern signature -------------------------------------+------------------------------------- Reporter: heisenbug | 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 goldfire): Just took a quick look: this is not just `-fprint-explicit-runtime-reps`, which is what I thought. Possibly a tidying error? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 13:23:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 13:23:58 -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.f99d9c4c32ee1f04c3c9f92849bd0b38@haskell.org> #13767: GHCi trips -DS checks at rts/sm/Sanity.c, line 210 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): This reproduces on https://phabricator.haskell.org/rGHC4d683fa11a5140b74f588b93f93f7891f79ac891 as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 13:30:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 13:30:41 -0000 Subject: [GHC] #13761: Can't create poly-kinded GADT with TypeInType enabled, but can without In-Reply-To: <050.2f1e1c074cee1d6dee365ff75365056c@haskell.org> References: <050.2f1e1c074cee1d6dee365ff75365056c@haskell.org> Message-ID: <065.0893b14163c6a28751fcb110586214eb@haskell.org> #13761: Can't create poly-kinded GADT with TypeInType enabled, but can without -------------------------------------+------------------------------------- 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This behavior is all expected... or, in one case, not unexpected. The very first example in the OP is regrettable, but it is "not unexpected", as `-XNoTypeInType` rejects such programs on a best-effort basis. That one is hard. The other examples are all consequences of [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #complete-user-supplied-kind-signatures-and-polymorphic-recursion the CUSK rules]. Proposed solution: allow top-level kind signatures of type-level declarations (just like we have top-level type signatures of term-level declarations) and deprecate CUSKs. One Of These Days, I will write a ghc- proposal for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 13:37:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 13:37:29 -0000 Subject: [GHC] #13761: Can't create poly-kinded GADT with TypeInType enabled, but can without In-Reply-To: <050.2f1e1c074cee1d6dee365ff75365056c@haskell.org> References: <050.2f1e1c074cee1d6dee365ff75365056c@haskell.org> Message-ID: <065.88bfc0e0e7de5008fdbae24a297d8c0a@haskell.org> #13761: Can't create poly-kinded GADT with TypeInType enabled, but can without -------------------------------------+------------------------------------- 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:2 goldfire]: > This behavior is all expected... or, in one case, not unexpected. > > The very first example in the OP is regrettable, but it is "not unexpected", as `-XNoTypeInType` rejects such programs on a best-effort basis. That one is hard. > > The other examples are all consequences of [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #complete-user-supplied-kind-signatures-and-polymorphic-recursion the CUSK rules]. Thanks for the link. I'm a bit embarrassed to say I didn't think to look in the users' guide to see if CUSKs were documented, but I'm glad they are! > Proposed solution: allow top-level kind signatures of type-level declarations (just like we have top-level type signatures of term-level declarations) and deprecate CUSKs. One Of These Days, I will write a ghc- proposal for this. If I may ask, what do you mean by "top-level kind signature" here? I thought that {{{#!hs data T :: forall k. k -> Type }}} //was// a top-level kind signature, but perhaps you meant something different? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 13:38:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 13:38:08 -0000 Subject: [GHC] #13762: TypeInType is not documented in the users' guide flag reference In-Reply-To: <050.78435b52d9dc2514bd12b6fce932038d@haskell.org> References: <050.78435b52d9dc2514bd12b6fce932038d@haskell.org> Message-ID: <065.08e577a8312794c28da91fd2d09cb208@haskell.org> #13762: TypeInType is not documented in the users' guide flag reference -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3614 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Looks good -- thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 13:42:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 13:42:42 -0000 Subject: [GHC] #13761: Can't create poly-kinded GADT with TypeInType enabled, but can without In-Reply-To: <050.2f1e1c074cee1d6dee365ff75365056c@haskell.org> References: <050.2f1e1c074cee1d6dee365ff75365056c@haskell.org> Message-ID: <065.95c4d27c34088876da24902805656caf@haskell.org> #13761: Can't create poly-kinded GADT with TypeInType enabled, but can without -------------------------------------+------------------------------------- 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I mean something like {{{#!hs type T :: k -> Type -- this is the kind signature data T _ where MkT :: T Int }}} Note that there is no `=` in the kind signature, distinguishing it from a type synonym declaration. The `_` in the `data` line is a recognition that a datatype with a kind signature does not need anything after the `T`. Not sure what the best concrete syntax around that is. (In my thought about this feature, `data T a where` and `data T :: ... where` would also both be acceptable.) Types with kind signatures will be treated just like types with CUSKs are today. Eventually, I would expect types without kind signatures to be treated just like types without CUSKs today. We would then cease to have a notion of CUSK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 13:45:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 13:45:17 -0000 Subject: [GHC] #13700: GHCi command listing possible type class instances In-Reply-To: <051.87a39f033f8a52ca51433d465661fe5a@haskell.org> References: <051.87a39f033f8a52ca51433d465661fe5a@haskell.org> Message-ID: <066.e1d62b705d1a8efa3c0b2e42919866ab@haskell.org> #13700: GHCi command listing possible type class instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack 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): Related: [https://www.schoolofhaskell.com/user/sloan/reifying-instance- resolution Reifying Instance Resolution ] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 13:46:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 13:46:52 -0000 Subject: [GHC] #13761: Can't create poly-kinded GADT with TypeInType enabled, but can without In-Reply-To: <050.2f1e1c074cee1d6dee365ff75365056c@haskell.org> References: <050.2f1e1c074cee1d6dee365ff75365056c@haskell.org> Message-ID: <065.fbd0d398d5d601bf2bd72c1c73113b6e@haskell.org> #13761: Can't create poly-kinded GADT with TypeInType enabled, but can without -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Thanks! That proposal sounds like an interesting solution. Since the original bug is expected behavior (and documented, no less), I'm going to close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 16:01:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 16:01:47 -0000 Subject: [GHC] #12908: Tuple constraints refactoring seems to regress performance considerably In-Reply-To: <046.5462e2db6c503e4b14bcdb8c72713d1a@haskell.org> References: <046.5462e2db6c503e4b14bcdb8c72713d1a@haskell.org> Message-ID: <061.a2989ca7049b7618bfde27cdaa18c461@haskell.org> #12908: Tuple constraints refactoring seems to regress performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: performance Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 16:18:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 16:18:33 -0000 Subject: [GHC] #11621: GHC doesn't see () as a Constraint in type family In-Reply-To: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> References: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> Message-ID: <066.def869a954cb80308bca435c4bb379a0@haskell.org> #11621: GHC doesn't see () as a Constraint in type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11715 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #11715 Comment: Replying to [comment:3 spacekitteh]: > Has this been fixed? No. {{{ GHCi, version 8.3.20170516: 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:14: error: • Expected a constraint, but ‘()’ has kind ‘*’ • In the type ‘()’ In the type family declaration for ‘F’ | 10 | F 'True = () | ^^ }}} Again, this probably requires fixing #11715 first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 16:27:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 16:27:52 -0000 Subject: [GHC] #13701: GHCi 2x slower without -keep-tmp-files In-Reply-To: <046.5313c8330fb56c9723008f1f4396a25a@haskell.org> References: <046.5313c8330fb56c9723008f1f4396a25a@haskell.org> Message-ID: <061.60b0eaa528484d88ba7863ab0bb53ce4@haskell.org> #13701: GHCi 2x slower without -keep-tmp-files -------------------------------------+------------------------------------- Reporter: niteria | Owner: duog Type: task | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3620 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: D3620 => Phab:D3620 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 17:39:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 17:39:13 -0000 Subject: [GHC] #11774: Regression on GHC 8 branch (vs 7.10.3) when using the GHC API to parse code that uses TH In-Reply-To: <050.40af602ae9a228b0dca3c0dd3ac155f0@haskell.org> References: <050.40af602ae9a228b0dca3c0dd3ac155f0@haskell.org> Message-ID: <065.09258e05fd475c1d4cc7b72edbfb96d6@haskell.org> #11774: Regression on GHC 8 branch (vs 7.10.3) when using the GHC API to parse code that uses TH -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonmar (added) Comment: The workaround is what //broke// this, ironically enough, since this regression was caused by commit 4905b83a2d448c65ccced385343d4e8124548a3b (Remote GHCi, -fexternal-interpreter). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 17:59:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 17:59:46 -0000 Subject: [GHC] #13385: ghci fails to start when -XRebindableSyntax is passed In-Reply-To: <046.49534d46a543f72893ed665a08de1bb0@haskell.org> References: <046.49534d46a543f72893ed665a08de1bb0@haskell.org> Message-ID: <061.768194f1970b2f7a29d712b7569a5e25@haskell.org> #13385: ghci fails to start when -XRebindableSyntax is passed -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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): * version: 8.0.2 => 8.0.1 Comment: This was caused by 4905b83a2d448c65ccced385343d4e8124548a3b (Remote GHCi, -fexternal-interpreter). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 18:49:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 18:49:23 -0000 Subject: [GHC] #13385: ghci fails to start when -XRebindableSyntax is passed In-Reply-To: <046.49534d46a543f72893ed665a08de1bb0@haskell.org> References: <046.49534d46a543f72893ed665a08de1bb0@haskell.org> Message-ID: <061.129faaa76b08153000a8957ba08455d8@haskell.org> #13385: ghci fails to start when -XRebindableSyntax is passed -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3621 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3621 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 19:04:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 19:04:13 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.c3948e827a7e5e77b27dd5bb2b28dc63@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): trippels, I've tried building against the libraries that you cite with `-O2` but sadly I'm still not seeing the crashes. What distribution are you using? Perhaps you could provide your binary? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 19:07:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 19:07:22 -0000 Subject: [GHC] #13771: ghc fails to build on openSUSE Message-ID: <048.545d3232bdf47d2b254b3d958c840fde@haskell.org> #13771: ghc fails to build on openSUSE --------------------------------------+--------------------------------- Reporter: msuchanek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- The gcc on openSUSE defaults to -pie and reverting that fixes the build. The gcc does not set any define with -pie or -no-pie. The -no-pie flag is detected but the build fails nonetheless. Adding the PIC flag does not help: {{{ @@ -3650,6 +3650,7 @@ default_PIC :: Platform -> [GeneralFlag] default_PIC platform = case (platformOS platform, platformArch platform) of (OSDarwin, ArchX86_64) -> [Opt_PIC] + (OSLinux, ArchX86_64) -> [Opt_PIC] (OSOpenBSD, ArchX86_64) -> [Opt_PIC] -- Due to PIE support in -- OpenBSD since 5.3 release -- (1 May 2013) we need to }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 19:07:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 19:07:46 -0000 Subject: [GHC] #13771: ghc fails to build on openSUSE In-Reply-To: <048.545d3232bdf47d2b254b3d958c840fde@haskell.org> References: <048.545d3232bdf47d2b254b3d958c840fde@haskell.org> Message-ID: <063.1647853d82207a52ba05e69e326671aa@haskell.org> #13771: ghc fails to build on openSUSE ---------------------------------+-------------------------------------- Reporter: msuchanek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by msuchanek): * Attachment "_log.txt.xz" added. log of failed build -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 19:44:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 19:44:34 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.10f4e3868f4254e1e2b1667e62679717@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 trippels): Sorry, but I've switched back to 8.0.2 and everything works fine again. The xmobar binary is too big to attach (even compressed). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 21:25:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 21:25:11 -0000 Subject: [GHC] #13759: Strange error message for deriving Data In-Reply-To: <044.c89c9d7f67d761ccca1e7e03774533ee@haskell.org> References: <044.c89c9d7f67d761ccca1e7e03774533ee@haskell.org> Message-ID: <059.1ad899bb6bebe83bde6d9031fe9a0cf9@haskell.org> #13759: Strange error message for deriving Data -------------------------------------+------------------------------------- Reporter: alanz | 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: #12245 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): alanz helped me figure out what was going on. You won't hit the bug with the original code, but you will with this slightly tweaked code: {{{#!hs {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE FlexibleInstances #-} import Data.Data data Pass = Parsed | Renamed | Typechecked deriving (Data) data GHC (c :: Pass) deriving instance Data GhcPs deriving instance Data GhcRn deriving instance Data GhcTc -- Type synonyms as a shorthand for tagging type GhcPs = GHC 'Parsed type GhcRn = GHC 'Renamed type GhcTc = GHC 'Typechecked }}} Crucially, we're deriving instances for the type synonyms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 21:28:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 21:28:01 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.5c8b19697b1ebaf5c127b8352a933365@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Argh! I was stupid again, in a different way. When I was trying out the old-style generics for `binary`, I forgot that my stage1 was 8.0.2, which is no good for that. When I used GHC 8.2.1 as the stage1, it built just fine. Using the merged classes ''and'' inlines to compile `Language.Haskell.Extension` takes 9 seconds, whereas with the split class and no inlines it takes 7. So I think this actually is fixed now. I'll put together a test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 22:07:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 22:07:23 -0000 Subject: [GHC] #12820: Regression around pattern synonyms and higher-rank types In-Reply-To: <047.8ff9e83595f6e43eb23a94e0b79eda39@haskell.org> References: <047.8ff9e83595f6e43eb23a94e0b79eda39@haskell.org> Message-ID: <062.e3c487f4b6a047f6c65006253f2ff540@haskell.org> #12820: Regression around pattern synonyms and higher-rank types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.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): This regression was introduced somewhere between commit 45bfd1a65978ee282d8d2cc1ddb7e3e5f4cd4717 (Refactor typechecking of pattern bindings) and 9417e57983dbcf7f500cca16163b11d1abb699e6 (Refactor occurrence-check logic). (I'm 90% sure it's 45bfd1a65978ee282d8d2cc1ddb7e3e5f4cd4717, but I can't say with certainty because that commit was in the middle of a slew of commits which didn't compile correctly until 9417e57983dbcf7f500cca16163b11d1abb699e6.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 22:40:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 22:40:39 -0000 Subject: [GHC] #13759: Strange error message for deriving Data In-Reply-To: <044.c89c9d7f67d761ccca1e7e03774533ee@haskell.org> References: <044.c89c9d7f67d761ccca1e7e03774533ee@haskell.org> Message-ID: <059.f8a0cf535587a72f3594e8bde26bd88d@haskell.org> #13759: Strange error message for deriving Data -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12245 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate Comment: Please ignore what I wrote in comment:2, that is utter garbage. The real, //real// cause of what was going on is much simpler: it is indeed a duplicate of #12245. The reason that alanz hit this bug when building ​https://github.com/ghc/ghc/tree/wip/new-tree-one-param-2 was simply because he was bootstrapping with GHC 8.0.2, and the fix for #12245 didn't land until GHC 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 23:09:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 23:09:39 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.9e281a0526a508b53a31b8eaad769da5@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Nope, nope, nope. Actually, there still seems to be a problem, but I think it's been masked by the early inline patch. Specifically, ''removing'' the `INLINE`s makes the merged class problematic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 30 23:56:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 May 2017 23:56:46 -0000 Subject: [GHC] #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) In-Reply-To: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> References: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> Message-ID: <072.19632849353bb640c9f72891e0be8d41@haskell.org> #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) -------------------------------------+------------------------------------- Reporter: | Owner: (none) mikhail.vorozhtsov | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining 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 RyanGlScott): A sizable chunk of the regression came from commit 6746549772c5cc0ac66c0fce562f297f4d4b80a2 (Add kind equalities to GHC.) {{{ Commit 6e56ac58a6905197412d58e32792a04a63b94d7e (Fix infix record field fixity (#11167 and #11173).) ----- $ time ghc4/inplace/bin/ghc-stage2 -fforce-recomp -O -c -Rghc-timing TypeList.hs Regression.hs <> real 0m12.829s user 0m12.688s sys 0m0.140s Commit 6746549772c5cc0ac66c0fce562f297f4d4b80a2 (Add kind equalities to GHC.) ----- $ time ghc4/inplace/bin/ghc-stage2 -fforce-recomp -O -c -Rghc-timing TypeList.hs Regression.hs <> real 0m34.744s user 0m34.572s sys 0m0.176s }}} But that's not the full story, since I get a realtime of `1m12.849s` with GHC 8.0.1. I'll try to figure out what other commit(s) are contributing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 01:45:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 01:45:52 -0000 Subject: [GHC] #13657: Documentation: Functional dependencies by other means In-Reply-To: <043.e6a2276b874588c5228bad3b9ffdb642@haskell.org> References: <043.e6a2276b874588c5228bad3b9ffdb642@haskell.org> Message-ID: <058.e83e8b789f0e7a12a513ea3925b4aa8c@haskell.org> #13657: Documentation: Functional dependencies by other means -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: 10431 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:1 simonpj]: > We could add it to the user manual. (I still think the User Manual doesn't really explain the difference between SuperClass constraints vs Instance constraints.) > > But alternatively, and perhaps better, we have [https://wiki.haskell.org/GHC GHC's collaborative documentation pages]. OK. I've transplanted the ticket's text to an added section under "Type system extensions" [https://wiki.haskell.org/GHC/SuperClass SuperClass]. (Strewth! Changing the markup style was fiddly.) And added some of the materials from the original ghc-users thread. > > (The contents page itself could do with some editing work too!) Yes, it's a bit of a rag-bag. I guess there's plenty of material on idioms and techniques around the web on blogs these days. But that's often related to older versions of GHC; and is difficult to search. (I did have a quick squiz for stuff on SuperClass constraints, but I don't think this ticket is repeating anything 'obvious'.) What does GHC HQ see as the 'organising principle' for the collaborative doo-hickeys? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 04:17:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 04:17:07 -0000 Subject: [GHC] #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) In-Reply-To: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> References: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> Message-ID: <072.ed31c629de677bc22e45ed9eee01fe2c@haskell.org> #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) -------------------------------------+------------------------------------- Reporter: | Owner: (none) mikhail.vorozhtsov | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining 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 RyanGlScott): Found it. The other culprit is commit 1722fa106e10e63160bb2322e2ccb830fd5b9ab3 (Fix #11230.): {{{ Commit ae86eb9f72fa7220fe47ac54d6d21395691c1308 (Fix tcTyClTyVars to handle SigTvs) ----- $ time ghc4/inplace/bin/ghc-stage2 -fforce-recomp -O -c -Rghc-timing TypeList.hs Regression.hs <> real 0m33.216s user 0m33.040s sys 0m0.176s Commit 1722fa106e10e63160bb2322e2ccb830fd5b9ab3 (Fix #11230.) ----- $ time ghc4/inplace/bin/ghc-stage2 -fforce-recomp -O -c -Rghc-timing TypeList.hs Regression.hs <> real 1m25.494s user 1m25.252s sys 0m0.260s }}} What's alarming is that that commit is so small! There must be something interesting happening there... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 12:27:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 12:27:04 -0000 Subject: [GHC] #13719: checkFamInstConsistency dominates compile time In-Reply-To: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> References: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> Message-ID: <061.7da42e260ccc8923b88f97bf5c27398b@haskell.org> #13719: checkFamInstConsistency dominates compile time -------------------------------------+------------------------------------- Reporter: niteria | 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: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13092, #13099, | Differential Rev(s): phab:D3600, #12191 | phab:D3602, phab:D3603 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"69d9081d9fa3ff36fda36e4e11ef7e8f946ecf2a/ghc" 69d9081d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="69d9081d9fa3ff36fda36e4e11ef7e8f946ecf2a" Faster checkFamInstConsistency This implements the idea from https://ghc.haskell.org/trac/ghc/ticket/13092#comment:14. It's explained in Note [Checking family instance optimization] in more detail. This improves the test case T13719 tenfold and cuts down the compile time on `:load` in `ghci` on our internal code base by half. Test Plan: ./validate Reviewers: simonpj, simonmar, rwbarton, austin, bgamari Reviewed By: simonpj Subscribers: thomie GHC Trac Issues: #13719 Differential Revision: https://phabricator.haskell.org/D3603 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 12:40:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 12:40:57 -0000 Subject: [GHC] #13719: checkFamInstConsistency dominates compile time In-Reply-To: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> References: <046.36315d7719a700f0e74f6d8460035cba@haskell.org> Message-ID: <061.6daf4761240b15e1992d5c1344cf3b0a@haskell.org> #13719: checkFamInstConsistency dominates compile time -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13092, #13099, | Differential Rev(s): phab:D3600, #12191 | phab:D3602, phab:D3603 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * status: new => closed * resolution: => fixed Comment: From my perspective this is fixed. It's a localized change with a nice upside, so we might want to merge to `ghc-8.2`. It applies cleanly, except for the testsuite. I'm happy to do the legwork, but I will leave the decision to Ben. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 13:52:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 13:52:17 -0000 Subject: [GHC] #13771: ghc fails to build on openSUSE In-Reply-To: <048.545d3232bdf47d2b254b3d958c840fde@haskell.org> References: <048.545d3232bdf47d2b254b3d958c840fde@haskell.org> Message-ID: <063.6a94e7a6957635ecaf832215d95f20a2@haskell.org> #13771: ghc fails to build on openSUSE ---------------------------------+-------------------------------------- Reporter: msuchanek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): > The -no-pie flag is detected but the build fails nonetheless. How in particular are you confirming that `-no-pie` is detected? What does the `settings` file look like in the root of the source tree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 13:54:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 13:54:03 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.53a8d4a139631276d5be8e93847a79fa@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm not even sure how you're getting that far on GHC 8.0.2. I just tried building `relational-query-0.8.3.2` fresh from Hackage, and I get this error: {{{ [40 of 40] Compiling Database.Relational.Query.TH ( src/Database/Relational/Query/TH.hs, dist/dist-sandbox- 1069cc36/build/Database/Relational/Query/TH.o ) src/Database/Relational/Query/TH.hs:83:49: error: Module ‘Database.Record.TH’ does not export ‘recordType’ }}} Are one of my dependencies too recent? {{{ $ cabal install --enable-tests --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): dlist-0.8.0.2 names-th-0.2.0.2 primitive-0.6.2.0 random-1.1 sql-words-0.1.4.1 text-1.2.2.2 tf-random-0.5 QuickCheck-2.9.2 quickcheck-simple-0.1.0.1 th-data-compat-0.0.2.2 persistable-record-0.5.0.1 th-reify-compat-0.0.1.1 time-locale-compat-0.1.1.3 relational-query-0.8.3.2 (latest: 0.9.1.0) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 14:46:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 14:46:55 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.b20d4ebe4accafc0e03cc91cbe8823a4@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by LocutusOfBorg): libghc-dlist-dev amd64 0.8.0.2-3build1 [34.6 kB] libghc-names-th-dev amd64 0.2.0.2-3build1 [24.4 kB] libghc-primitive-dev amd64 0.6.1.0-4build1 [95.1 kB] libghc-random-dev amd64 1.1-5build1 [106 kB] libghc-sql-words-dev amd64 0.1.4.1-4build1 [76.7 kB] libghc-text-dev amd64 1.2.2.1-3build1 [924 kB] libghc-tf-random-dev amd64 0.5-7build1 [79.7 kB] libghc-quickcheck2-dev amd64 2.8.2-3build1 [456 kB] libghc-quickcheck-simple-dev amd64 0.1.0.1-3build1 [20.9 kB] libghc-th-data-compat-dev amd64 0.0.2.2-3build1 [11.7 kB] libghc-persistable-record-dev amd64 0.4.1.0-1build1 [84.5 kB] libghc-th-reify-compat-dev amd64 0.0.1.1-3build1 [8050 B] libghc-time-locale-compat-dev amd64 0.1.1.3-3build1 [6616 B] so, some of them has new updates now build log here: https://launchpadlibrarian.net/303895959/buildlog_ubuntu-zesty-amd64 .haskell-relational-query_0.8.3.2-2build2_BUILDING.txt.gz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 14:54:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 14:54:44 -0000 Subject: [GHC] #13739: Very slow linking of profiled executables In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.a7d10e0a83bd04e3c222b2dcfd4c6385@haskell.org> #13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): I wanted to compare `gold` to `collect2`, so I run linking of profiled `ghc-stage2` under both with and without `--gc-sections`. The results: {{{ no --gc-sections, collect2 real 0m9.456s user 0m8.248s sys 0m1.168s 161M ghc/stage2/build/tmp/ghc-stage2 no --gc-sections, gold real 0m3.122s user 0m2.680s sys 0m0.441s 161M ghc/stage2/build/tmp/ghc-stage2 --gc-sections, collect2 real 2m14.460s user 2m13.356s sys 0m1.087s 129M ghc/stage2/build/tmp/ghc-stage2 --gc-sections, gold real 0m3.118s user 0m2.691s sys 0m0.411s 129M ghc/stage2/build/tmp/ghc-stage2 }}} Looks like `gold` doesn't even break a sweat. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 16:35:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 16:35:51 -0000 Subject: [GHC] #13771: ghc fails to build on openSUSE In-Reply-To: <048.545d3232bdf47d2b254b3d958c840fde@haskell.org> References: <048.545d3232bdf47d2b254b3d958c840fde@haskell.org> Message-ID: <063.8d3a5f7a94eacb96e26f4b22efc8df14@haskell.org> #13771: ghc fails to build on openSUSE ---------------------------------+-------------------------------------- Reporter: msuchanek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by msuchanek): [ 48s] checking whether GCC supports -no-pie... yes settings (from different machine, unfortunately) - the original machine has been upgraded to gcc7 which fails to build in-tree ghc-pwd during configure and produces no settings anymore. This happens at most once in five years ;-) {{{ [("GCC extra via C opts", " -fwrapv -fno-builtin"), ("C compiler command", "/usr/bin/gcc"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", ""), ("C compiler supports -no-pie", "YES"), ("Haskell CPP command","/usr/bin/gcc"), ("Haskell CPP flags","-E -undef -traditional"), ("ld command", "/usr/bin/ld"), ("ld flags", ""), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/usr/bin/ar"), ("ar flags", "q"), ("ar supports at file", "YES"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/bin/perl"), ("cross compiling", "NO"), ("target os", "OSLinux"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("Unregisterised", "NO"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 17:21:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 17:21:08 -0000 Subject: [GHC] #13772: Cannot put HasCallStack on instances Message-ID: <047.d360e3ed5517211c4a279da62bac67fe@haskell.org> #13772: Cannot put HasCallStack on instances -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'd like to get stack traces even when I'm using methods from a class, but I don't seen to be able to put HasCallStack in instance declarations. See attached code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 17:23:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 17:23:41 -0000 Subject: [GHC] #13772: Cannot put HasCallStack on instances In-Reply-To: <047.d360e3ed5517211c4a279da62bac67fe@haskell.org> References: <047.d360e3ed5517211c4a279da62bac67fe@haskell.org> Message-ID: <062.309005f57403a9019c322991c33928bb@haskell.org> #13772: Cannot put HasCallStack on instances -------------------------------------+------------------------------------- Reporter: augustss | 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 augustss): * Attachment "CallStack.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 17:31:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 17:31:31 -0000 Subject: [GHC] #13773: Types are not normalized in instance declarations Message-ID: <047.b99d4e95d0428b43aa3236e584c6e7ac@haskell.org> #13773: Types are not normalized in instance declarations -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the example below. It does not compile, but replacing 5*2 by 10 makes it compile. This is quite annoying since it forces me to do the normalization that the computer is really much better at doing. {{{#!hs module NatInstance where import GHC.TypeLits type N = 5 * 2 data D (n :: Nat) = D instance Show (D N) where show _ = "" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 18:28:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 18:28:10 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.e1bce15e37bd5eeede57ad2d2baa3086@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks, LocutusOfBorg. I needed to constraint `persistable-record`: {{{ $ cabal install --enable-tests --constraint=persistable-record==0.4.1.0 --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): dlist-0.8.0.2 names-th-0.2.0.2 primitive-0.6.2.0 random-1.1 sql-words-0.1.4.1 text-1.2.2.2 tf-random-0.5 QuickCheck-2.9.2 quickcheck-simple-0.1.0.1 th-data-compat-0.0.2.2 persistable-record-0.4.1.0 (latest: 0.5.0.1) th-reify-compat-0.0.1.1 time-locale-compat-0.1.1.3 relational-query-0.8.3.2 (latest: 0.9.1.0) }}} With this set of dependencies, I was able to reproduce the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 18:42:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 18:42:53 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.cbe5fb005b75114c5bdbf731ce06effe@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: QuasiQuotes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12778 | Differential Rev(s): Phab:D3610 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I don't submit a GHC proposal yet because we don't have yet a good solution to propose, we only have a problem and a couple of leads to investigate. I state the problem here in a general form. An account that Mathieu did a while ago can be found in ticket:12778#comment:8. Template Haskell quasiquotes allow to embed other languages in Haskell programs. One can use this ability to generate and compile code in a foreign language and then have the result invoked from Haskell. For quasiquotations to be typesafe though, the implementation of the quasiquoter needs to tell the foreign compiler which types are expected of the antiquoted variables and of the returned value. Quasiquoters currently have no way to find the expected return type if the programmer does not supply it explicitly. Let's consider the following example using inline-java. The package `inline-java` implements a quasiquote which allows to embed fragments of Java programs in Haskell modules. {{{ jappendWorld :: Text -> IO Text jappendWorld = [java| $x + " World!" |] }}} This generates some Java code that is compiled by a Java compiler. It also generates some Haskell code which marshals values between Java and Haskell and invokes the result of compiling the Java code. The java code that is generated looks like {{{ class ClassFreshName { public static Object freshName(String x) { return x + " World!"; } } }}} The quasiquoter knows that the antiquote `x` has type `String` in Java, because it knows that `x` has the type `Text` in Haskell and it can marshal the values between the two types. The quasiquoter can find the Haskell type of `x` via the Template Haskell function `reify` as implemented in ticket:11832. However, the quasiquoter has currently no way to find the expected return type. Therefore, it assumes that any return value is of the catch-all Java type `java.lang.Object`. This is problematic, because it is up to the programmer to use the return value in a way appropriate to its type. If the value returned by the quasiquote does not match the type expected by the programmer on the Haskell side, the program has undefined behavior. Solutions: 1. Have the programmer supply the return type, this is how the package `inline-c` works to embed `C` programs in Haskell. This involves effort on the part of the user to write the return type in every quasiquotation. 2. Use typed splices instead of quasiquotes. e.g. {{{ $$(java [string| $x + " World!" |]) }}} Typed splices do expose the expected type to the implementation, and the generated code could be tailored by using type classes. This is rather clumsy to write while quasiquotes are the best fit. 3. Implement typed quasiquotes, so we can write {{{ [java|| $x + " World!" ||] }}} which desugars to {{{ $$(typedQuoteExp java " $x + \" World!\") }}} 4. What this ticket proposed. 5. Similar to (4), but avoid introducing a name with a hash of the location. For this, we extend the type checker so when it finds a splice, it adds a binding to the typing environment which has the type of the splice and an identifier uniquely associated to the splice. Calls to `reify` can then find this binding and yield the type in the same fashion that it is done with antiquoted variables. Let me know if this should still be sent to GHC proposals. Besides that, any thoughts or advice? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 19:14:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 19:14:37 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.b8f527821908ef85e234a3fe9d6b8d1b@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: QuasiQuotes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12778 | Differential Rev(s): Phab:D3610 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Looks like typed splices and quasiquotes will pose some gotchas. {{{ -- Q.hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} module Q where import Data.Proxy import Language.Haskell.TH.Syntax class C a where method :: Proxy a -> Q (TExp a) instance C Int where method _ = [|| 1 :: Int ||] instance C Char where method _ = [|| 'a' ||] q :: forall a. C a => Q (TExp a) q = method (Proxy :: Proxy a) }}} {{{ -- testQ.hs {-# LANGUAGE TemplateHaskell #-} import Q main :: IO () main = print ($$(q) `asTypeOf` (0 :: Int)) }}} {{{ $ ghc --make testQ.hs [1 of 2] Compiling Q ( Q.hs, Q.o ) [2 of 2] Compiling Main ( testQ.hs, testQ.o ) testQ.hs:6:18: error: • Ambiguous type variable ‘a0’ arising from a use of ‘q’ prevents the constraint ‘(C a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance C Char -- Defined at Q.hs:14:10 instance C Int -- Defined at Q.hs:11:10 • In the expression: q In the Template Haskell splice $$(q) In the first argument of ‘asTypeOf’, namely ‘$$(q)’ | 6 | main = print ($$(q) `asTypeOf` (0 :: Int)) | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 31 19:43:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 May 2017 19:43:12 -0000 Subject: [GHC] #13773: Types are not normalized in instance declarations In-Reply-To: <047.b99d4e95d0428b43aa3236e584c6e7ac@haskell.org> References: <047.b99d4e95d0428b43aa3236e584c6e7ac@haskell.org> Message-ID: <062.4576b9ad2c60238e5d91c2743ff8f955@haskell.org> #13773: Types are not normalized in instance declarations -------------------------------------+------------------------------------- Reporter: augustss | 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): How would you feel about {{{#!hs f :: Int -> Bool f (5*2) = True f _ = False }}} GHC rejects this. Should it? -- Ticket URL: GHC The Glasgow Haskell Compiler