From ghc-devs at haskell.org Sun Jun 1 03:43:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jun 2014 03:43:20 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.d8517862dec1098b7373dba798c0e800@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): I think the case could be made to mark re haskell platform using 7.8.3 assuming the timeline for 7.8.3 is soon enough... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 1 07:28:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jun 2014 07:28:50 -0000 Subject: [GHC] #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) In-Reply-To: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> References: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> Message-ID: <060.434cbebfd65d3e6e7559ec09023fe4f9@haskell.org> #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) ---------------------------------------+---------------------------------- Reporter: slyfox | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler (NCG) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by simonmar): * owner: => simonmar * priority: normal => highest * milestone: => 7.8.3 Comment: Investigating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 1 13:48:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jun 2014 13:48:42 -0000 Subject: [GHC] #9158: Broken link in User's Guide Message-ID: <044.03b282b48d7123d7caf9429014429a96@haskell.org> #9158: Broken link in User's Guide ------------------------------------+-------------------------------------- Reporter: gidyn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- The online User's Guide [http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/packages.html #building-packages 4.9.7. Building a package from Haskell source] contains a broken link to [http://www.haskell.org/ghc/docs/7.8.2/html/Cabal/index.html Cabal]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 1 14:00:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jun 2014 14:00:21 -0000 Subject: [GHC] #9158: Broken link in User's Guide In-Reply-To: <044.03b282b48d7123d7caf9429014429a96@haskell.org> References: <044.03b282b48d7123d7caf9429014429a96@haskell.org> Message-ID: <059.e0134ec7470b5b6962b84faaa1ca8035@haskell.org> #9158: Broken link in User's Guide --------------------------------------+------------------------------------ Reporter: gidyn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: I believe this is a duplicate of #9154. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 1 19:57:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jun 2014 19:57:42 -0000 Subject: [GHC] #5599: msys has bad Unicode support In-Reply-To: <046.3f625e98390ad242d829f3e1c223a6bd@haskell.org> References: <046.3f625e98390ad242d829f3e1c223a6bd@haskell.org> Message-ID: <061.551bd4365e51b4dd290350eec825922a@haskell.org> #5599: msys has bad Unicode support -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.4.1 Resolution: fixed | Version: 7.2.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: llibraries/tests/IO/T3307, | Unknown/Multiple environment001 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): Replying to [comment:7 awson]: > > You shall *never* install msys2 runtime headers, libraries and development tools. You should only install msys2-base distribution and mingw(32|64)-* headers, libraries and development tools. > > You also shall start msys2 shell with mingw(32|64)_shell.bat script included into distribution. > > This way you receive (native 32 or 64 bit windows) mingw-w64 runtime based development environment with no remnants of Msys2 runtime. You clearly know something important here! Our [https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows Windows wiki page] says only "install msys2". Might you elaborate it to be a bit more specific, and explain why various things are important? Perhaps a section on that page about msys2? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 1 20:03:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jun 2014 20:03:20 -0000 Subject: [GHC] #9157: cmm common block not eliminated In-Reply-To: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> References: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> Message-ID: <063.007974efd5393d2b481d81b7571fb9aa@haskell.org> #9157: cmm common block not eliminated -------------------------------------+------------------------------------ Reporter: wojteknar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 02:07:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 02:07:39 -0000 Subject: [GHC] #5599: msys has bad Unicode support In-Reply-To: <046.3f625e98390ad242d829f3e1c223a6bd@haskell.org> References: <046.3f625e98390ad242d829f3e1c223a6bd@haskell.org> Message-ID: <061.28692087034f5d968a2f78541ce56f49@haskell.org> #5599: msys has bad Unicode support -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.4.1 Resolution: fixed | Version: 7.2.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: llibraries/tests/IO/T3307, | Unknown/Multiple environment001 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by ezyang): It's a bit of a kerfuffle. I think what should be done is the current contents of that wikipage be archived (with a big banner saying they are out of date), and wiki:Building/Preparation/Windows/MSYS2 moved to replace it -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 05:15:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 05:15:13 -0000 Subject: [GHC] #9157: cmm common block not eliminated In-Reply-To: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> References: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> Message-ID: <063.917bfc35c4a4b69de51796d58231bc7d@haskell.org> #9157: cmm common block not eliminated -------------------------------------+------------------------------------ Reporter: wojteknar | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jstolarek): * owner: => jstolarek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 06:17:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 06:17:09 -0000 Subject: [GHC] #9157: cmm common block not eliminated In-Reply-To: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> References: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> Message-ID: <063.00052991ead85155a1ca703293257468@haskell.org> #9157: cmm common block not eliminated -------------------------------------+------------------------------------ Reporter: wojteknar | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jstolarek): * cc: simonmar (added) Comment: I confirmed that this bug exists in HEAD and found the reason. I suspect that Common Block Elimination as implemented now might not work as intended. Here's what's happening. Code attached in the bug report generates 8 identical blocks (showing only 2 here for brevity): {{{ c1Dm: _s1CG::I64 = I64[_s1Cy::P64 + 7]; _g1CN::I64 = _s1CG::I64; goto c1Dd; c1Dl: _s1CF::I64 = I64[_s1Cy::P64 + 7]; _g1CN::I64 = _s1CF::I64; goto c1Dd; }}} We hash these block ignoring the labels and we get identical hashes as expected. Then we get to the point when we attempt to actually eliminate common blocks. [https://github.com/ghc/ghc/blob/master/compiler/cmm/CmmCommonBlockElim.hs#L62 We check these two block for equality], except that this time we don't ignore the labels and other unique identifiers (eg. [https://github.com/ghc/ghc/blob/master/compiler/cmm/CmmCommonBlockElim.hs#L148 here]). We conclude that these two block are different because local registers `_s1CG` are `_s1CF` are different. Later the sinking pass makes these two blocks identical. The result that we see in the Cmm output are 8 identical blocks: {{{ c1Dm: _g1CN::I64 = I64[_s1Cy::P64 + 7]; goto c1Dd; c1Dl: _g1CN::I64 = I64[_s1Cy::P64 + 7]; goto c1Dd; }}} I suspect that this is not how CBE was intended to work. I mean if we ignore the labels during hashing then we should probably be smarter when actually comparing the blocks. Except that this is not trivial. I wonder if we could simply move CBE to the end of Cmm pipeline, so that it is run after sinking and other optimizations? Or is there A Good Reason to have CBE at the beginning of the pipeline and not at the end? CCing Simon Marlow - perhaps he can tell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 07:17:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 07:17:32 -0000 Subject: [GHC] #9157: cmm common block not eliminated In-Reply-To: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> References: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> Message-ID: <063.aa4c9fe6d666815bddb5cad4b559ef66@haskell.org> #9157: cmm common block not eliminated -------------------------------------+------------------------------------ Reporter: wojteknar | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I suspect that we ignore the labels the first time so that this works: {{{ L1: x = x+1; goto L2 L2: y = y+1; goto Lend L3: x = x+1; goto L3 L4: y = y+1; goto Lend }}} Now L1 and L3 would be different if we took account of labels, but once L2 and L4 are commoned up, L1 and L3 can be as well. Waiting for the sinking pass may well help, and I don't know why we don't do CBE at the end. But it isn't enough in general. Consider {{{ L1: x = r+1; Sp[4] = x; Sp[8] = x*2; goto Lend L2: y = r+1; Sp[4] = y; Sp[8] = y*2; goto Lend }}} Here x and y look different but they are simply local temporaries. If we did a liveness analysis, the equality-comparing function could make- equivalent assignments to dead variables. So when comparing L1 and L2, since x and y are dead, the first statements will compare ''equal'', and make x and y equivalent; hence the second statements will compare equal too. Anyway, I'm no expert here; I have not looked at the code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 07:21:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 07:21:32 -0000 Subject: [GHC] #9052: Support a "stable heap" which doesn't get garbage collected In-Reply-To: <045.cef633f00b20a59333331a11354e10ec@haskell.org> References: <045.cef633f00b20a59333331a11354e10ec@haskell.org> Message-ID: <060.0c699515a28601dc671b5b55716cc932@haskell.org> #9052: Support a "stable heap" which doesn't get garbage collected ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by hvr): * cc: hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 07:48:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 07:48:22 -0000 Subject: [GHC] #9157: cmm common block not eliminated In-Reply-To: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> References: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> Message-ID: <063.43a60cdd1ccb8432cd43b2ef87b3c9bc@haskell.org> #9157: cmm common block not eliminated -------------------------------------+------------------------------------ Reporter: wojteknar | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Yes, I think Simon PJ's reason above is exactly why hashes don't include labels: so that the hashes remain stable under elimination of common blocks. After eliminating some blocks, more opportunities for elimination emerge, so the algorithm keeps iterating until there are no more blocks to eliminate. Originally CBE was there to catch a common case of common blocks that occurred in the code we generated for case expressions. But that pattern is handled directly by the code generator (we don't generate the common blocks anymore), and hence CBE is only enabled with -O. As with most optimisations, CBE interacts with other passes, so there may be more (or fewer) opportunities for CBE at different stages during the pipeline. Whether it's worthwhile (a) having another CBE pass (maybe with -O2 only) or (b) moving the existing CBE pass later in the pipeline, is a matter for measurement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 07:53:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 07:53:11 -0000 Subject: [GHC] #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) In-Reply-To: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> References: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> Message-ID: <060.87a5e51c6dbed683f3f73bb78c5c569d@haskell.org> #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) ---------------------------------------+---------------------------------- Reporter: slyfox | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler (NCG) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by simonmar): I have a fix for this, indeed f5879acd018494b84233f26fba828ce376d0f81d was buggy. I'll do some more testing and measurement before I push. This is a blocker for 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 07:58:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 07:58:36 -0000 Subject: [GHC] #9157: cmm common block not eliminated In-Reply-To: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> References: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> Message-ID: <063.82faad8377d548e0c41b60ddf81b00a9@haskell.org> #9157: cmm common block not eliminated -------------------------------------+------------------------------------ Reporter: wojteknar | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jstolarek): > Whether it's worthwhile (a) having another CBE pass (maybe with -O2 only) or (b) moving the existing CBE pass later in the pipeline, is a matter for measurement. I see. It looks like a low-priority thing so I'm leaving investigating that to someone who has access to more computing power than me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 07:58:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 07:58:43 -0000 Subject: [GHC] #9157: cmm common block not eliminated In-Reply-To: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> References: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> Message-ID: <063.46f27b2d9d6728fec8d15fb845023c5c@haskell.org> #9157: cmm common block not eliminated -------------------------------------+------------------------------------ Reporter: wojteknar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jstolarek): * owner: jstolarek => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 08:11:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 08:11:27 -0000 Subject: [GHC] #9157: cmm common block not eliminated In-Reply-To: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> References: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> Message-ID: <063.5ec0dfaa37b28aa9539789eeaf6c4ebc@haskell.org> #9157: cmm common block not eliminated -------------------------------------+------------------------------------ Reporter: wojteknar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by wojteknar): Not generating the identical blocks at all sounds like a good idea to an outsider. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 11:14:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 11:14:33 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.f77c860c46c7c14a5a73e821df3b0953@haskell.org> #9023: Error when using empty record update on binary pattern synonym ---------------------------------+--------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Changes (by simonpj): * cc: cactus (added) * owner: => cactus Comment: Let's not remove the trace. It signals that something quite unexpected is happening ,which should be investigated. Gergo: could you look at why this is happening, since it involves pattern synonyms? Yell if you get stuck and need help from me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 12:06:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 12:06:52 -0000 Subject: [GHC] #9159: cmm case, binary search instead of jump table Message-ID: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> #9159: cmm case, binary search instead of jump table ------------------------------+-------------------------------------------- Reporter: wojteknar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I'm not sure if this is qualifies as a bug or feature request. For case expressions where the scrutinee is Int#,or Int, or probably anything else numerical, GHC generates binary search, where a jump table could easily be used instead. The functions toChunk1# and toChunk2# yield suboptimal code. I found a satisfactory workaround, toChunk3# uses Enum and it is fine. For the attached code it probably does not matter much, but I have 65 cases in my real code, trying to implement a variant of ByteString, which will have the lowest possible storage overhead (just the info table pointer == one word) for lengths up to 64 bytes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 12:26:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 12:26:08 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.75f6bf7998f7b656d9c876271d488a6f@haskell.org> #9023: Error when using empty record update on binary pattern synonym ---------------------------------+--------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by archblob): I was pretty uncomfortable doing that and wondered if something else was going on but I removed it because the caller also tests for the length mismatch and prints pretty much the same message if debug flags is set. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 13:02:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 13:02:19 -0000 Subject: [GHC] #9159: cmm case, binary search instead of jump table In-Reply-To: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> References: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> Message-ID: <063.16fba6d58cc00df38440ea00cba586af@haskell.org> #9159: cmm case, binary search instead of jump table --------------------------------------------+------------------------------ Reporter: wojteknar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): That is `toChunk3#`? Would you like to offer a patch? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 13:10:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 13:10:02 -0000 Subject: [GHC] #9159: cmm case, binary search instead of jump table In-Reply-To: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> References: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> Message-ID: <063.16b400ba01d0c0d4626022d503673e18@haskell.org> #9159: cmm case, binary search instead of jump table --------------------------------------------+------------------------------ Reporter: wojteknar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by wojteknar): > That is toChunk3#? I'm referring to the functions in the attached file. > Would you like to offer a patch? Way beyond my skills, sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 14:27:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 14:27:01 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.4a579fbf276fc74a11a9b2de5e3ed255@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by jstolarek): After spending some time on this today I have to admit that arrow desugaring is still a mystery to me. For example this code: {{{ proc n -> do x <- returnA -< n returnA -< x }}} Is desugared to: {{{ arr (\n -> (n, ())) >>> arr (\ds -> case ds of { (ds2, ds3) -> ds2 }) >>> arr (\ds -> ((ds, ()), ())) >>> ((arr (\ds -> case ds of { (ds2, ds3) -> ds2 }) >>> id) *** id >>> arr (\ds -> case ds of { (x, ds2) -> case ds2 of { () -> x } }) ) >>> arr (\ds -> (ds, ())) >>> arr (\ds -> case ds of { (ds2, ds3) -> ds2 }) >>> id }}} This can be simplified to an identity (as expected), but GHC doesn't do it. This definitely seems like an opportunity for improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 16:31:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 16:31:21 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.f518a9428c468429090418bf333abbf4@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Now, the question is whether we can derive `Coercible (s -> p a s) (s -> p b s)` from `(Rep p, Coercible a b)`, right? Once again, we assume that the only way we can use `Rep` is the rule (*) in comment:15. 1. Decompose `(->)` to get that we need to show `Coercible (p a s) (p b s)`. 2. Use the eta rule requested at the top of #9117 to reduce the goal to `Coercible (p a) (p b)`. 3. Use rule (*) to reduce the goal to `(Rep p, Coercible a b)`. 4. We are done by assumption. This was indeed somewhat harder than the derivation in comment:15 in that it requires the constraint solver to do something it currently cannot (the eta reduction in #9117), but it still doesn't require an asymmetrical rule for `Rep`. Note that the eta rule is easily expressible in Core -- it's just that the constraint solver doesn't know to use it. Does this address your concern, Edward? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 16:43:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 16:43:56 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.1e88871e389d4660899e982dbfbbc0aa@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ekmett): Hrmm, when we have something like {{{ newtype F p f a = F { runF :: p a (f (F p f a)) } }}} do we get stuck again because of the fact that p has two args and the coercion of a has to be used on both sides of it? {{{ Free = F (,) Cofree = F Either }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 16:50:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 16:50:44 -0000 Subject: [GHC] #8828: allow fully applied type families in instance heads In-Reply-To: <045.6152be3035980bd31e93fc1579e85689@haskell.org> References: <045.6152be3035980bd31e93fc1579e85689@haskell.org> Message-ID: <060.cfe7e7770715b2ee3987a75814b84125@haskell.org> #8828: allow fully applied type families in instance heads -------------------------------------+------------------------------------ Reporter: aavogt | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I've thought about this ticket some, and I think implementing this idea is a move in the wrong direction. Implementing this idea feels quite like allowing function applications in patterns. For example, how would we feel about this: {{{ foo :: Bool -> Int foo True = 1 foo (not True) = -1 }}} With some engineering, there is no reason that we couldn't accept a definition such as the one above. After all, `not True` is fully applied to constants and can be reduced to `False`. We can pretend that there is a TH-like stage restriction (somewhat like Simon's quite valid dependency concerns in comment:1) to prevent infinite regress. We can even check to make sure that the pattern match is complete. Yet, this definition smells like rotten eggs to me. Should it be different at the type level? I, personally, think not. What it seems we really want here are ''type pattern synonyms''. Pattern synonyms allow a richer syntax "on the left of an `=`", which is what we want here in types. It so happens that, currently, type patterns are syntactically just types that don't mention type families, but if we separate out a type pattern syntax from a type syntax (which I think is a good idea -- they are different!) then the idea of type families "on the left" becomes even more suspicious and type pattern synonyms make more sense. So, instead of implementing the idea proposed here, I would rather think about type pattern synonyms. How are these related to term pattern synonyms? How would we declare them? Can they be promoted to kinds? etc. What do others think here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 17:07:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 17:07:26 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.944f0254f80120fc56f610415e5ef2b8@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Comment (by carlhowells): If this is possible, it'd be really great to have. For Symbols, too. Just because sometimes Typeable is helpful, and for the times when it is, it's nice for new fancy types to be instances of it as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 17:07:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 17:07:41 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.2b66445f56410735e9c37fc3c3997fd2@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Here, we need more assumptions. We have to assume an instance `Rep p` and an instance `Rep (p a)`. (We need it only for the `a` in question, though there would almost certainly be an axiom asserting `forall a. Rep (p a)`.) So, we assume `(Rep p, Rep (p a), Rep f, Coercible a b)` and wish to prove `Coercible (p a (f (F p f a))) (p b (f (F p f b)))`. We would be doing this in the context of an instance declaration for `Rep (F p f)`, so we can assume that, too. 1. Use transitivity to break our goal down to two sub-goals: `Coercible (p a (f (F p f a))) (p a (f (F p f b)))` and `Coercible (p a (f (F p f b))) (p b (f (F p f b)))`. 2. First sub-goal `Coercible (p a (f (F p f a))) (p a (f (F p f b)))`: a. Use rule (*) to break the goal down to `Rep (p a)` and `Coercible (f (F p f a)) (f (F p f b))`. The first of these is solved by assumption. b. Use rule (*) to get `Rep f` and `Coercible (F p f a) (F p f b)`. The first of these is solved by assumption. c. Use rule (*) to get `Rep (F p f)` and `Coercible a b`. Both are solved by assumption. 3. Second sub-goal `Coercible (p a (f (F p f b))) (p b (f (F p f b)))`: a. Use the #9117 eta rule to reduce the goal to `Coercible (p a) (p b)`. b. Use rule (*) to reduce the goal to `(Rep p, Coercible a b)`. c. Done by assumption. I'm not necessarily saying that the constraint solver is up to this task without help (that is, user annotations or other assistance), but `Rep` with rule (*) seems to be able to support the derivation once found. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 17:38:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 17:38:09 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.2ffcf69abc4e9bbd8678f35ecdc2e6dd@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ekmett): Good trick w/ transitivity! You've won me over on the simpler rule. =) That leaves these: {{{ instance Representational f => Representational (Compose f) instance Representational p => Representational (WrappedArrow p) instance Representational (p a) => Representational (WrappedArrow p a) }}} ...and if I understand correctly, the form we're talking about also gets stuck whenever an earlier argument occurs 'under' a later argument, e.g. the `s` when we try to define `instance Representational StateT` occurs under the `m` but everything else should work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 18:36:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 18:36:46 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.ea460aacb0c361821dae492b5dade7bf@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): `instance Rep f => Rep (Compose f)` where `newtype Compose f g a = Compose (f (g a))`: We wish to show `forall a. Coercible (m (f a)) (m (g a))` from `Rep m` and `Coercible f g`. Fix `a`. 1. Use rule (*) to get `Coercible (f a) (g a)`. 2. Use #9117's eta to get `Coercible f g`. We're done. `instance Rep p => Rep (WrappedArrow p)` where `newtype WrappedArrow a b c = WrappedArrow (a b c)`: We wish to show `forall a. Coercible (p x a) (p y a)` from `Rep p` and `Coercible x y`. Fix `a`. 1. Use #9117's eta to get `Coercible (p x) (p y)`. 2. Use rule (*), and we're done. `instance Rep (p a) => Rep (WrappedArrow p a)`: We wish to show `Coercible (p a x) (p a y)` from `Rep (p a)` and `Coercible x y`. 1. Use rule (*), and we're done. -------------------------- Unfortunately, I can't counter the point about `StateT` -- we still can't express that `s` should be representational if `m`'s argument is. But, what about this: {{{ newtype Flip0 f a b = Flip0 (f b a) -- not used; just to better understand Flip1 newtype Flip1 f a b c = Flip1 (f b a c) instance Rep m => Rep (Flip1 StateT m) }}} Would that work for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 20:33:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 20:33:17 -0000 Subject: [GHC] #9159: cmm case, binary search instead of jump table In-Reply-To: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> References: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> Message-ID: <063.4f348d353fe59dbcc930d157ef8ef94e@haskell.org> #9159: cmm case, binary search instead of jump table --------------------------------------------+------------------------------ Reporter: wojteknar | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by rwbarton): * type: bug => feature request Comment: Presumably the case on an `Int#` uses a binary search because there's no reason the cases need to be consecutive integers: imagine you change the last case to `1000000# -> Chunk08 w#`. Now a jump table is not a good idea. The case on a `Nat` knows that the tag integer identifying the constructor will be in the range from 0 to 8. We would need some heuristic for when to use binary search vs. a jump table (or perhaps both, if the cases to be matched consist of multiple ranges of consecutive integers). Maybe worth looking into what C compilers do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 20:51:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 20:51:47 -0000 Subject: [GHC] #9159: cmm case, binary search instead of jump table In-Reply-To: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> References: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> Message-ID: <063.491371a82b7b22d123a3f6cd7cbb10ad@haskell.org> #9159: cmm case, binary search instead of jump table --------------------------------------------+------------------------------ Reporter: wojteknar | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by wojteknar): * priority: low => lowest Comment: Okay, this really is a corner case of case statement. For one range the heuristics could be "fill factor". For multiple ranges it gets really difficult. The workaround with Enum and tagToEnum# works fine. Perhaps I should just close this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 22:43:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 22:43:31 -0000 Subject: [GHC] #9052: Support a "stable heap" which doesn't get garbage collected In-Reply-To: <045.cef633f00b20a59333331a11354e10ec@haskell.org> References: <045.cef633f00b20a59333331a11354e10ec@haskell.org> Message-ID: <060.0349e864d1640b523d19820886fba99e@haskell.org> #9052: Support a "stable heap" which doesn't get garbage collected ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): A little musing about implementation: we could go about representing the stable generation in two ways. One is that the stable generation is an extra generation which is always present (e.g. we always allocate a field for it when initializing the storage manager), but the GC ignores it; the other is the stable generation is "just another generation" (i.e. to have g0, g1 and a stable gen, the user needs to pass -G3) but specially flagged to behave differently. I think the first option is more user-friendly, but the latter option makes for cleaner implementation, because we don't have to +1 the value of the 'generations' configuration flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 23:54:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 23:54:10 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule Message-ID: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> #9160: Panic: Template variable unbound in rewrite rule ----------------------------------+--------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- Installing `singletons-1.0` with GHC 7.8.2 on OS X 10.9.2 fails: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-apple-darwin): Template variable unbound in rewrite rule }}} Full build log attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 23:59:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 23:59:10 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.c7ca536b504ed35dd78ad2a0d6ae9565@haskell.org> #9160: Panic: Template variable unbound in rewrite rule ---------------------------------------+---------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 4524 ---------------------------------------+---------------------------------- Changes (by mietek): * related: => 4524 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 2 23:59:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jun 2014 23:59:30 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.be6ffcf6c0bc29eabbaec510dd80d4bb@haskell.org> #9160: Panic: Template variable unbound in rewrite rule ---------------------------------------+---------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4524 ---------------------------------------+---------------------------------- Changes (by mietek): * related: 4524 => #4524 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 02:47:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 02:47:02 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.e21bdaf77fe4d013d985de2f4227b2e0@haskell.org> #9160: Panic: Template variable unbound in rewrite rule ---------------------------------------+---------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4524 ---------------------------------------+---------------------------------- Description changed by mietek: Old description: > Installing `singletons-1.0` with GHC 7.8.2 on OS X 10.9.2 fails: > > {{{ > ghc: panic! (the 'impossible' happened) > (GHC version 7.8.2 for x86_64-apple-darwin): > Template variable unbound in rewrite rule > }}} > > Full build log attached. New description: Installing `singletons-1.0` with GHC 7.8.2 on OS X 10.9.2 fails: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-apple-darwin): Template variable unbound in rewrite rule }}} See also [https://github.com/goldfirere/singletons/issues/83 goldfirere/singletons#83] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 02:52:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 02:52:37 -0000 Subject: [GHC] #9161: Pattern synonyms interact badly with data kinds Message-ID: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> #9161: Pattern synonyms interact badly with data kinds -------------------------------------------------+------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: Keywords: renamer, pattern synonyms, | 7.8.2 data kinds | Operating System: Architecture: Unknown/Multiple | Linux Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------------+------------------------- If we define a pattern `A` and use it as a type: {{{ {-# LANGUAGE PatternSynonyms, DataKinds #-} pattern A = () b :: A b = undefined }}} we get the following error: {{{ Prelude> :load tmp.XDGqzccOAV.hs [1 of 1] Compiling Main ( /tmp/tmp.XDGqzccOAV.hs, interpreted ) /tmp/tmp.XDGqzccOAV.hs:5:9: GHC internal error: ?A? is not in scope during type checking, but it passed the renamer tcl_env of environment: [] In the type signature for ?blah?: blah :: A Failed, modules loaded: none. }}} Also occurs with different arities of `A` (the arity of the pattern and type can differ) and defining it as an operator (enabling the `TypeOperators` pragma). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 04:32:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 04:32:29 -0000 Subject: [GHC] #9162: fix missing space in documentation Message-ID: <045.e1924d6715b51cc4ed862ff56c7f8600@haskell.org> #9162: fix missing space in documentation ------------------------------------+------------------------------------- Reporter: ryantm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- From d37f69f60227b7e232dd6bb334f5b07f6b6f9386 Mon Sep 17 00:00:00 2001 From: Ryan Mulligan Date: Mon, 2 Jun 2014 21:20:01 -0700 Subject: [PATCH] fix missing space --- docs/users_guide/codegens.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/users_guide/codegens.xml b/docs/users_guide/codegens.xml index 2eb9408..d2a805a 100644 --- a/docs/users_guide/codegens.xml +++ b/docs/users_guide/codegens.xml @@ -38,7 +38,7 @@ You must install and have LLVM available on your PATH for the LLVM code generator to work. Specifically GHC needs to be able to call the - optand llc tools. Secondly, if you + opt and llc tools. Secondly, if you are running Mac OS X with LLVM 3.0 or greater then you also need the Clang c compiler compiler available on your PATH. -- 1.9.3 available on github: https://github.com/ryantm/ghc/commit/d37f69f60227b7e232dd6bb334f5b07f6b6f9386 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 04:47:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 04:47:13 -0000 Subject: [GHC] #9162: fix missing space in documentation In-Reply-To: <045.e1924d6715b51cc4ed862ff56c7f8600@haskell.org> References: <045.e1924d6715b51cc4ed862ff56c7f8600@haskell.org> Message-ID: <060.b69a4ffe20b344e04037b145a7b9f7d7@haskell.org> #9162: fix missing space in documentation -------------------------------------+------------------------------------ Reporter: ryantm | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: Pushed, thanks. {{{ commit 2da439ae8b27e7a6f250831977aa887532493de6 Author: Ryan Mulligan Date: Mon Jun 2 21:20:01 2014 -0700 fix missing space }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 06:29:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 06:29:49 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.443fc3f662bc38cca4acd4614fbb917c@haskell.org> #9023: Error when using empty record update on binary pattern synonym ---------------------------------+--------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by archblob): I had no idea assertions were enabled only {{{-DDEBUG}}}, lesson learned. Here is the actual panic: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20140530 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/PatSyn.lhs line 268 patSynInstArgTys P [t, t] [(t, t)] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 06:42:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 06:42:11 -0000 Subject: [GHC] #9161: Pattern synonyms interact badly with data kinds In-Reply-To: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> References: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> Message-ID: <066.77b53a1fb2d6f17de230e2fd6c006b9e@haskell.org> #9161: Pattern synonyms interact badly with data kinds -------------------------+------------------------------------------------- Reporter: | Owner: cactus Iceland_jack | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 lowest | Keywords: renamer, pattern synonyms, Component: | data kinds Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Linux | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Changes (by simonpj): * cc: cactus (added) * owner: => cactus Comment: Probably we should not promote pattern synonyms to the type level, so the program should be rejected with "you can't use a pattern synonym as a type, even with !DataKinds" error. Gergo might you look at this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 11:25:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 11:25:34 -0000 Subject: [GHC] #8828: allow fully applied type families in instance heads In-Reply-To: <045.6152be3035980bd31e93fc1579e85689@haskell.org> References: <045.6152be3035980bd31e93fc1579e85689@haskell.org> Message-ID: <060.eb7b4d9dc15dc85b3b043d72d65e97e6@haskell.org> #8828: allow fully applied type families in instance heads -------------------------------------+------------------------------------ Reporter: aavogt | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I rather agree with Richard here. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 13:36:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 13:36:19 -0000 Subject: [GHC] #9163: Ptr should have a phantom role Message-ID: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> #9163: Ptr should have a phantom role ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In `GHC.Ptr` we see {{{ type role Ptr representational data Ptr a = Ptr Addr# deriving (Eq, Ord) }}} with no comments. Why is `Ptr` representational? In the same module we have `castPtr`: {{{ castPtr :: Ptr a -> Ptr b castPtr (Ptr addr) = Ptr addr }}} which unpacks and repacks a `Ptr`. If `Ptr` was phantom, we could use `coerce`. And that in turn would actually make a lot of code more efficient ? there are lots of calls to `castPtr`. Specifically, in `nofib`, I tried implementing `castPtr` with `unsafeCoerce`. Then I found: * 12% less allocation in `reverse-complem` * 7.3% less allocation in `fasta`. * Binary sizes fell 0.1%. Both these benchmarks are ones that do a ''lot'' of I/O, and it turns out that `GHC.IO.Handle.Text.$wa1` has a `castPtr` that (all by itself) accounts for 12% of `reverse-complem`'s total allocation! So making `castPtr` free is good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 13:37:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 13:37:52 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.5de3344825384ab098895aae3ea9241d@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Richard says: It seemed clear to me that `Ptr` ''should'' be representational, thinking that we don't want to coerce a `Ptr Int` to a `Ptr Bool`. I don't see any reason why this couldn't be changed. Why is `Ptr` a `data` not a `newtype`? If it were a newtype, we could keep the role annotation and use `coerce` internally, according to the updated Coercible solver. Answer (from Simon): because the payload is an unboxed `Addr#`, so `Ptr` boxes it. A `newtype` can't have an unboxed payload. However, it is crucial that `FunPtr` have a representational argument, as normaliseFfiType' depends on this fact. There is a brief comment in `TcForeign`, but clearly more comments are necessary. Will do shortly. If we want to change `FunPtr`'s role, `normaliseFfiType'` would have to be updated, too, but it shouldn't be hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 13:39:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 13:39:19 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.ce141978ef88fcf685bae906375d3524@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Austin says: I think Ptr should almost certainly be representational, as it is a case where the actual underlying value is the same, but what it points to is not (I'll ignore castPtr here for a second). This makes me think of something I talked about before with Andres - in general, phantom roles seem somewhat dangerous, and I kind of wonder if they should be inferred by default. Often you see some code along the lines of: {{{ module A ( Bar, newBarInt ) where data Bar a = Bar Int newBarInt :: Int -> Bar Int }}} where A is exported to the client and the module boundary enforces some restrictions on 'Bar', like what types we can instantiate `Bar a` to (the example is dumb but bear with me). In the above example, I believe the `a` in `Bar a` would be inferred at phantom role. The question I have is: what legitimate case would there be for phantom roles like this? Such usage of phantom type parameters seems very common, but in almost *all* cases I can't think of a reason why I would ever want a user to be allowed to `coerce` away the type information, if the `a` parameter was phantom. It seems like in the above example, I would almost certainly want `a` to be representational instead. What other cases exist for legitimate phantom roles such as this where we want this inference? I wonder if instead we should require an explicit role annotation for phantoms in this case - not the other way around. `Ptr` is a similar story - by default it would maybe seem reasonable to be phantom, but that seems like an especially grievous error, given we don't want people to `poke` incorrect values in or something (again, ignoring castPtr for a second, but I think the general idea holds.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 13:40:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 13:40:08 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.dfef516682b6b49f71c02a5525906eb5@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Well, remember that even if Ptr has a phantom role, the two types (Ptr Int) and (Ptr Double) would be different types. It's just that you could *coerce* between them. Which is perhaps not unreasonable. Indeed that is precisely what castPtr does. It?s not silent or implicit. I still don't see why it would be bad to make `Ptr` phantom. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 13:47:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 13:47:46 -0000 Subject: [GHC] #9148: tryReadMVar locks up the process with +RTS -N2 or greater In-Reply-To: <047.60c6cfd551628c7f0ad6d52e55f6dbba@haskell.org> References: <047.60c6cfd551628c7f0ad6d52e55f6dbba@haskell.org> Message-ID: <062.647009d55187e2e96d7452c5c03bd2bd@haskell.org> #9148: tryReadMVar locks up the process with +RTS -N2 or greater -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 13:48:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 13:48:01 -0000 Subject: [GHC] #9078: Segfault with makeStableName In-Reply-To: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> References: <047.bf45402f1725b509aa19781248b9a4a6@haskell.org> Message-ID: <062.54bf86e016a027d7081cea2f5f8a853a@haskell.org> #9078: Segfault with makeStableName -------------------------------------+------------------------------------ Reporter: robertce | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged into 7.8 branch for 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 13:48:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 13:48:16 -0000 Subject: [GHC] #9068: Don't uninstall signal handlers if none were installed In-Reply-To: <044.7794aa4ce82ed5ecdcf0c07847cdd3ac@haskell.org> References: <044.7794aa4ce82ed5ecdcf0c07847cdd3ac@haskell.org> Message-ID: <059.26b08fac773becde8e6583edd252ef84@haskell.org> #9068: Don't uninstall signal handlers if none were installed ------------------------------------------------+-------------------------- Reporter: tomgr | Owner: Type: bug | simonmar Priority: normal | Status: closed Component: Runtime System | Milestone: 7.8.3 Resolution: fixed | Version: 7.8.2 Operating System: Windows | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 13:48:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 13:48:53 -0000 Subject: [GHC] #9021: [CID43168] rts/linker.c has a memory leak in the dlopen/dlerror code In-Reply-To: <046.338d06ed46ba2865fda90272f333c349@haskell.org> References: <046.338d06ed46ba2865fda90272f333c349@haskell.org> Message-ID: <061.c60e6e631525bcafd17ebb32b2a0407d@haskell.org> #9021: [CID43168] rts/linker.c has a memory leak in the dlopen/dlerror code -------------------------------------+------------------------------------- Reporter: hgolden | Owner: simonmar Type: bug | Status: closed Priority: low | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: linker, memory Operating System: POSIX | leak, coverity Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: This was already merged, it seems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 13:48:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 13:48:59 -0000 Subject: [GHC] #9001: unexpected runtime crash In-Reply-To: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> References: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> Message-ID: <060.f54703d3f0ec51e7cf1f1a6f448bbf02@haskell.org> #9001: unexpected runtime crash -------------------------------------+------------------------------------ Reporter: jwlato | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 13:49:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 13:49:12 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.5d5284480ae00d8b58364a6aec38d39a@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: libraries | Version: 7.8.1-rc2 (other) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 13:49:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 13:49:32 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.84dd40de89c9d125131d42c739028367@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: closed Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: This should all be merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 13:49:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 13:49:38 -0000 Subject: [GHC] #8475: Library docs: broken links to Foreign.ForeignPtr In-Reply-To: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> References: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> Message-ID: <062.b457c618758041bf37158befef9422f0@haskell.org> #8475: Library docs: broken links to Foreign.ForeignPtr -------------------------------------+------------------------------------ Reporter: simonmar | Owner: hellertime Type: bug | Status: closed Priority: high | Milestone: 7.8.3 Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 13:53:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 13:53:22 -0000 Subject: [GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) In-Reply-To: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> References: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> Message-ID: <068.3bbeed60db225c2c8676568bdefa5cf1@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: infoneeded => closed * resolution: => fixed Comment: I do believe this is fixed in 396648eebaa1144d4d1f5326db716e8130f73732 - closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 14:00:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 14:00:05 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.92e5899d610d0219af6f1d6defe9fa3a@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Slightly off topic, but maybe `GHC.IO.Handle.Text` can be written so that `castPtr` is not needed. It seems it always works with `Ptr Word8`, but exposes an API that uses `Ptr a` as a generic pointer. The type `a` is never needed inside `GHC.IO.Handle.Text`... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 14:17:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 14:17:22 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.6cbc50dfe1331992d349e8c654883005@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): While I hear Austin's concerns, I tend to agree with Simon here. We don't want to consider `Ptr Int` and `Ptr Bool` to be the same types, but we ''do'' want to allow a knowledgeable programmer to get from one to the other for free. This seems to be a great use case for `coerce`. This idea extends to other cases where GHC infers phantom roles. In case it got lost, I'll ask again: why is `Ptr` a datatype, not a newtype? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 14:27:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 14:27:20 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.af0fae5588804c08b15c43bfe0719213@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Replying to [comment:5 goldfire] > In case it got lost, I'll ask again: why is `Ptr` a datatype, not a newtype? See my reply in comment 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 14:28:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 14:28:13 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.a7b406c7ffd5777612636a0d3077069a@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * cc: simonmar (added) Comment: Adding Simon Marlow who may want to comment on comment 4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 14:52:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 14:52:58 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.16a2a00d6e2e7dab278787836b90a1a7@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I tried it, and hPutBuf & Co are called with `Ptr Word8` (sometimes called `LitString`) in all cases but `BufWrite.bPutCStringLen`, where we have a `Ptr CChar`, where `CChar` is a newtype. So by using `coerce` there (and `unsafeCoerce` during bootstrapping), we get the best of boths worlds: The more restrictive role and the free behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 15:34:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 15:34:55 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.46764d208bcfb3cdad2ce8bfd2b7310d@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by ross): Replying to [comment:11 jstolarek]: > I have a few questions about implementation in `DsArrows` - I think these go to Ross. > > 1. What is the purpose of the stack created in the desugaring process? > 2. How do I read the notation describing each case of `dsCmd`? Eg. the `HsCmdApp` case has this comment: > > {{{ > -- D; ys |-a cmd : (t,stk) --> t' > -- D, xs |- exp :: t > -- ------------------------ > -- D; xs |-a cmd exp : stk --> t' > -- > -- ---> premap (\ ((xs),stk) -> ((ys),(e,stk))) cmd > }}} > What is `|-a`, `xs` and `ys`? What is the difference between `:` and `::`? Could you tell me how to read this particular comment? I should then be able to understand all the others. EDIT: Is there a semantic difference between `,` and `;` as in `D; ys` vs. `D, xs`? Yes, those differences in punctuation are significant. A type judgement for an expression (ignoring constraints) looks like {{{ D |- exp :: t }}} but one for a command looks like {{{ D; xs |-a cmd : stk --> t }}} Here * a is the type of arrow for this command * D is the environment of the surrounding proc expression * xs are variables defined within the proc expression, which will be inputs to the arrow * stk is a list of anonymous inputs to the arrow * t is the output type of the arrow So the translation of this command should be an expression with type {{{ D |- [[proc (xs) -> cmd]] : a ((xs),stk) t }}} In this particular rule, exp is typed using an ordinary expression judgement. It can use both external valuables (D) and those local to the proc expression (xs), so these are combined in a single environment. (Commands, in contrast, need to keep these separate.) The value of that expression is then pushed onto stk, which, together with xs, is input to cmd. (The lambda rule for commands lets you take a value from the stack and put it in the local environment, giving it a name.) The remaining wrinkle here is that cmd may not need all the variables in xs, but just the subset ys of xs, so the function inside the premap may also trim the environment from xs to ys. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 15:48:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 15:48:03 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.f7f8a814839f06c7153d10c6202c420c@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by ross): Replying to [comment:12 jstolarek]: > After spending some time on this today I have to admit that arrow desugaring is still a mystery to me. For example this code: > > {{{ > proc n -> do > x <- returnA -< n > returnA -< x > }}} > > Is desugared to: > > {{{ > arr (\n -> (n, ())) >>> > arr (\ds -> case ds of { (ds2, ds3) -> ds2 }) >>> > arr (\ds -> ((ds, ()), ())) >>> > ((arr (\ds -> case ds of { (ds2, ds3) -> ds2 }) >>> id) *** id >>> > arr (\ds -> case ds of { (x, ds2) -> case ds2 of { () -> x } }) ) >>> > arr (\ds -> (ds, ())) >>> > arr (\ds -> case ds of { (ds2, ds3) -> ds2 }) >>> > id > }}} > This can be simplified to an identity (as expected), but GHC doesn't do it. This definitely seems like an opportunity for improvement. The simplifier reduces that to an identity using rules in Control.Arrow (though more rules are probably needed to handle slightly more complex cases). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 16:01:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 16:01:31 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.274979d46318638de30ce1914d89c350@haskell.org> #9023: Error when using empty record update on binary pattern synonym ---------------------------------+--------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by archblob): I'm sorry for hijacking this thread again but I'm trying to understand all of this stuff and tinkering with it does it best for me. As I understand it, {{{tcTyConAppArgs}}} will look through synonyms but not through newtypes. The thing is it will also not get us the args we want in the case of nested application, so in this case for tuples, but the bug will manifest itself for any nested application. I've attached a patch with a new fix and I'm wondering if you can take a look at it. The fix works for this test case but there may be things that i overlooked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 16:12:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 16:12:21 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.4411eef88e062131846e98d0b2d5a32a@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"b4856f9f4f0fb3db473901b247d3fa94a11c25a0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b4856f9f4f0fb3db473901b247d3fa94a11c25a0" Do pretty-printing of TyThings via IfaceDecl (Trac #7730) All the initial work on this was done fy 'archblob' (fcsernik at gmail.com); thank you! I reviewed the patch, started some tidying, up and then ended up in a huge swamp of changes, not all of which I can remember now. But: * To suppress kind arguments when we have -fno-print-explicit-kinds, - IfaceTyConApp argument types are in a tagged list IfaceTcArgs * To allow overloaded types to be printed with =>, add IfaceDFunTy to IfaceType. * When printing data/type family instances for the user, I've made them print out an informative RHS, which is a new feature. Thus ghci> info T data family T a data instance T Int = T1 Int Int data instance T Bool = T2 * In implementation terms, pprIfaceDecl has just one "context" argument, of type IfaceSyn.ShowSub, which says - How to print the binders of the decl see note [Printing IfaceDecl binders] in IfaceSyn - Which sub-comoponents (eg constructors) to print * Moved FastStringEnv from RnEnv to OccName It all took a ridiculously long time to do. But it's done! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 16:16:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 16:16:46 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.c327274a489086b6a34b767629148602@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by simonpj): Well that was a struggle, but I finally pushed this through. You'd done the heavy lifting but there were some dark corners I had to peer into. Thanks for making this happen Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 16:17:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 16:17:46 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.660996f14fec6c18fe8de655ba10dc32@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by jstolarek): Thanks Ross. I think I still don't understand the stk thing. What are the "anonymous inputs to the arrow"? Is that described in any of the arrow papers? > The simplifier reduces that to an identity using rules in Control.Arrow How can I observe that? Using `-ddump-simpl` only shows that this huge expression is split into many smaller functions but it doesn't look like anything gets simplified. Using `-ddump-rules` and `-ddump-rule-rewrites` I see that some rules fire but none of them seems to optimize the above expression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 16:26:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 16:26:31 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.061e13db81f477f872e991f1b93dd5a9@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"dd9943472d385b55f9baa56780f333a190794bcf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dd9943472d385b55f9baa56780f333a190794bcf" Comments only (related to Trac #7730) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 16:27:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 16:27:28 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.8a38f61b3421d0274d91cf5a647c86b5@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): Oh, thank you. I'm glad that I could help and this is all over. I think the ticked can be marked as fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 16:29:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 16:29:25 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.a0d54f62b01d8a10b7a30ee39df37018@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Well regardless of the decision about the role of `Ptr`, what you describe sounds like an improvement anyway, getting rid of (always suspicious) `castPtr` calls. If you grep in the base library you'll find quite a few others. Can you eliminate them in the same way? I think this would be a nice improvement, if you cared to push it through. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 16:45:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 16:45:58 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.f4d0aa61cd4c091ae4a9d00658e6757f@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Just added a new section to [wiki:Roles2#IntegratingRepintothesolver the wiki page] about difficulty of integrating into the solver. Despite my success yesterday at defeating all of Edward's challenges, it seems his rule will lead to a better implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 16:49:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 16:49:07 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.8f64bc1985c9a41e61923e6cc937ea07@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): +1 from me on making `Ptr`'s role phantom. But especially I don't think it should be ''exactly'' representational; either phantom or nominal must be better. A `Ptr a` is not actually a pointer to a Haskell heap object of type `a`, for any type `a`. Neither the representation of the `Ptr a` itself nor the representation of the thing-being-pointed-to depends on the ''representation'' of `a` specifically. I might define a `newtype BigEndianInt = BigEndianInt Int` and write a `Storable` instance that uses a big-endian format when `peek`ing or `poke`ing. Then it isn't any more valid to cast from `Ptr Int` to `Ptr BigEndianInt` than it is to cast from `Ptr Int` to `Ptr Double`. Similar comments probably apply to Austin's hypothetical example of an inferred phantom role. If the library author does not want `Bar` to have a phantom role, they probably do not want it to have a representational role either. But it's hard to say without a more fledged-out example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 16:52:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 16:52:58 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.c6507d7413ae466fd5a745a38b514f04@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Helpful comments, rwbarton. Is the same true for `FunPtr`? I would assume so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 16:54:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 16:54:41 -0000 Subject: [GHC] #9128: Possible bug in strictness analyzer when where clause declared NOINLINE In-Reply-To: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> References: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> Message-ID: <060.a9122dd8fd0a349877b3360afa82ddda@haskell.org> #9128: Possible bug in strictness analyzer when where clause declared NOINLINE ---------------------------------+----------------------------------------- Reporter: aalevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strictness bytestring Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | ---------------------------------+----------------------------------------- Comment (by rwbarton): Someone on #haskell reported this: http://lpaste.net/105005 which looks like it might be the same bug, but sadly they didn't include enough details to reproduce it (and my 5-minute attempt to do so by guessing the rest of the program was unsuccessful). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 16:59:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 16:59:06 -0000 Subject: [GHC] #9128: Possible bug in strictness analyzer when where clause declared NOINLINE In-Reply-To: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> References: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> Message-ID: <060.88167cb4e4b4909f5927c6756258ef38@haskell.org> #9128: Possible bug in strictness analyzer when where clause declared NOINLINE ---------------------------------+----------------------------------------- Reporter: aalevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strictness bytestring Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | ---------------------------------+----------------------------------------- Comment (by aalevy): @rwbarton, know who it was? It does look related. I would like to try and get info from them to help me track this down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 17:00:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 17:00:12 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.4bbb957803287beff599f7a04046f9db@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): Replying to [comment:11 goldfire]: > Helpful comments, rwbarton. Is the same true for `FunPtr`? I would assume so. My knee-jerk reaction is "not sure"; I am thinking that while the normal way to consume a `Ptr` is to `peek` and `poke` it, the normal way to consume a `FunPtr` is with a `foreign import ccall "dynamic"` wrapper, and I'm not sure they are obviously analogous situations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 17:05:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 17:05:39 -0000 Subject: [GHC] #9128: Possible bug in strictness analyzer when where clause declared NOINLINE In-Reply-To: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> References: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> Message-ID: <060.34bc3413bb5921ea4dd16c8a5515c2e3@haskell.org> #9128: Possible bug in strictness analyzer when where clause declared NOINLINE ---------------------------------+----------------------------------------- Reporter: aalevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strictness bytestring Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | ---------------------------------+----------------------------------------- Comment (by rwbarton): Replying to [comment:6 aalevy]: > @rwbarton, know who it was? It does look related. I would like to try and get info from them to help me track this down. freenode Web user `ticktockman` (http://ircbrowse.net/browse/haskell?id=18255857×tamp=1401773327#t1401773327). Good luck :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 17:34:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 17:34:30 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.dd37db578a87620f016278b1862352ca@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): So I've been assuming that `castPtr` was free all this time, and it turns out it isn't! Please make it free. We can't change the type of `hPutBuf` and friends without potentially breaking code. There's no better choice than `Ptr a` here, because we don't know the type of the underlying data. Making it `Ptr Word8` would just force the caller to use `castPtr` sometimes without any benefit. e.g. `Ptr CChar` is also a sensible choice, but it could in reality be anything. It does look like the two `castPtr`s in `bufWrite` are unnecessary, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 17:44:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 17:44:04 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.1e7c439ea3146b58a310c63d7e0009f6@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by ross): Replying to [comment:15 jstolarek]: > Thanks Ross. I think I still don't understand the stk thing. What are the "anonymous inputs to the arrow"? Is that described in any of the arrow papers? They are command arguments, the arrow analogue of function arguments. But with arrows they have to be tupled up with the local environment as the input to the arrow. In the notation paper (section 3.2) these arguments are attached to the environment with a series of pairings, but before 7.8 I had to change the representation to fit with GHC's constraint-based typechecker. Now the environment and stack are separate tuples, combined in a pair. > > The simplifier reduces that to an identity using rules in Control.Arrow > > How can I observe that? Using `-ddump-simpl` only shows that this huge expression is split into many smaller functions but it doesn't look like anything gets simplified. Using `-ddump-rules` and `-ddump-rule-rewrites` I see that some rules fire but none of them seems to optimize the above expression. I used -O as well (this is with GHC 7.8.2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 21:34:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 21:34:33 -0000 Subject: [GHC] #9164: Hunt down uses of `castPtr` Message-ID: <046.786745c4f6f3f83d0a16b89841bd178e@haskell.org> #9164: Hunt down uses of `castPtr` ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This bug is a fork from #9163: nomeata: Slightly off topic, but maybe `GHC.IO.Handle.Text` can be written so that `castPtr` is not needed. It seems it always works with `Ptr Word8`, but exposes an API that uses `Ptr a` as a generic pointer. The type `a` is never needed inside `GHC.IO.Handle.Text`... I tried it, and `hPutBuf` & Co are called with `Ptr Word8` (sometimes called LitString) in all cases but `BufWrite.bPutCStringLen`, where we have a `Ptr CChar`, where `CChar` is a newtype. So by using coerce there (and `unsafeCoerce` during bootstrapping), we get the best of boths worlds: The more restrictive role and the free behaviour. SPJ: Well regardless of the decision about the role of `Ptr`, what you describe sounds like an improvement anyway, getting rid of (always suspicious) `castPtr` calls. If you grep in the base library you'll find quite a few others. Can you eliminate them in the same way? I think this would be a nice improvement, if you cared to push it through. simonmar: So I've been assuming that `castPtr` was free all this time, and it turns out it isn't! Please make it free. We can't change the type of `hPutBuf` and friends without potentially breaking code. There's no better choice than `Ptr a` here, because we don't know the type of the underlying data. Making it `Ptr Word8` would just force the caller to use `castPtr` sometimes without any benefit. e.g. `Ptr CChar` is also a sensible choice, but it could in reality be anything. It does look like the two `castPtrs` in `bufWrite` are unnecessary, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 21:34:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 21:34:59 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.d6d388a9b54caf008aa8b7cdfcc0c8ac@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9164 -------------------------------------+------------------------------------ Changes (by nomeata): * related: => #9164 Comment: Discussion about `castPtr` moved to #9164. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 21:36:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 21:36:49 -0000 Subject: [GHC] #9164: Hunt down uses of `castPtr` In-Reply-To: <046.786745c4f6f3f83d0a16b89841bd178e@haskell.org> References: <046.786745c4f6f3f83d0a16b89841bd178e@haskell.org> Message-ID: <061.b272d2e1183124a540ccd9e1e8ed75c2@haskell.org> #9164: Hunt down uses of `castPtr` -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): > We can't change the type of hPutBuf and friends without potentially breaking code. Is there a stability guarantee on things in the `GHC` namespace? The module name tells me ?this is lowevel stuff and may change?, at least between GHC releases and the usual `base` bump. Also, given that the docs state > hPutBuf hdl buf count writes count 8-bit bytes from the buffer buf to the handle hdl. It returns (). I?d say that `Ptr Word8` is fine ? that is how `hPutBuf` uses it, and if I want to pass a `Ptr Double`, I have to think about whether that works. Having to call `castPtr` makes me think about it. (If you agree with this, then this might be a nice ZuriHac beginner task.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 3 23:43:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jun 2014 23:43:16 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.c35cfbbd999f2d7fcca27eb6502e268b@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by ross): Here's a different suggestion for rebinding that is perhaps more analogous to the expression case. We could consider do and if commands as sugar for more primitive commands: {{{ do { p <- cmd; stmts } = cmd `bind` \ p -> do { stmts } do { cmd; stmts } = cmd `bind_` do { stmts } do { let defs; stmts } = let defs in do { stmts } do { cmd } = cmd if exp then cmd1 else cmd2 = (| ifThenElseA cmd1 cmd2 |) exp }}} (remember these are commands, not expressions), given the ordinary Haskell definitions {{{ bind :: Arrow a => a (e,s) b -> a (e,(b,s)) c -> a (e,s) c u `bind` f = arr id &&& u >>> arr (\ ((e,s),b) -> (e,(b,s))) >>> f bind_ :: Arrow a => a (e,s) b -> a (e,s) c -> a (e,s) c u `bind_` v = arr id &&& u >>> arr fst >>> v ifThenElseA :: ArrowChoice a => a (e,s) r -> a (e,s) r -> a (e,(Bool,s)) r ifThenElseA thenPart elsePart = arr split >>> thenPart ||| elsePart where split (e, (True, s)) = Left (e, s) split (e, (False, s)) = Right (e, s) }}} Then rebinding would just use whatever definitions of these names are in scope, and they could be associated with {{{BindStmt}}}, etc, in a similar way to expressions. But would this be enough for the people who want rebinding? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 00:14:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 00:14:22 -0000 Subject: [GHC] #9165: Export TimerManager from GHC.Event Message-ID: <049.21fd1c961d7a9c57f5d1deeb4c2c655b@haskell.org> #9165: Export TimerManager from GHC.Event -------------------------------------------+------------------------------- Reporter: basvandijk | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- [http://hackage.haskell.org/package/base-4.7.0.0/docs/GHC-Event.html GHC.Event] exports `getSystemTimerManager` but not the actual `TimerManager` type. I propose to export it so that the haddocks are properly linked and users can actually refer to `TimerManager` in their type signatures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 07:31:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 07:31:04 -0000 Subject: [GHC] #9164: Hunt down uses of `castPtr` In-Reply-To: <046.786745c4f6f3f83d0a16b89841bd178e@haskell.org> References: <046.786745c4f6f3f83d0a16b89841bd178e@haskell.org> Message-ID: <061.97b07881814784c8d50e73c9af995101@haskell.org> #9164: Hunt down uses of `castPtr` -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): `hPutBuf` and friends are re-exported by `System.IO`. > I?d say that Ptr Word8 is fine ? that is how hPutBuf uses it, and if I want to pass a Ptr Double, I have to think about whether that works. Having to call castPtr makes me think about it. The data in the buffer returned could be any type. Now, whether we want to represent "any type" as `Ptr a` or `Ptr Word8` is debatable, but since we've had this API for a long time already, and changing it to `Ptr Word8` could break some code, I don't see a good argument for changing it. `castPtr` should be free. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 07:47:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 07:47:52 -0000 Subject: [GHC] #9165: Export TimerManager from GHC.Event In-Reply-To: <049.21fd1c961d7a9c57f5d1deeb4c2c655b@haskell.org> References: <049.21fd1c961d7a9c57f5d1deeb4c2c655b@haskell.org> Message-ID: <064.4c0e433f620e28febfaed4b04b48ca2a@haskell.org> #9165: Export TimerManager from GHC.Event -------------------------------+------------------------------------------- Reporter: basvandijk | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"fe59334988fea384b119b7ef8372147b5c246bbf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fe59334988fea384b119b7ef8372147b5c246bbf" Export `TimerManager` from GHC.Event (re #9165) This just addresses the specific issue raised in #9165. However, I've noticed the Haddock comments need to be improved, which will be addressed by a separate commit. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 07:49:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 07:49:36 -0000 Subject: [GHC] #9164: Hunt down uses of `castPtr` In-Reply-To: <046.786745c4f6f3f83d0a16b89841bd178e@haskell.org> References: <046.786745c4f6f3f83d0a16b89841bd178e@haskell.org> Message-ID: <061.ffe05d034eb2398b90e561118c51a836@haskell.org> #9164: Hunt down uses of `castPtr` -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Ok, forgot about the re-export. So if #9163 can be solved with `castPtr` being free, then this ticket becomes moot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 07:52:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 07:52:26 -0000 Subject: [GHC] #9165: Export TimerManager from GHC.Event In-Reply-To: <049.21fd1c961d7a9c57f5d1deeb4c2c655b@haskell.org> References: <049.21fd1c961d7a9c57f5d1deeb4c2c655b@haskell.org> Message-ID: <064.e08632ae2cd5a6fcfe12252fa2a413ef@haskell.org> #9165: Export TimerManager from GHC.Event -------------------------------+------------------------------------------- Reporter: basvandijk | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed * milestone: => 7.10.1 Comment: I assume we don't need this to get merged into the GHC 7.8 branch, so I'm closing this for now -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 07:54:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 07:54:19 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.b3cc36d1fd4965d095e282993d485249@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9164 -------------------------------------+------------------------------------ Comment (by nomeata): I agree with rwbarton: The `Ptr`?s parameter is, in a sense, a convenience for the user. The API could just use `Ptr` without an argument, and users could use `Tagged a Ptr` if they want to track types. By that reasoning, `Ptr`?s argument should be phantom, as nothing in `Foreign.Ptr` takes `a` into account. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 10:24:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 10:24:03 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.96278c8b396f6990d00fe4347d13cf99@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by archblob): I have played with the test case a little to see if I can reduce it, and to see when exactly the error happens. Here is what I have: {{{#!haskell {-# LANGUAGE PolyKinds, TypeFamilies, UndecidableInstances #-} module Bug where class PEnum (k :: a) where type ToEnum (x :: a) :: * type ToEnum x = TEHelper type TEHelper = ToEnum Int }}} That fails as the test case in the ticket, and this one passes: {{{#!haskell {-# LANGUAGE PolyKinds, TypeFamilies, UndecidableInstances #-} module Bug where class PEnum (k :: a) where type ToEnum (x :: b) :: * type ToEnum x = TEHelper type TEHelper = ToEnum Int }}} Also this is the output from {{{-ddump-tc-trace}}} : {{{ rn12 rn13 Tc2 (src) Tc3 kcTyClGroup module Bug class PEnum (k :: a) where type family ToEnum (x :: a) :: * type instance ToEnum x = TEHelper type TEHelper = ToEnum Int env2 [(a, Type variable ?a? = a)] env2 [] kcTyClGroup: initial kinds [(PEnum, AThing a -> Constraint), (ToEnum, AThing a -> *)] env2 [] kcd1 TEHelper [] tc_lhs_type: ToEnum Int Expected kind ?k_av5? tc_lhs_type: ToEnum Expected kind ?k_av6? lk1 ToEnum lk2 ToEnum AThing a -> * writeMetaTyVar k_av6 := a -> * tc_lhs_type: Int The first argument of ?ToEnum? should have kind ?a? lk1 Int lk2 Int Type constructor ?Int? checkExpectedKind Int * a checkExpectedKind 1 Int * a ([(k0, 1)], [(av4, a)]) ([(k0, 1)], [(av4, a)]) Adding error: Bug.hs:9:24: The first argument of ?ToEnum? should have kind ?a?, but ?Int? has kind ?*? In the type ?ToEnum Int? In the type declaration for ?TEHelper? tryTc/recoverM recovering from IOEnv failure Bug.hs:9:24: The first argument of ?ToEnum? should have kind ?a?, but ?Int? has kind ?*? In the type ?ToEnum Int? In the type declaration for ?TEHelper? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 11:50:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 11:50:08 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.f4c68d272559a1f3b11fa803e59e6cb4@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): That second example is somewhat alarming -- the associated type family does not mention any class parameters. I'm surprised that's accepted! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 12:09:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 12:09:13 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.0b26fdcce46bc917f6119a1b95e30929@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by archblob): It really is. By playing with the kind checking strategy when default instances are defined I've managed to get the initial program to typecheck and get the correct type and kinds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 12:54:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 12:54:25 -0000 Subject: [GHC] #9166: Missing documentation for the -fwarn-inline-rule-shadowing warning Message-ID: <042.6f4a914d89b764cde200d92eb3de3c17@haskell.org> #9166: Missing documentation for the -fwarn-inline-rule-shadowing warning ------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The {{{-fwarn-inline-rule-shadowing}}} warning, which is on by default, it isn't documented in http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/options- sanity.html. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 13:32:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 13:32:20 -0000 Subject: [GHC] #9167: Associated type is accepted even without mentioning class parameters Message-ID: <047.2d5de3ba88af5354277dc53a66fecc69@haskell.org> #9167: Associated type is accepted even without mentioning class parameters ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The following module is accepted: {{{ {-# LANGUAGE TypeFamilies #-} module Bug where class C a where type F b }}} Note that the associate type family `F` does not mention the class variable `a`. Because associated type families are somewhat thin sugar over non-associated type families, I doubt this causes any great disaster anywhere, but it should probably be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 13:33:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 13:33:03 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.c244e605a1c3249f0c7ebcf4cb9992b5@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by archblob): > That second example is somewhat alarming -- the associated type family does not mention > any class parameters. I'm surprised that's accepted! @goldfire, wasn't this introduced in #7939 ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 13:34:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 13:34:04 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.2a979ee7563be08d7b61665c897dd3a1@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Created #9167 about the malformed associated type issue. @archblob: Do you have a patch about the original issue? Thanks for looking into it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 13:43:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 13:43:28 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.100b15b87f220c2fadf341bf6e0a7151@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Replying to [comment:4 archblob]: > > That second example is somewhat alarming -- the associated type family does not mention > any class parameters. I'm surprised that's accepted! > > @goldfire, wasn't this introduced in #7939 ? Perhaps, but if so, it was certainly not intentional. That work should make `b` poly-kinded, but it shouldn't necessarily make `F` accepted. I'm actually surprised that kind-checking strategies have much to do with this bug, but I haven't looked into it. When you change strategies, how does that affect other programs? As outlined in the very long comment explaining them and in #7939, kind-checking strategies are fiddly and subtle, a dangerous combination. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 13:59:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 13:59:34 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.3613ae2a0b44ff9bd1659eab707e02bb@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by archblob): The patch for the original issue still needs validating, I'm working on it now. I was interested in tracking down when the other problem happened first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 14:04:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 14:04:19 -0000 Subject: [GHC] #9167: Associated type is accepted even without mentioning class parameters In-Reply-To: <047.2d5de3ba88af5354277dc53a66fecc69@haskell.org> References: <047.2d5de3ba88af5354277dc53a66fecc69@haskell.org> Message-ID: <062.e410103a89b7020d698679f2dbefdd93@haskell.org> #9167: Associated type is accepted even without mentioning class parameters -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by archblob): This is not 7.8.2 specific, it originated in 7.4.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 17:02:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 17:02:11 -0000 Subject: [GHC] #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies In-Reply-To: <047.6b2af23e852e3dacdefeac6524bf6813@haskell.org> References: <047.6b2af23e852e3dacdefeac6524bf6813@haskell.org> Message-ID: <062.965b090f927ce63e859a97e32ee8c525@haskell.org> #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by MikeIzbicki): I believe I've also encountered this bug. My code base is quite a bit more complicated, so I don't know if it will be helpful to look at, but I've got a description of the problem posted in the README (https://github.com/mikeizbicki/typeparams#a-bug-in-ghc). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 19:31:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 19:31:44 -0000 Subject: [GHC] #17: Separate warnings for unused local and top-level bindings In-Reply-To: <047.fe4cdb312b5d86f34d27df1115f2c91a@haskell.org> References: <047.fe4cdb312b5d86f34d27df1115f2c91a@haskell.org> Message-ID: <062.b22c90a7fdc573d55ce8b85d4e51cb9d@haskell.org> #17: Separate warnings for unused local and top-level bindings -----------------------------------+--------------------------------------- Reporter: magunter | Owner: Type: feature | Status: new request | Milestone: ? Priority: lowest | Version: None Component: Compiler | Keywords: -fwarn-unused-binds Resolution: None | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: None/Unknown | Related Tickets: Test Case: | Blocking: | -----------------------------------+--------------------------------------- Comment (by errge): Note that you can simply prefix those "used from GHCi only top-level bindings" with an underscore as a workaround until this gets implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 19:57:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 19:57:19 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.eeef64bdf42e59dc32cadb438873b083@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Ross that looks attractive. Is it enough for desugaring? That is, is the translation above what you would use for desugaring? It looks a LOT simpler than the present desugaring! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 21:47:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 21:47:46 -0000 Subject: [GHC] #8993: Fold NullaryTypeClasses into MPTC In-Reply-To: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> References: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> Message-ID: <058.3b5757f56cc175f33291e2711a4c815c@haskell.org> #8993: Fold NullaryTypeClasses into MPTC -------------------------------------+------------------------------------ Reporter: owst | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Krzysztof Gogolewski ): In [changeset:"c63a465011b99eeafbb957074e54c2e6bbf751d9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c63a465011b99eeafbb957074e54c2e6bbf751d9" Subsume NullaryTypeClasses by MultiParamTypeClasses (#8993) MPTC now also handles the nullary case }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 21:49:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 21:49:19 -0000 Subject: [GHC] #8993: Fold NullaryTypeClasses into MPTC In-Reply-To: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> References: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> Message-ID: <058.7ace981ae9ec3fadfeb6e5b8d5bdd5cb@haskell.org> #8993: Fold NullaryTypeClasses into MPTC -------------------------------------+------------------------------------ Reporter: owst | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: patch => closed * resolution: => fixed Comment: I've pushed - thanks for the patch! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 22:43:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 22:43:10 -0000 Subject: [GHC] #9168: reading/writing blocking FDs over FD_SETSIZE is broken Message-ID: <047.7e804364d376ec9b9bd7772943568384@haskell.org> #9168: reading/writing blocking FDs over FD_SETSIZE is broken ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In `GHC.IO.FD` when reading from or writing to a blocking FD we first check (using our C function `fdReady`) whether the underlying fd is ready for read/write, in an attempt to avoid blocking the current OS thread. On POSIX this check is done using select, with no test for whether the fd exceeds `FD_SETSIZE`, causing a write out of bounds and various bad consequences. Also, while `readRawBufferPtr` checks the error status of `fdReady`, `readRawBufferPtrNoBlock`, `writeRawBufferPtr`, `writeRawBufferPtrNoBlock` do not, making this issue harder to diagnose. I suggest that `fdReady` use `poll(2)` where available. I can prepare a set of patches if needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 22:47:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 22:47:07 -0000 Subject: [GHC] #9168: reading/writing blocking FDs over FD_SETSIZE is broken In-Reply-To: <047.7e804364d376ec9b9bd7772943568384@haskell.org> References: <047.7e804364d376ec9b9bd7772943568384@haskell.org> Message-ID: <062.c33d7de527dfba9e959451feb0b287df@haskell.org> #9168: reading/writing blocking FDs over FD_SETSIZE is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): A reproducer, based on https://github.com/smurphy8/broken-acid-test. Note: you need a max open files ulimit of more than about 1030 to reproduce the bug with this program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 22:52:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 22:52:33 -0000 Subject: [GHC] #9168: reading/writing blocking FDs over FD_SETSIZE is broken In-Reply-To: <047.7e804364d376ec9b9bd7772943568384@haskell.org> References: <047.7e804364d376ec9b9bd7772943568384@haskell.org> Message-ID: <062.bcaceb6738eec2ee78e15a83a95efb80@haskell.org> #9168: reading/writing blocking FDs over FD_SETSIZE is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): Oh, and if `poll(2)` is not available and so we have to fall back to `select`, and we call `fdReady` on an fd exceeding `FD_SETSIZE`, we should raise an exception, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 23:15:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 23:15:43 -0000 Subject: [GHC] #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar Message-ID: <049.23b37a7a3374245a7e82fd5db3c1a49c@haskell.org> #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.2 Keywords: stm | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I just needed a Weak pointer to a TMVar: {{{ -- | Make a 'Weak' pointer to a 'TMVar', using the second argument as -- a finalizer to run when 'TMVar' is garbage-collected. mkWeakTMVar :: TMVar a -> IO () -> IO (Weak (TMVar a)) mkWeakTMVar tmv@(TMVar (TVar t#)) f = IO $ \s -> case mkWeak# t# tmv f s of (# s1, w #) -> (# s1, Weak w #) }}} It might make sense to add a similar function for TSem as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 4 23:27:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jun 2014 23:27:48 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.b7558ab7b36f86218c1a3c07f5572080@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by ross): Replying to [comment:18 simonpj]: > Ross that looks attractive. Is it enough for desugaring? That is, is the translation above what you would use for desugaring? It looks a LOT simpler than the present desugaring! It's only part of it. This would treat do and if commands as derived constructs, defined in terms of a kernel command language. But that language would still need to be type-checked using the command rules (with their split environments), and would still need to be translated into expressions, as now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 02:37:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 02:37:31 -0000 Subject: [GHC] #9170: haddock: panic! (the 'impossible' happened) Message-ID: <048.9d4de3027be76ef0a09ec5d9f5740bb6@haskell.org> #9170: haddock: panic! (the 'impossible' happened) -----------------------------------+--------------------------------------- Reporter: diego.saa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- After running "cabal install yi", I got this message: dist/build/tmp-79484/src/library/Yi/Eval.hs:139:5: Warning: Defined but not used: `publishedActions_' 73% ( 11 / 15) in 'Yi.Eval' 19% ( 5 / 26) in 'Yi.Modes' 25% ( 1 / 4) in 'Yi.Mode.IReader' 0% ( 0 / 2) in 'Yi.Mode.Compilation' 33% ( 1 / 3) in 'Yi.Mode.JavaScript' 50% ( 2 / 4) in 'Yi.Mode.Latex' 31% ( 4 / 13) in 'Yi.Mode.Interactive' 60% ( 9 / 15) in 'Yi.Command' 58% ( 15 / 26) in 'Yi.Keymap.Emacs.Utils' haddock: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): mkWWcpr: not a product <
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Installing library in /Users/diegos/Library/Haskell/ghc-7.6.3/lib/yi-0.8.1/lib Installing executable(s) in /Users/diegos/Library/Haskell/ghc-7.6.3/lib/yi-0.8.1/bin Registering yi-0.8.1... Installed yi-0.8.1 I'm on OS 10.9.3, GHC 7.6.3. Please let me know if I can provide any other info that could be helpful, or if a full output would help. Thanks, Diego Saa -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 04:32:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 04:32:42 -0000 Subject: [GHC] #9171: Can't match type family with kind polymorphism Message-ID: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> #9171: Can't match type family with kind polymorphism ----------------------------+---------------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Create a module with the following code: {{{ data Base type family GetParam (p::k1) (t::k2) :: k3 type instance GetParam Base t = t }}} It loads into GHCi just fine. But when we run: {{{ ghci> :t undefined :: GetParam Base (GetParam Base Int) }}} we get an error {{{ :1:14: Couldn't match expected type ?GetParam Base (GetParam Base Int)? with actual type ?GetParam Base (GetParam Base Int)? NB: ?GetParam? is a type function, and may not be injective The type variable ?k0? is ambiguous In the ambiguity check for: GetParam Base (GetParam Base Int) To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In an expression type signature: GetParam Base (GetParam Base Int) In the expression: undefined :: GetParam Base (GetParam Base Int) }}} If we modify the module by either 1) set `k3` to `k2`, `k1`, or any concrete kind or 2) set `k2` to any concrete kind then the ghci snippet will type check just fine. I assume that this is a mistake, and that the original code should work just fine. If there is some reason, however, why the program would be unsound, then the error message should be made a bit more informative. The claim is that the kind `k0` is ambiguous, but it doesn't appear anywhere in my code! In my full program, it took me a long time to narrow down that this was the source of the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 04:50:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 04:50:29 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.a8d9a3589e009789ec6b1327a936857e@haskell.org> #229: Integer overflow in array allocation --------------------------------------+------------------------------------ Reporter: josefs | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: ? Component: libraries (other) | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by rwbarton): * owner: => rwbarton * priority: low => normal * version: 6.4.1 => 7.8.1 * component: libraries/base => libraries (other) Comment: This bug still exists. With a little more care you can read and write arbitrary memory. {{{ import Data.Array.MArray import Data.Array.IO import Data.Word main = do m <- newArray_ (0,2^62-1) :: IO (IOUArray Int Word32) -- allocates 0 bytes writeArray m 17 12345 -- write wherever you like }}} The `unsafeNewArray_` definitions in `Data.Array.Base` need to check for integer overflow when computing the size in bytes to be allocated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 05:27:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 05:27:58 -0000 Subject: [GHC] #9172: integer overflow in allocate() Message-ID: <047.b4f6b9adf9374ef0bf3fb465ecef5eea@haskell.org> #9172: integer overflow in allocate() ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ Prelude> Data.Array.array (0,2^61 * 1024 `div` 1025) [] array (0,: internal error: evacuate: strange closure type 2131681697 (GHC version 7.8.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} You can get a variety of other errors too. The array size is chosen so that the total size (in words) passed to `allocate` is just a bit over 2^61^. The computation of `req_blocks` overflows: {{{ W_ req_blocks = (W_)BLOCK_ROUND_UP(n*sizeof(W_)) / BLOCK_SIZE; }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 07:38:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 07:38:06 -0000 Subject: [GHC] #9171: Can't match type family with kind polymorphism In-Reply-To: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> References: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> Message-ID: <065.0ca8e5e6c086c46faa53298c7149ee24@haskell.org> #9171: Can't match type family with kind polymorphism ----------------------------------------------+---------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by kosmikus): Consider this small variation of your example: {{{ data Base type family GetParam (p::k1) (t::k2) :: k3 type instance GetParam Base Int = Int type instance GetParam Base Int = Maybe type instance GetParam Base Maybe = Bool test1 = undefined :: GetParam Base (GetParam Base Int :: *) test2 = undefined :: GetParam Base (GetParam Base Int :: * -> *) }}} Now `test1` has type `Int` and `test2` has type `Bool`, and the only difference is the intermediate kind of `GetParam Base Int` which you haven't specified. So I think GHC is right to complain. The kind of the result of `GetParam Base Int` is ambiguous without annotation, and its choice can in general make a difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 09:39:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 09:39:06 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.ec2645ac35dccf02ff21d479c4fb6b90@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by archblob): Although my patch fixed this specific problem, it failed validation by causing others. My initial idea was to infer a more general {{{forall (a :: BOX). a -> *}}} kind when the associated type is mentioned in the rhs of the synonym, works for this case but causes breakages. Anyway, I'll be looking more into how to do it because I'm having a good time, but I'm not really sure anything will come of it so if someone else wants to work on this, don't mind me, go ahead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 10:04:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 10:04:09 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.d59f653f0a651075d712de3922c05b9d@haskell.org> #9023: Error when using empty record update on binary pattern synonym ---------------------------------+--------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0a55a3cada2fea37586b1a270c1511ed9957dbd4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0a55a3cada2fea37586b1a270c1511ed9957dbd4" Fix egregious instantiation bug in matchOneConLike (fixing Trac #9023) We simply weren't giving anything like the right instantiating types to patSynInstArgTys in matchOneConLike. To get these instantiating types would have involved matching the result type of the pattern synonym with the pattern type, which is tiresome. So instead I changed ConPatOut so that instead of recording the type of the *whole* pattern (in old field pat_ty), it not records the *instantiating* types (in new field pat_arg_tys). Then we canuse TcHsSyn.conLikeResTy to get the pattern type when needed. There are lots of knock-on incidental effects, but they mostly made the code simpler, so I'm happy. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 10:28:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 10:28:17 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.f3c8dc5ecf46f1ad4c1822ef110efe69@haskell.org> #9023: Error when using empty record update on binary pattern synonym ------------------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Test Case: patsyn/should_compile/T9023 | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonpj): * status: patch => merge * testcase: => patsyn/should_compile/T9023 Comment: archblob: you successfully provoked me into looking into this, but your patch was I'm afraid utterly wrong! The `[Type]` argument to `patSynInstArgTys` is positional: the order of the types in that list matters a lot! Moreover we need the instantiating types, not the free variables of the instantiating types. So if it worked for you it was a fluke. But don't be discouraged! There is plenty more to do. Austin: worth merging this to 7.8.3. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 11:26:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 11:26:33 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.f4da5d7c0ebd82cdbe3ba48759bc5362@haskell.org> #9023: Error when using empty record update on binary pattern synonym ------------------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Test Case: patsyn/should_compile/T9023 | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Simon Peyton Jones ): In [changeset:"616f54bdc28ad699f903248a5fb18dc0e5b52a52/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="616f54bdc28ad699f903248a5fb18dc0e5b52a52" Test Trac #9023 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 13:33:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 13:33:23 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.b99fe685ccaf885f161d467304477940@haskell.org> #9023: Error when using empty record update on binary pattern synonym ------------------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Test Case: patsyn/should_compile/T9023 | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonpj): * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 13:42:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 13:42:13 -0000 Subject: [GHC] #9173: Better type error messages Message-ID: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> #9173: Better type error messages ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Generating better type-error messages is a hoary chestnut, but Herbert brought my attention to [https://pay.reddit.com/r/haskell/comments/26tcrk/curious_with_a_bit_of_beginner_ranting_about_some/ this thread on reddit], which has the following idea. At the moment, from {{{ module Foo where addThree = \x -> x + 3 :: Int y = addThree $ Just 5 }}} we get this error: {{{ Foo.hs:2:20 Couldn't match expected type `Int' with actual type `Maybe a0' In the return type of a call of `Just' In the second argument of `($)', namely `Just 5' In the expression: addThree $ Just 5 }}} Maybe we could generate this instead {{{ Foo.hs:2:20 inferred: "Just 5" has type "Maybe a0" expected: second argument of "($)" must have type "Int" in the expression: addThree $ Just 5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 13:43:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 13:43:33 -0000 Subject: [GHC] #9171: Clarify error messages when there is a kind mismatch (was: Can't match type family with kind polymorphism) In-Reply-To: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> References: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> Message-ID: <065.18f87616b31ffb8cd54c2c73483e470f@haskell.org> #9171: Clarify error messages when there is a kind mismatch ----------------------------------------------+---------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): kosmikus is right -- kind variables are properly seen as arguments to a type family, and the OP's code is correctly rejected. However, the error message is quite suboptimal. I wonder if there's a way to detect that kinds are at issue and to suggest `-fprint-explicit-kinds` (which would make the problem more apparent). As a strawman proposal, we could just look at the rendered output; if the "expected" and "actual" are identical, suggest `-fprint-explicit-kinds`. Leaving this ticket open as a request to fine-tune error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 13:46:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 13:46:00 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.0eb2cc2b2103408e59ede5c3ebc9ae38@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): I like this, and think the second set of output reads much, much better. Bonus points: use ANSI terminal colors to highlight some key words in the output, such as "Warning" or "Error" should they exist. Lennart also makes an observation about the way the Mu Haskell compiler handles this: https://pay.reddit.com/r/haskell/comments/26tcrk/curious_with_a_bit_of_beginner_ranting_about_some/chuwwns -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 14:02:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 14:02:28 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.923658f8c0654bab05e8cbf831042ea9@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Looking at the code for a bit, I don't think this is a trivial fix, after all. The problem is that associated type defaults are type-checked in the same group as the enclosing class. This means that GHC thinks that `TEHelper` and `PEnum` are mutually recursive. Thus, polymorphic recursion is not allowed between them, which is what we're asking for here. Instead, GHC should type check associated type defaults with other instances (in `tcInstDecls1`, likely), ''after'' all !TyClGroups are done being checked. With that line-up, `TEHelper` depends on `ToEnum` (part of the group with `PEnum`), but not the other way around. Unfortunately, this requires some moving plumbing around, and is not something I have time for at the moment. This all is not unlike how default method declarations have to be checked quite separately from the rest of a class. Anyway, archblob, if you want to keep playing, perhaps my comments above are helpful. I don't think this is ''hard'', but I originally thought the problem was due to a small oversight in the dependency analysis in the renamer. That's not the case, but it shouldn't be more than an hour or two of work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 14:11:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 14:11:55 -0000 Subject: [GHC] #9080: GHC error on Win 8.1 64bit In-Reply-To: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> References: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> Message-ID: <058.777093ce96b92f0c31d3a0d865102664@haskell.org> #9080: GHC error on Win 8.1 64bit ---------------------------------------+---------------------------------- Reporter: maun | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"56ea745c3dd00c87ad86b80f91a31ced5e86e488/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="56ea745c3dd00c87ad86b80f91a31ced5e86e488" Add ".text.unlikely" to recognized code sections on Windows. Fixes #9080 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 14:11:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 14:11:55 -0000 Subject: [GHC] #7241: GHC-7.6.1 panics on template haskell code In-Reply-To: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> References: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> Message-ID: <061.1dcdf48895be8b119e7e096755533009@haskell.org> #7241: GHC-7.6.1 panics on template haskell code ---------------------------------------+----------------------------------- Reporter: akamaus | Owner: Yuras Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Austin Seipp ): In [changeset:"c226d25fef519db663d0c9efe7845637423f1dca/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c226d25fef519db663d0c9efe7845637423f1dca" Emit error in case of duplicate GRE; fixes #7241 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 14:12:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 14:12:14 -0000 Subject: [GHC] #9080: GHC error on Win 8.1 64bit In-Reply-To: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> References: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> Message-ID: <058.8ea5d0a88843fffef7e1281cd59a87b1@haskell.org> #9080: GHC error on Win 8.1 64bit ---------------------------------------+---------------------------------- Reporter: maun | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 14:12:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 14:12:25 -0000 Subject: [GHC] #7241: GHC-7.6.1 panics on template haskell code In-Reply-To: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> References: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> Message-ID: <061.6d5b4660b0bbd86e21a0afb9e89c42de@haskell.org> #7241: GHC-7.6.1 panics on template haskell code ---------------------------------------+----------------------------------- Reporter: akamaus | Owner: Yuras Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 15:38:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 15:38:49 -0000 Subject: [GHC] #9174: Haddock fails with "Module defined in multiple files" Message-ID: <045.7b388517426ffff02e3552a19cb548c4@haskell.org> #9174: Haddock fails with "Module defined in multiple files" ----------------------------------+--------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- Haddock fails to cooperate with OS X clang CPP: {{{ : module ?pkgid-pkgversion:Main? is defined in multiple files: dist/build/tmp-#####/Stuff }}} A workaround is to pass `--ghc-options=-optP-P` to `cabal haddock`. This prevents `cabal-install` from being boostrapped, unless `--no-doc` is specified. The original Haddock ticket and the corresponding Cabal issue were both closed as invalid, but there appears to be no GHC ticket to track the underlying cause. http://trac.haskell.org/haddock/ticket/284 https://github.com/haskell/cabal/issues/1740 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 15:41:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 15:41:05 -0000 Subject: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS In-Reply-To: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> References: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> Message-ID: <060.2d1e9fe14cfbb97dbd5f7dce544ed2e0@haskell.org> #4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Runtime System | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by slyfox): 0003-rts-posix-Select.c-throw-exception-to-reader-as-soon.patch adds another step to kill thread on '''threadWaitRead'''. Now it works as: {{{ [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... a: awaitEvent: invalid argument (Bad file descriptor) a: user error (If you can read this, shutdownHaskellAndExit did not exit.) }}} The problem is the status of killed thread. RTS thinks it did not finish, but blocked on FFI call: {{{ $ ./a +RTS -D{s,i,r,S,z} cap 0: thread 1 stopped (blocked on a read operation) thread 1 @ 0x7fd2fa405390 is blocked on read from fd 12 (TSO_DIRTY) scheduler: checking for threads blocked on I/O (waiting) found bad READ fd=12 cap 0: raising exception in thread 1. Waking up blocked thread 1 cap 0: running thread 1 (ThreadRunGHC) a: awaitEvent: invalid argument (Bad file descriptor) cap 0: thread 1 stopped (suspended while making a foreign call) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 15:49:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 15:49:21 -0000 Subject: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS In-Reply-To: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> References: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> Message-ID: <060.2c414d28077e65f55c6909f4022ad53f@haskell.org> #4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Runtime System | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by slyfox): Some notes about the code which does '''threadWaitRead''' from haskell, but does not perform '''read()'''. For xmobar the bug was in polling on X11 socket from haskell code, and handling of sockets from C code (which ignored bad FD). Thus such code led to 100% CPU busy loop: {{{ x11_ctx <- get_x11_ctx forever $ do threadWaitRead (x11_connection x11_ctx) x11_poll_events event_callback -- ignores -EBADF }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 16:13:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 16:13:44 -0000 Subject: [GHC] #9171: Clarify error messages when there is a kind mismatch In-Reply-To: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> References: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> Message-ID: <065.2bf0c3344b9f657602caa01d5b8ab2b6@haskell.org> #9171: Clarify error messages when there is a kind mismatch ----------------------------------------------+---------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by MikeIzbicki): Replying to [comment:1 kosmikus]: I was under the impression that type families had to be functions, and so: {{{ type family GetParam (p::k1) (t::k2) :: k3 type instance GetParam Base Int = Int type instance GetParam Base Int = Maybe }}} would be rejected for having conflicting definitions. If we change the code to: {{{ type family GetParam (p::k1) (t::k2) :: * type instance GetParam Base Int = Int type instance GetParam Base Int = Double }}} then the program does get rejected as having conflicting definitions. Is there a good reason to allow the former but not the latter? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 16:28:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 16:28:53 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.a46179f3e543501c92a32301060bcedd@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by juhpetersen): Here is the small patch to ghc.mk I have been using for Fedora builds so far: https://github.com/fedora-haskell/ghc/blob/master/ghc-package-xhtml- terminfo-haskeline.patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 16:42:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 16:42:43 -0000 Subject: [GHC] #9171: Clarify error messages when there is a kind mismatch In-Reply-To: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> References: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> Message-ID: <065.0763bda4cb5da73f55675af6535b467b@haskell.org> #9171: Clarify error messages when there is a kind mismatch ----------------------------------------------+---------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by rwbarton): Replying to [comment:3 MikeIzbicki]: The kind of your first `GetParam` would be `forall k3 k1 k2. k1 -> k2 -> k3` meaning that for each triple of kinds (k1,k2,k3), `GetParam` is a type function `k1 -> k2 -> k3`. It doesn't mean that for each pair of kinds (k1,k2) there is a kind k3 which is determined by the type family and a type function `k1 -> k2 -> k3`. It's like the type level `forall c a b. C a b c => a -> b -> c` (though it's not a perfect analogy; since type families can perform type-level "kind-case" but functions can't perform type-case, I added a type class constraint). Or, if you convert the polykindedness to extra arguments to the type family (as ghci will show you is happening behind the scenes if you `:info GetParam`), then your instances become {{{ type instance GetParam * * * Base Int = Int type instance GetParam (* -> *) * * Base Int = Maybe }}} and now you can see that they don't conflict. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 16:50:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 16:50:17 -0000 Subject: [GHC] #9171: Clarify error messages when there is a kind mismatch In-Reply-To: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> References: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> Message-ID: <065.707a2c620e5a264a57d6f062ac482d1c@haskell.org> #9171: Clarify error messages when there is a kind mismatch ----------------------------------------------+---------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by MikeIzbicki): That makes sense. Was that decision made due to implementation convenience? Or are there examples of type families where we really would want that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 17:24:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 17:24:31 -0000 Subject: [GHC] #9171: Clarify error messages when there is a kind mismatch In-Reply-To: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> References: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> Message-ID: <065.0a0854139d9ff6b75d39d58e44d73b42@haskell.org> #9171: Clarify error messages when there is a kind mismatch ----------------------------------------------+---------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): I've written several type families where we really do want this behavior. I can't speak to ''why'' it was designed to work this way, but I have benefitted from this decision. One example is to be able to encode overloaded numbers in types: {{{ type family FromNat (n :: Nat) :: k type instance FromNat n = n -- identity type instance FromNat n = ToU n -- for UnaryNat type instance FromNat n = ToZ n -- for Z (integers) data UnaryNat = Zero | Succ UnaryNat type family ToU n where ToU 0 = Zero ToU n = Succ (ToU (n - 1)) data Z = ... type family ToZ n where ... }}} I admit that I'm probably in the minority at using this feature, but it ''is'' being used. On the other hand, it is a little alarming to most users at first, and it's definitely not the most intuitive feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 17:52:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 17:52:12 -0000 Subject: [GHC] #9174: Haddock fails with "Module defined in multiple files" In-Reply-To: <045.7b388517426ffff02e3552a19cb548c4@haskell.org> References: <045.7b388517426ffff02e3552a19cb548c4@haskell.org> Message-ID: <060.119d46b129e90c008b80f375d6b52c40@haskell.org> #9174: Haddock fails with "Module defined in multiple files" ---------------------------------+---------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Description changed by mietek: Old description: > Haddock fails to cooperate with OS X clang CPP: > {{{ > : > module ?pkgid-pkgversion:Main? is defined in multiple files: > dist/build/tmp-#####/Stuff > }}} > > A workaround is to pass `--ghc-options=-optP-P` to `cabal haddock`. > > This prevents `cabal-install` from being boostrapped, unless `--no-doc` > is specified. > > The original Haddock ticket and the corresponding Cabal issue were both > closed as invalid, but there appears to be no GHC ticket to track the > underlying cause. > http://trac.haskell.org/haddock/ticket/284 > https://github.com/haskell/cabal/issues/1740 New description: Haddock fails to cooperate with OS X clang CPP: {{{ : module ?pkgid-pkgversion:Main? is defined in multiple files: dist/build/tmp-#####/Stuff }}} A workaround is to pass `--ghc-options=-optP-P` to `cabal haddock`. This prevents `cabal-install` from bootstrapping, unless `--no-doc` is specified. The original Haddock ticket and the corresponding Cabal issue were both closed as invalid, but there appears to be no GHC ticket to track the underlying cause. http://trac.haskell.org/haddock/ticket/284 https://github.com/haskell/cabal/issues/1740 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 18:17:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 18:17:07 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.1de8739679305df80deb7cb2526c6321@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by crockeea): Replying to [comment:3 goldfire]: > For the problem reported in the first comment -- about a `Typeable` instance for `Symbol`s (and presumably `Nat`s) -- the implementation technique is somewhat different and might best be something for Iavor. [http://www.haskell.org/pipermail/haskell-cafe/2013-August/109993.html This message] from August 2013 suggests that he is on it, but I don't know if there has been progress since then. I just asked Iavor about that message. His response (6/4/14): "I don't think anything has happened with this, but we discussed it some time ago and as far as I recall there were no theoretical or technical difficulties ---it just has to get done. I'll put it on my (now getting longish :-) todo list." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 19:40:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 19:40:29 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.d445522f9dad950c6147adca2f651f16@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * cc: hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 20:25:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 20:25:26 -0000 Subject: [GHC] #9050: Panic when compiling cmm file together with -outputdir In-Reply-To: <044.0c851e057b25561ca3c3a92b801901b3@haskell.org> References: <044.0c851e057b25561ca3c3a92b801901b3@haskell.org> Message-ID: <059.f6a7b8d09751bbd40f3b0faab0422b47@haskell.org> #9050: Panic when compiling cmm file together with -outputdir ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"2a463ebeba4dff6793ae16707712f1e9245225e8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2a463ebeba4dff6793ae16707712f1e9245225e8" Fix compilation of cmm files with -outputdir (Trac #9050) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 20:41:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 20:41:52 -0000 Subject: [GHC] #9050: Panic when compiling cmm file together with -outputdir In-Reply-To: <044.0c851e057b25561ca3c3a92b801901b3@haskell.org> References: <044.0c851e057b25561ca3c3a92b801901b3@haskell.org> Message-ID: <059.b3d2329540a0cb7b3f809ea8485a0e14@haskell.org> #9050: Panic when compiling cmm file together with -outputdir ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by monoidal): * status: patch => merge * milestone: => 7.8.3 Comment: I've pushed; the change should be mergeable to 7.8, as Yuras said in comment:1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 22:11:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 22:11:00 -0000 Subject: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS In-Reply-To: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> References: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> Message-ID: <060.a303678422ce8a06eca729072b4b4d0b@haskell.org> #4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Runtime System | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by slyfox): After throwToSingleThreaded '''tso''' should not be pushed to runnables queue. 0004-rts-posix-Select.c-don-t-put-thread-with-pending-exc.patch fixes this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 22:15:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 22:15:19 -0000 Subject: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS In-Reply-To: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> References: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> Message-ID: <060.cd4ac38a7e1d6bfc3197c3acaa0f823f@haskell.org> #4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: ? Component: Runtime System | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by slyfox): * status: new => patch Comment: Now even with non-threaded RTS error is reported as expected: {{{ $ inplace/bin/ghc-stage2 --make -fforce-recomp a.hs -o a -debug && ./a a: awaitEvent: invalid argument (Bad file descriptor) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 23:56:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 23:56:47 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.d0d42b1b7bedb6996908e0de4e741c73@haskell.org> #9160: Panic: Template variable unbound in rewrite rule ---------------------------------------+---------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4524 ---------------------------------------+---------------------------------- Changes (by mietek): * os: MacOS X => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 5 23:59:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jun 2014 23:59:37 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.743ea3e6de47dc16337bccb1ab86541d@haskell.org> #9160: Panic: Template variable unbound in rewrite rule ---------------------------------------+---------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4524 ---------------------------------------+---------------------------------- Description changed by mietek: Old description: > Installing `singletons-1.0` with GHC 7.8.2 on OS X 10.9.2 fails: > > {{{ > ghc: panic! (the 'impossible' happened) > (GHC version 7.8.2 for x86_64-apple-darwin): > Template variable unbound in rewrite rule > }}} > > See also [https://github.com/goldfirere/singletons/issues/83 > goldfirere/singletons#83] New description: Installing `singletons-1.0` with GHC 7.8.2 on both OS X 10.9.2 and Ubuntu 2014.04 fails: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-apple-darwin): Template variable unbound in rewrite rule }}} This seems to be an issue with the optimizer, as the bug only appears with optimization level 2, using the following line in `~/.cabal/config`: {{{ optimization: 2 }}} See also [https://github.com/goldfirere/singletons/issues/83 goldfirere/singletons#83] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 00:44:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 00:44:10 -0000 Subject: [GHC] #9175: Bad interaction between Pattern Synonyms and Text Message-ID: <047.311a35a65ef21c36ac9cb789bb411456@haskell.org> #9175: Bad interaction between Pattern Synonyms and Text -----------------------------------+--------------------------------------- Reporter: emertens | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Compiling this file causes the impossible to happen. It is necessary to enable optimizations. The bug did not occur if the Text parameter was replaced with ByteString or String. {{{ {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE OverloadedStrings #-} module Bug where {- - Must compile with optimizations - - text-1.1.1.3 - ghc-7.8.2 - Both Darwin and Linux platforms - -} import Data.Text(Text) data T = C Text Bool f :: a -> b f _ = undefined {-# NOINLINE f #-} -- important pattern P1 a = C "sh" a -- at least two characters pattern P2 = C "x" True -- this pattern has to come last g :: Text -> T g x = case x of "" -> f (P1 undefined) -- this has to be a pattern synonym }}} {{{ [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-apple-darwin): StgCmmEnv: variable not found lvl_s2Jr{v} [lid] local binds for: main:Bug.f{v rBS} [gid] main:Bug.rewriteRule{v rBV} [gid] main:Bug.$mP2{v r17q} [gid] main:Bug.$WP2{v r17A} [gid] main:Bug.$mP1{v r17E} [gid] main:Bug.$WP1{v r17R} [gid] main:Bug.$WP3{v r3bq} [gid] main:Bug.$WP4{v r3ua} [gid] main:Bug.$WP5{v r3ub} [gid] main:Bug.$WP2_dt{v r3uc} [gid] main:Bug.$WP6{v r3ud} [gid] main:Bug.$WP7{v r3ue} [gid] main:Bug.$WP8{v r3uf} [gid] main:Bug.$w$mP1{v r3ug} [gid] main:Bug.$w$mP2{v r3uh} [gid] main:Bug.$mP3{v r3ui} [gid] main:Bug.$mP4{v r3uj} [gid] main:Bug.$mP5{v r3uk} [gid] main:Bug.$wrewriteRule{v r3ul} [gid] main:Bug.rewriteRule1{v r3um} [gid] main:Bug.rewriteRule2{v r3un} [gid] main:Bug.rewriteRule3{v r3uo} [gid] main:Bug.rewriteRule4{v r3up} [gid] main:Bug.rewriteRule5{v r3uq} [gid] lvl{v r3ur} [gid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 02:43:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 02:43:28 -0000 Subject: [GHC] #9174: Haddock fails with "Module defined in multiple files" In-Reply-To: <045.7b388517426ffff02e3552a19cb548c4@haskell.org> References: <045.7b388517426ffff02e3552a19cb548c4@haskell.org> Message-ID: <060.c31475b928a19ac779833a0c9ba926bb@haskell.org> #9174: Haddock fails with "Module defined in multiple files" ---------------------------------+---------------------------------- Reporter: mietek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Changes (by carter): * status: new => closed * resolution: => duplicate Comment: i'm closing it as a duplicated, because a lot of the related issues are due to be resolved in https://ghc.haskell.org/trac/ghc/ticket/8683 its a known issue of using clang for cpp naively, things will break. dont use clang for cpp. This becomes easier in 7.8.3 which will be release soon (and i'm told with that patches in #8683 merged in) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 03:58:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 03:58:53 -0000 Subject: [GHC] #9176: GHC not generating dyn_hi files Message-ID: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> #9176: GHC not generating dyn_hi files ----------------------------------+---------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: dynamic | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------- In some situations, GHC terminates successfully and generates a `dyn_o` file, but no `dyn_hi` file. As a result, a package that contains a library seems to build successfully, but fails to install. I narrowed the problem down to the following test case. I compile it with `ghc --make -shared -dynamic-too Foo`. It seems to be Parsec-related, but I don't know how to trace it further. {{{ module Foo where import Text.ParserCombinators.Parsec }}} Parsec was installed with `cabal install --reinstall --user --enable- shared --disable-library-profiling parsec-3.1.5`. Some Parsec modules do not cause the missing `dyn_hi` file. For instance, all output files are created if Foo imports `Text.Parsec.Pos` instead of `Text.ParserCombinators.Parsec`. GHC was built from source, commit 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with XCode 5.1.1 on OS X 10.9.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 04:06:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 04:06:29 -0000 Subject: [GHC] #9176: GHC not generating dyn_hi files In-Reply-To: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> References: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> Message-ID: <062.89924b8960c0fac1d5c69648c26981f1@haskell.org> #9176: GHC not generating dyn_hi files -----------------------------+---------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: dynamic Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Description changed by heatsink: Old description: > In some situations, GHC terminates successfully and generates a `dyn_o` > file, but no `dyn_hi` file. As a result, a package that contains a > library seems to build successfully, but fails to install. I narrowed > the problem down to the following test case. I compile it with `ghc > --make -shared -dynamic-too Foo`. It seems to be Parsec-related, but I > don't know how to trace it further. > > {{{ > module Foo where > import Text.ParserCombinators.Parsec > }}} > > Parsec was installed with `cabal install --reinstall --user --enable- > shared --disable-library-profiling parsec-3.1.5`. Some Parsec modules do > not cause the missing `dyn_hi` file. For instance, all output files are > created if Foo imports `Text.Parsec.Pos` instead of > `Text.ParserCombinators.Parsec`. > > GHC was built from source, commit > 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with > XCode 5.1.1 on OS X 10.9.3. New description: In some situations, GHC terminates successfully and generates a `dyn_o` file, but no `dyn_hi` file. As a result, a package that contains a library seems to build successfully, but fails to install. I narrowed the problem down to the following test case. I compile it with `ghc --make -shared -dynamic-too Foo`. It seems to be Parsec-related, but I don't know how to trace it further. {{{ module Foo where import Text.ParserCombinators.Parsec }}} Parsec was installed with `cabal install --reinstall --user --enable- shared --disable-library-profiling parsec-3.1.5`. Some Parsec modules do not cause the missing `dyn_hi` file. For instance, all output files are created if Foo imports `Text.Parsec.Pos` instead of `Text.ParserCombinators.Parsec`. My installed Parsec library does not seem to be broken. I can link and run `main = parseTest (char 'a') "a"` in both `-dynamic` and `-static` modes, and I can also use Parsec from GHCi. GHC was built from source, commit 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with XCode 5.1.1 on OS X 10.9.3. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 04:07:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 04:07:08 -0000 Subject: [GHC] #9176: GHC not generating dyn_hi files In-Reply-To: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> References: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> Message-ID: <062.bdee328b058e752a2ca2fc18e83574ad@haskell.org> #9176: GHC not generating dyn_hi files -----------------------------+---------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: dynamic Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Description changed by heatsink: Old description: > In some situations, GHC terminates successfully and generates a `dyn_o` > file, but no `dyn_hi` file. As a result, a package that contains a > library seems to build successfully, but fails to install. I narrowed > the problem down to the following test case. I compile it with `ghc > --make -shared -dynamic-too Foo`. It seems to be Parsec-related, but I > don't know how to trace it further. > > {{{ > module Foo where > import Text.ParserCombinators.Parsec > }}} > > Parsec was installed with `cabal install --reinstall --user --enable- > shared --disable-library-profiling parsec-3.1.5`. Some Parsec modules do > not cause the missing `dyn_hi` file. For instance, all output files are > created if Foo imports `Text.Parsec.Pos` instead of > `Text.ParserCombinators.Parsec`. > > My installed Parsec library does not seem to be broken. I can link and > run `main = parseTest (char 'a') "a"` in both `-dynamic` and `-static` > modes, and I can also use Parsec from GHCi. > > GHC was built from source, commit > 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with > XCode 5.1.1 on OS X 10.9.3. New description: In some situations, GHC terminates successfully and generates a `dyn_o` file, but no `dyn_hi` file. As a result, a package that contains a library seems to build successfully, but fails to install. I narrowed the problem down to the following test case. I compile it with `ghc --make -shared -dynamic-too Foo`. It seems to be Parsec-related, but I don't know how to trace it further. {{{ module Foo where import Text.ParserCombinators.Parsec }}} Parsec was installed with `cabal install --reinstall --user --enable- shared --disable-library-profiling parsec-3.1.5`. Some Parsec modules do not cause the missing `dyn_hi` file. For instance, all output files are created if Foo imports `Text.Parsec.Pos` instead of `Text.ParserCombinators.Parsec`. My installed Parsec library seems to be working correctly. I can link and run `main = parseTest (char 'a') "a"` in both `-dynamic` and `-static` modes, and I can also use Parsec from GHCi. GHC was built from source, commit 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with XCode 5.1.1 on OS X 10.9.3. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 07:25:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 07:25:21 -0000 Subject: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS In-Reply-To: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> References: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> Message-ID: <060.395ea423ce16e872c34e80384c0e71a4@haskell.org> #4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: ? Component: Runtime System | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by slyfox): If idea in patches looks fine i can squash last 3 patches in one and cleanup comments around. I can also slightly change polling cycle to resume only descriptors with data available, and not all the waiters. It would be more robust against spurious blocking calls. What do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 07:31:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 07:31:58 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.f5fc9f83e16e07bad5b6611e515b21d7@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by archblob): I think you original assumption still stands, as the current failure happens when we try to type-check the type synonym, we don't even get to the associated defaults, thus only postponing the type checking of atdefs will do no good I think. The failure will still happen at this stage. I think the synonym would have to be type checked in a different group, after the class declaration and before the atdefs, which will have to be checked with other instances as you suggested. Maybe someone else can chime in with some ideas about the strategy. Please tell me if my assumptions are wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 07:39:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 07:39:42 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.47fd163aef734d45962fd5ed50b45aea@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by schyler): Here's an error that a noob making a subtle typo might get from GHC: {{{ Prelude> map 1 [1..5] :2:1: Could not deduce (Num (a0 -> b)) arising from the ambiguity check for ?it? from the context (Num (a -> b), Num a, Enum a) bound by the inferred type for ?it?: (Num (a -> b), Num a, Enum a) => [b] at :2:1-12 The type variable ?a0? is ambiguous When checking that ?it? has the inferred type ?forall a b. (Num (a -> b), Num a, Enum a) => [b]? Probable cause: the inferred type is ambiguous }}} I wholeheartedly agree that the information needs to be presented in a way that's easier to digest. For what should be a really simple error, I really have to stare that down to understand what it's actually trying to say ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 07:58:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 07:58:53 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.92b59df77a700e0d7ea6887979ada622@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Despite the very general ticket title, let?s not confalte multiple errors. The original ticket was a about a type mismatch (inferred vs. expected). The example by schlyer is about an ambiguous type in the GHCi prompt. Note that with some more instances added, `map 1 [1..5]` would type check! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 08:25:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 08:25:48 -0000 Subject: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS In-Reply-To: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> References: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> Message-ID: <060.d0ca4e70c943377259d957c90fbb6d29@haskell.org> #4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: ? Component: Runtime System | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by simonmar): Yes, please squash the patches and then I'll review. Not sure what you mean by "slightly change polling cycle to resume only descriptors with data available", don't we already do that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 08:26:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 08:26:48 -0000 Subject: [GHC] #9177: Suggest Int when user uses int Message-ID: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> #9177: Suggest Int when user uses int ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1388 | ------------------------------------+------------------------------------- This ticket is a fork of #1388. We already give suggestions when the user mispells names, based on edit distance. But this does not cross the boundaries between different kind of names. It would be helpful if {{{Not in scope: type variable `int'}}} would also say {{{Did you mean the type constructor `Int'}}}? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 08:27:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 08:27:02 -0000 Subject: [GHC] #1388: Newbie help features In-Reply-To: <044.efaff92cf2e79b2f529fa901fdcbafbb@haskell.org> References: <044.efaff92cf2e79b2f529fa901fdcbafbb@haskell.org> Message-ID: <059.ad9eab7b7bf54d69f0462e7bd470275b@haskell.org> #1388: Newbie help features -------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature | Status: new request | Milestone: ? Priority: low | Version: 6.6.1 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by nomeata): Split the last suggestion in the original ticket to #9177 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 08:52:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 08:52:16 -0000 Subject: [GHC] #9177: Suggest Int when user uses int In-Reply-To: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> References: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> Message-ID: <061.5c884598346c3bd1532e8ebc8ba6d428@haskell.org> #9177: Suggest Int when user uses int -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #1388 -------------------------------------+------------------------------------ Comment (by simonpj): Good idea. Want to implement it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 08:57:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 08:57:17 -0000 Subject: [GHC] #9177: Suggest Int when user uses int In-Reply-To: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> References: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> Message-ID: <061.cf6acf4221fd17167a129e78156fcddf@haskell.org> #9177: Suggest Int when user uses int -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #1388 -------------------------------------+------------------------------------ Changes (by nomeata): * owner: => nomeata Comment: Almost done, this is my ZuriHac warm up ticket :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 09:20:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 09:20:09 -0000 Subject: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS In-Reply-To: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> References: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> Message-ID: <060.c6887c2d5b7fb42d44a918f2cd344f12@haskell.org> #4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: ? Component: Runtime System | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by slyfox): > Yes, please squash the patches and then I'll review. Will do. > Not sure what you mean by "slightly change polling cycle to resume only descriptors with data available", don't we already do that? I was a bit unclear. I meant: only in a case of '''select() == EBADF''' failure we always resumed all the blocked threads: https://ghc.haskell.org/trac/ghc/browser/ghc/rts/posix/Select.c#L295 {{{ if ( errno == EBADF ) unblock_all = rtsTrue; ... ready = unblock_all || FD_ISSET(tso->block_info.fd, &rfd); // [1] ... if (ready) pushOnRunQueue(&MainCapability,tso); }}} Current patchset only propagates exceptions early, but does not fix spurious resumes (as it was before). I propose to fix resume problem: {{{ --- ready = unblock_all || FD_ISSET(tso->block_info.fd, &rfd); +++ if (unblock_all) ready = fd_is_really_ready (fd); +++ else ready = FD_ISSET(tso->block_info.fd, &rfd); }}} It' won't be hard to implement on top of current patchset. Secondary '''select()''' can already provide all the info. Should I do it as a) a separate patch/ticket, b) merge into final result, c) don't touch it at all? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 09:40:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 09:40:34 -0000 Subject: [GHC] #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) In-Reply-To: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> References: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> Message-ID: <060.cbf62b6f76fd8ed6025c1ffd5c779f79@haskell.org> #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) ---------------------------------------+---------------------------------- Reporter: slyfox | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler (NCG) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by simonmar): Just to let you know I'm still working on this, hope to have it done today or tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 09:59:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 09:59:31 -0000 Subject: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS In-Reply-To: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> References: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> Message-ID: <060.1636832012f0cd6684324910a290c1b1@haskell.org> #4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: ? Component: Runtime System | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by simonmar): (b) merge into your patch please. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 10:03:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 10:03:17 -0000 Subject: [GHC] #9177: Suggest Int when user uses int In-Reply-To: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> References: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> Message-ID: <061.9b52f83c97019ed6a49818acbc03f481@haskell.org> #9177: Suggest Int when user uses int -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #1388 -------------------------------------+------------------------------------ Comment (by nomeata): I have two variants: One that suggests `Integer` when `integer` is typed, and one that suggests even `Integer` if `integerr` is typed (using the same edit distance metric stuff). I?ll push the first, followed by the second, so that one can easily revert. Of course there is no limit on how smart the error message can be. In `type Foo = eq`, one cannot mean `Eq` (as it is a class), but that is not available on the level of `OccNames`. But I guess the suggestion is still an improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 10:33:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 10:33:30 -0000 Subject: [GHC] #9177: Suggest Int when user uses int In-Reply-To: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> References: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> Message-ID: <061.e1cca9a7b91ea05c31165efa79dfa0d0@haskell.org> #9177: Suggest Int when user uses int -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #1388 -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => patch Comment: Another example of this logic leading the user into a direction that will cause a different error: {{{ Prelude> let foo = () Prelude> let g = Foo -- good suggestion :5:9: Not in scope: data constructor ?Foo? Perhaps you meant variable ?foo? (line 2) Prelude> let f (Foo x) = x -- bad suggestion :3:8: Not in scope: data constructor ?Foo? Perhaps you meant variable ?foo? (line 2) }}} Anyways, I pushed it to `wip/T9177` for review (but will likely push to master in the next days; people can still complain afterwards). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 10:37:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 10:37:40 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.9ecf04f23d294b1b0ac6ad1a833d7932@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by hvr): What about compiler errors/warnings? Should those use `UnicodeSyntax` as well if enabled? What about `ghc`'s compile messages in general? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 10:38:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 10:38:52 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.2ddc4f34b0ab987aab0106575e30a343@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ocharles): Ok, my branch has been updated with the Data instances. I think we're all done here! Here's the final diff that needs reviewing: https://github.com/ocharles/ghc/compare/master...generics-instances If people are happy with this, I will probably rewrite the branch to be a single commit, unless people feel the history here is relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 10:41:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 10:41:57 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.032a621cc1127f0fc16bd026ba24a33f@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by skeuchel): I would like to further work on this, i.e. add multiplication. Is there still interest in having this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 10:43:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 10:43:39 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.e5b348fc46e8b6a0a8eac1698a5fe9bd@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I'm not following the details here, but if the core-libraries commmitte are happy please turn it into one comment and change to 'patch' status so that Austin can merge it. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 10:44:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 10:44:08 -0000 Subject: [GHC] #9177: Suggest Int when user uses int In-Reply-To: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> References: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> Message-ID: <061.14f10bad24d1de58a33df9124c62520e@haskell.org> #9177: Suggest Int when user uses int -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #1388 -------------------------------------+------------------------------------ Comment (by simonpj): Sounds good to me. Do get someone at Zurihac to look it over and then push to master. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 10:56:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 10:56:02 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.c1d8a133dd9abb648020ee88c2580668@haskell.org> #9156: Duplicate record field ------------------------------------------------+-------------------------- Reporter: wojteknar | Owner: gintas Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by nomeata): * owner: => gintas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 11:17:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 11:17:53 -0000 Subject: [GHC] #9177: Suggest Int when user uses int In-Reply-To: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> References: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> Message-ID: <061.08b079db49da5c8b482f6d281582d489@haskell.org> #9177: Suggest Int when user uses int -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #1388 -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"009e86f5dd2bc2657be093c76ba679b7866b651a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="009e86f5dd2bc2657be093c76ba679b7866b651a" Suggest Int when user writes int and the other way around. This fixes #9177. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 11:17:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 11:17:54 -0000 Subject: [GHC] #9177: Suggest Int when user uses int In-Reply-To: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> References: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> Message-ID: <061.39ea25a0850f3d073d3dfc36a04a55bb@haskell.org> #9177: Suggest Int when user uses int -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #1388 -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"ae41a50f0378c00351df5414b35026fc4bce2b44/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ae41a50f0378c00351df5414b35026fc4bce2b44" Report all possible results from related name spaces instead of just one matching directly. This is an alternative way to fix ticket #9177. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 11:17:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 11:17:54 -0000 Subject: [GHC] #9177: Suggest Int when user uses int In-Reply-To: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> References: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> Message-ID: <061.34c55a1c66a500f444693ccd4f0f56d1@haskell.org> #9177: Suggest Int when user uses int -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #1388 -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"d3cae19055d6f148b6085fb5d6885a1826215aad/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d3cae19055d6f148b6085fb5d6885a1826215aad" Add testcase for #9177 and adjust test output }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 11:27:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 11:27:34 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.0a0ebd428b4f4e30a0fa5d062d356938@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: skeuchel Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by skeuchel): * owner: => skeuchel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 11:42:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 11:42:22 -0000 Subject: [GHC] #8927: Multiple case match at once In-Reply-To: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> References: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> Message-ID: <061.5785a6024e4689e0e0145c8f0117f5c8@haskell.org> #8927: Multiple case match at once --------------------------------------+------------------------------------ Reporter: vxanica | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.1-rc2 Resolution: | Keywords: case, multiple Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by nomeata): * difficulty: Easy (less than 1 hour) => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 11:48:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 11:48:13 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.3f755330776993db4c3aee31300370d2@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:10 ocharles]: > If people are happy with this, I will probably rewrite the branch to be a single commit, unless people feel the history here is relevant. ...please put whitespace changes in a separate commit though :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 11:48:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 11:48:21 -0000 Subject: [GHC] #9178: improve orphan instance warning Message-ID: <043.fcde19f8eb765ccd6976e8ca3285d142@haskell.org> #9178: improve orphan instance warning ------------------------------------+------------------------------------- Reporter: fphh | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The current warning `Warning: orphan instance: instance ClassName TypeName` could be improved by suggesting three solutions: (i) Move the instance declaration to the file, where the class has been declared (ii) Move the instance declaration to the file, where the Type has been declared (iii) Wrap the type with a newtype and declare the instance on the new type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 12:01:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 12:01:37 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.2c82d198edfafea088efce9c345935d2@haskell.org> #9136: Constant folding in Core could be better --------------------------------------------+------------------------------ Reporter: simonpj | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): I had a look and the patch seemed broadly OK, through rather under- commented. Notably the parameters to the key function, whose name I now forget, and a user-readable version of the rewrite that each block of code performs. Care is needed to be sure that the rewrites really are semantics preserving, given that overflow may happen. It's probably ok because the types involved do wrap-around, but that very point needs a careful `Note` in the code. By all means extend it further, but please do document it well. One thing to bear in mind is that these rewrite rules are tried for every single expression `(op a b)`, where `op` is (say) `Int#` addition, and every single iteration of the simplifier. So it needs to fail fast if it ends up doing nothing. An alternative would be an entirely separate pass, which can then be as expensive as you like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 12:05:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 12:05:00 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.e6a098fef4800860de2d1b19f56f54c1@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: nomeata Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by nomeata): * owner: => nomeata -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 12:06:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 12:06:12 -0000 Subject: [GHC] #9175: Bad interaction between Pattern Synonyms and Text In-Reply-To: <047.311a35a65ef21c36ac9cb789bb411456@haskell.org> References: <047.311a35a65ef21c36ac9cb789bb411456@haskell.org> Message-ID: <062.8d8214b32b61d70c763b4d06d52fe758@haskell.org> #9175: Bad interaction between Pattern Synonyms and Text ---------------------------------------+----------------------------------- Reporter: emertens | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7ac600d5fcd74db1f991555de6e415030970d5f3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7ac600d5fcd74db1f991555de6e415030970d5f3" Make the matcher and wrapper Ids in PatSyn into LocalIds, not GlobalIds This was a serious bug, exposed by Trac #9175. The matcher and wrapper must be LocalIds, like record selectors and dictionary functions, for the reasons now documented in Note [Exported LocalIds] in Id.lhs In fixing this I found - PatSyn should have an Id inside it (apart from the wrapper and matcher) It should be a Name. Hence psId --> psName, with knock-on consequences - Tidying of PatSyns in TidyPgm was wrong - The keep-alive set in Desugar.deSugar (now) doesn't need pattern synonyms in it I also cleaned up the interface to PatSyn a little, so there's a tiny knock-on effect in Haddock; hence the haddock submodule update. It's very hard to make a test for this bug, so I haven't. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 12:16:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 12:16:34 -0000 Subject: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS In-Reply-To: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> References: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> Message-ID: <060.9bdd1537b812d5a0294f2195b8fcfe63@haskell.org> #4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: ? Component: Runtime System | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by slyfox): Replying to [comment:24 simonmar]: > (b) merge into your patch please. Done as: 0001-Raise-exceptions-when-blocked-in-bad-FDs-fixes-Trac-.patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 12:19:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 12:19:04 -0000 Subject: [GHC] #8988: Documentation build fails if GHCi is unavailable In-Reply-To: <047.4e32c2ffd98d48e7ad6de5d06c23433e@haskell.org> References: <047.4e32c2ffd98d48e7ad6de5d06c23433e@haskell.org> Message-ID: <062.e76c77b50a158e7a5980d8bc6e0c7a0d@haskell.org> #8988: Documentation build fails if GHCi is unavailable -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: | Architecture: arm Operating System: Linux | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 12:25:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 12:25:34 -0000 Subject: [GHC] #9175: Bad interaction between Pattern Synonyms and Text In-Reply-To: <047.311a35a65ef21c36ac9cb789bb411456@haskell.org> References: <047.311a35a65ef21c36ac9cb789bb411456@haskell.org> Message-ID: <062.b72a3723e52734a82e1f22f757d1aa6c@haskell.org> #9175: Bad interaction between Pattern Synonyms and Text ---------------------------------------+----------------------------------- Reporter: emertens | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * status: new => merge Comment: Thank you for reporting this bug. It exposed a nasty bug in the pattern- synonym implementation, which I have now fixed. Nasty in that it's not easy to provoke... but I'm sure it would have bitten us soon enough. Indeed I'm not even going to add a test case. Please merge to 7.8.3 though (along with the corresponding Haddock patch. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 12:40:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 12:40:43 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.955f8a5a94ca9a9454f124f3ee4c043c@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by sjoerd_visscher): It might be a good idea to not to wait too long to merge the documentation patch in. Because the whole language options table is reordered any change to it will create a merge conflict. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 12:40:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 12:40:53 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.d046a956b29ed0828d3d07997cce2443@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: gzayas Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by gzayas): * owner: => gzayas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 12:45:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 12:45:41 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.992e93cb78470dcddf1e94a9d4aca2a7@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Would someone at ZuriHac like to do this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 13:04:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 13:04:54 -0000 Subject: [GHC] #9177: Suggest Int when user uses int In-Reply-To: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> References: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> Message-ID: <061.509e154c6bea6a34e2dfd982371c10e1@haskell.org> #9177: Suggest Int when user uses int -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #1388 -------------------------------------+------------------------------------ Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 13:06:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 13:06:07 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.46724f6b847bffefd8cc6b69d3662d4a@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Will have a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 13:07:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 13:07:23 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.c254f28a7f4c6c939406b7117a60ab8a@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by simonpj): I don't think anyone is working on injective type families right now, but it would make a good project, and not too difficult. Lunaris's patch has a lot of irrelevant white-space changes in it. But the biggest problem is that I don't think it implements the all-important check that a injective type family really is injective. Consider {{{ injective type family F a type instance F Int = Bool type instance F Char = Bool }}} This isn't injective and should jolly well be rejected. And this should be the case even if the two `type instance` declarations are in different modules. Similar code already exist for rejecting type-family ''overlap''; I think it is in `FamInst.checkFamInstConsistency`. But it'd need to be beefed up to deal with the injectiveness check. And you need to take care. What about {{{ type instance F Int = Bool -- (BAD) type instance F Char = F Int -- (BAD) }}} The two RHSs look different, but actually they are the same. The criterion for injectivity is that {{{ If (F t1 .. tn) ~ (F s1 .. sn) then t1 ~ s1 ... tn ~ sn }}} That doesn't hold for the (BAD) instances, so they should be rejected. In the terminology of the "Closed type families" paper, we need the two RHSs to be '''apart'''. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 13:18:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 13:18:03 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.3ff4619582fdd907390b4dc6eb7dbcfe@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by hpacheco): To get going, I wouldn't mind if the onus of proving that the type family is indeed injective fell on me, in an unsafe way. But I understand that it is clearly not a feature that you should blindly introduce in mainstream GHC... I may look into it in the future if I ever find the time, but I doubt it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 13:19:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 13:19:15 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.4e00a32b8829e394305cb64d60667df8@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by archblob): * cc: simonpj (added) Comment: I'm adding simonpj, maybe he can chime in. I'm writing again as documentation. I've been looking into the result of the dependency analysis done in `depAnalTyClDecls` and we have : {{{ REC type TEHelper = ToEnum Int class PEnum (k :: a) where type family ToEnum (x :: a) :: * type instance ToEnum x = TEHelper }}} which means we will try to check `TEHelper` before we generalize `ToEnum` and hence the kind check error. Braking the cycle and having: {{{ REC class PEnum (k :: a) where type family ToEnum (x :: a) :: * type instance ToEnum x = TEHelper NOREC type TEHelper = ToEnum Int }}} will only work if we defer default type instance checking as you suggested. These modifications have to go together. But they really fell hackish. One other thing that I don't know if we can do is somehow accommodate for this by tweaking the four steps in `kcTyClGroup` , I'll be looking into how to do that as an alternative and compare the two. Am I making sense ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 13:23:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 13:23:40 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.85d3f63fc588c61f6d49db4985b28758@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): archblob, you are digging into one of the darkest corners of the type inference engine. I don't have time to page all this in right now. My suggestion would be to tackle something easier for now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 13:28:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 13:28:10 -0000 Subject: [GHC] #9170: haddock: panic! (the 'impossible' happened) In-Reply-To: <048.9d4de3027be76ef0a09ec5d9f5740bb6@haskell.org> References: <048.9d4de3027be76ef0a09ec5d9f5740bb6@haskell.org> Message-ID: <063.a7401149e7168826f453c17c91c7b202@haskell.org> #9170: haddock: panic! (the 'impossible' happened) ---------------------------------------+----------------------------------- Reporter: diego.saa | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * version: 7.8.2 => 7.6.3 * resolution: => worksforme Old description: > After running "cabal install yi", I got this message: > > dist/build/tmp-79484/src/library/Yi/Eval.hs:139:5: Warning: > Defined but not used: `publishedActions_' > 73% ( 11 / 15) in 'Yi.Eval' > 19% ( 5 / 26) in 'Yi.Modes' > 25% ( 1 / 4) in 'Yi.Mode.IReader' > 0% ( 0 / 2) in 'Yi.Mode.Compilation' > 33% ( 1 / 3) in 'Yi.Mode.JavaScript' > 50% ( 2 / 4) in 'Yi.Mode.Latex' > 31% ( 4 / 13) in 'Yi.Mode.Interactive' > 60% ( 9 / 15) in 'Yi.Command' > 58% ( 15 / 26) in 'Yi.Keymap.Emacs.Utils' > haddock: panic! (the 'impossible' happened) > (GHC version 7.6.3 for x86_64-apple-darwin): > mkWWcpr: not a product > <
> > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > Installing library in > /Users/diegos/Library/Haskell/ghc-7.6.3/lib/yi-0.8.1/lib > Installing executable(s) in > /Users/diegos/Library/Haskell/ghc-7.6.3/lib/yi-0.8.1/bin > Registering yi-0.8.1... > Installed yi-0.8.1 > > I'm on OS 10.9.3, GHC 7.6.3. > > Please let me know if I can provide any other info that could be helpful, > or if a full output would help. > > Thanks, > Diego Saa New description: After running "cabal install yi", I got this message: {{{ dist/build/tmp-79484/src/library/Yi/Eval.hs:139:5: Warning: Defined but not used: `publishedActions_' 73% ( 11 / 15) in 'Yi.Eval' 19% ( 5 / 26) in 'Yi.Modes' 25% ( 1 / 4) in 'Yi.Mode.IReader' 0% ( 0 / 2) in 'Yi.Mode.Compilation' 33% ( 1 / 3) in 'Yi.Mode.JavaScript' 50% ( 2 / 4) in 'Yi.Mode.Latex' 31% ( 4 / 13) in 'Yi.Mode.Interactive' 60% ( 9 / 15) in 'Yi.Command' 58% ( 15 / 26) in 'Yi.Keymap.Emacs.Utils' haddock: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): mkWWcpr: not a product <
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Installing library in /Users/diegos/Library/Haskell/ghc-7.6.3/lib/yi-0.8.1/lib Installing executable(s) in /Users/diegos/Library/Haskell/ghc-7.6.3/lib/yi-0.8.1/bin Registering yi-0.8.1... Installed yi-0.8.1 }}} I'm on OS 10.9.3, GHC 7.6.3. Please let me know if I can provide any other info that could be helpful, or if a full output would help. Thanks, Diego Saa -- Comment: Thank you -- that looks bad. You say "Version = 7.8.2" in the ticket header, but then in your comments you say GHC 7.6.3. Let's assume the comments are right. I've just successfully done `cabal install yi` with (something very close to) 7.8.2. So I think it's probably already fixed. Do re-open if you disagree. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 13:54:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 13:54:31 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.bae92bc38629806e0c61291993f4c888@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: skeuchel Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Blaisorblade): Replying to [comment:7 skeuchel]: my progress is in this branch: https://github.com/Blaisorblade/ghc/tree/topic/fuseTakeWhile (see https://github.com/Blaisorblade/ghc/pull/1 for a better web interface), and include some doc changes. Since you assigned the bug to yourself (so I guess you plan to work on it), you might want to resume from there. Current status: the changes are done and do work on my example (causing fusion), now one should validate the performance impacts. Right now, I didn't write a benchmark to measure the speedup on my program (or any other), and there's no net effect on nofib (even though takeWhile is sometimes called ? but probably not in inner loops). The automated tests are also missing. (Sorry for not getting back to you before, I'm traveling lots this month ? next week I'm at PLDI). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 14:09:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 14:09:05 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.f61a3a6f322e5d266838a437cc46ab24@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by juhpetersen): Sergei asked on ghc-dev list for more context. This is about shared libaries: of course there is no impact on platforms without them. Starting with ghc-7.8, ghc's own binaries are also dynamically on platforms with dyn Haskell libs. Shipping the shared library without devel files on Linux seems quite unnatural and awkward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 14:09:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 14:09:34 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.a51bd15d3803901ad830bb2082e2364c@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Sjoerd Visscher ): In [changeset:"3bdc78b520c05706f8b66033b154c07ed021ac33/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3bdc78b520c05706f8b66033b154c07ed021ac33" Make DeriveTraversable imply DeriveFunctor/Foldable Implements #9069 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 14:09:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 14:09:34 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.979208bafc7d6e25e789d394440fdeaa@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Sjoerd Visscher ): In [changeset:"63d7047a8a20c4e8b1c050b4577bbd7ee5cebafc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="63d7047a8a20c4e8b1c050b4577bbd7ee5cebafc" Added testcase for #9069 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 14:09:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 14:09:35 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.89ae210893ed50ab76a3dfa1eb9d26a5@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: nomeata Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Joachim Breitner ): In [changeset:"819e1f2c2e10268fe3edc8395f2707b93c9c6f4d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="819e1f2c2e10268fe3edc8395f2707b93c9c6f4d" Use UnicodeSyntax when printing When printing Haskell source, and UnicodeSyntax is enabled, use the unicode sytax characters (#8959). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 14:10:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 14:10:07 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.2b67e4348887b8069bffec02b4983b4c@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: Looked fined and validated; pushed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 14:10:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 14:10:39 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.7e42ed3d23b8aa3662e776a58240ae02@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: nomeata Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by nomeata): That was indeed straight-forward, pushed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 14:10:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 14:10:45 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.230d537ae39ac87593f8703214b9224e@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: nomeata Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 14:12:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 14:12:58 -0000 Subject: [GHC] #9177: Suggest Int when user uses int In-Reply-To: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> References: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> Message-ID: <061.ce9c0b35f02c4764060c807975064bdf@haskell.org> #9177: Suggest Int when user uses int -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #1388 -------------------------------------+------------------------------------ Comment (by goldfire): Replying to [comment:3 nomeata]: > I have two variants: One that suggests `Integer` when `integer` is typed, and one that suggests even `Integer` if `integerr` is typed (using the same edit distance metric stuff). I?ll push the first, followed by the second, so that one can easily revert. > > Of course there is no limit on how smart the error message can be. In `type Foo = eq`, one cannot mean `Eq` (as it is a class), but that is not available on the level of `OccNames`. But I guess the suggestion is still an improvement. In case anyone is inspired to make this smarter, I'll note that `type Foo = Eq` is perfectly reasonable, in the presence of !ConstraintKinds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 14:23:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 14:23:26 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.7294f318bce053aef7c95bd967319d2e@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): > Shipping the shared library without devel files on Linux seems quite unnatural and awkward. I?m not sure about this: If the `.so` file is put in a private location (not `/usr/lib`, what?s wrong with that)? I?d actually prefer if GHC would ship as few packages as little, so that as many packages as possible can be packaged and installed in the ?common? way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 14:54:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 14:54:51 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.b6a0039e068043e24727155da8d946b5@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: nomeata Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by hvr): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 14:56:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 14:56:19 -0000 Subject: [GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable In-Reply-To: <054.98121a1976ff390c1bc22f999087be97@haskell.org> References: <054.98121a1976ff390c1bc22f999087be97@haskell.org> Message-ID: <069.a2f5fc4fdb0eae7bd01edb8d984ab0f5@haskell.org> #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable -------------------------------------+------------------------------------ Reporter: sjoerd_visscher | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 14:57:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 14:57:08 -0000 Subject: [GHC] #9177: Suggest Int when user uses int In-Reply-To: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> References: <046.3ce52a4ffb45ef4a4d975c61b827d528@haskell.org> Message-ID: <061.4446524fc0f26df4e4101cba4a036ae1@haskell.org> #9177: Suggest Int when user uses int -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #1388 -------------------------------------+------------------------------------ Changes (by hvr): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 16:54:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 16:54:44 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.e21403141aae4bbbe7859e5019800597@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by nomeata): * owner: nomeata => * status: closed => new * resolution: fixed => Comment: I just noticed that my patch only works if `-XUnicodeSyntax` is passed on the command line, or set with `:set`. It does not work simply because you load a file with `LANGUAGE UnicodeSyntax`. Should it? Other pragmas (tested it with `RankNTypes`) in a loaded file also don?t affect what you enter at GHCi. Also, the pragma does not have an effect on the error message printed by the compiler in error messages from a file with `UnicodeSyntax` active. The `dynflag` passed to the pretty-printer seems to be a different one than used when type-checking. (Reopening) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 16:56:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 16:56:51 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.283602494d558002cb30ae850f279914@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Joachim Breitner ): In [changeset:"b0215729214859051abf78f6cf5012805fe7d764/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b0215729214859051abf78f6cf5012805fe7d764" Test case: GHCi uses UnicodeSyntax if the loaded file uses it. Its marked as broken, as this does not work yet, but we are calling it a day here soon, so I want this to be recorded (#8959). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 17:03:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 17:03:40 -0000 Subject: [GHC] #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) In-Reply-To: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> References: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> Message-ID: <060.b3f9ce8f80e35829acfcc403c7878134@haskell.org> #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) ---------------------------------------+---------------------------------- Reporter: slyfox | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler (NCG) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by Simon Marlow ): In [changeset:"e577a52363ee7ee8a07f1d863988332ae8fbf2e4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e577a52363ee7ee8a07f1d863988332ae8fbf2e4" Fix discarding of unreachable code in the register allocator (#9155) A previous fix to this was wrong: f5879acd018494b84233f26fba828ce376d0f81d and left some unreachable code behind. So rather than try to be clever and do this at the same time as the strongly-connected-component analysis, I'm doing a separate reachability pass first. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 17:04:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 17:04:17 -0000 Subject: [GHC] #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) In-Reply-To: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> References: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> Message-ID: <060.21ed6d7e74d97a6d4fe283eeb04bf524@haskell.org> #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) ---------------------------------------+---------------------------------- Reporter: slyfox | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: Compiler (NCG) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by simonmar): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 17:16:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 17:16:30 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.304f17c9004fc7872a29c054ed877070@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: gzayas Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by gzayas): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 17:17:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 17:17:40 -0000 Subject: [GHC] #9178: improve orphan instance warning In-Reply-To: <043.fcde19f8eb765ccd6976e8ca3285d142@haskell.org> References: <043.fcde19f8eb765ccd6976e8ca3285d142@haskell.org> Message-ID: <058.9a5704726aee214b49893237b172772f@haskell.org> #9178: improve orphan instance warning -------------------------------------+------------------------------------ Reporter: fphh | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by fphh): * status: new => patch Comment: Finished, ready for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 17:18:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 17:18:50 -0000 Subject: [GHC] #9178: improve orphan instance warning In-Reply-To: <043.fcde19f8eb765ccd6976e8ca3285d142@haskell.org> References: <043.fcde19f8eb765ccd6976e8ca3285d142@haskell.org> Message-ID: <058.5d8cac6373a8462554293718ee774156@haskell.org> #9178: improve orphan instance warning -------------------------------------+------------------------------------ Reporter: fphh | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by fphh): This is how it looks like. What do you think? {{{ T9178.hs:8:10: Warning: Orphan instance: instance Show T9178_Type To avoid this move the instance declaration to the module of the class or of the type, or wrap the type with a newtype and declare the instance on the new type. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 17:30:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 17:30:56 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.aef760e312e61881159be968d6712159@haskell.org> #9156: Duplicate record field ------------------------------------------------+-------------------------- Reporter: wojteknar | Owner: gintas Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: T9156 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by gintas): * testcase: => T9156 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 17:35:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 17:35:46 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.ae7da40e3b1b3ce1af7da88ca64e25e7@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by hvr): Replying to [comment:7 nomeata]: > Should it? Other pragmas (tested it with `RankNTypes`) in a loaded file also don?t affect what you enter at GHCi. Btw, the prompt is usually affected by `:seti -X...` rather than `:set -X...` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 21:41:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 21:41:45 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.0df5fdaf5d3f813db3b67e02a9d24de0@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: > Btw, the prompt is usually affected by :seti -X... rather than :set -X... Yes, just read up on that in the docs. But `:set` is not wrong either... So I guess there is a more general question there: If I load a module into GHCi with a `*` (i.e. the ?inside view? with everything top-level in scope), then in a way I have ?entered? that module. Shouldn?t then all language pragmas of that module hold for me as well? And as general as this question is, it has of course been discussed before. I found #5673 (which I even took part in ? I need to buy better memory ;-)) which points to [wiki:3217#comment:15] So #3217 covers the remaining bits of this ticket well, closing this (again). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 21:41:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 21:41:49 -0000 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@haskell.org> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@haskell.org> Message-ID: <061.8943e954141f43a7e263440d35a7599c@haskell.org> #3217: Make GHCi have separate flags for interactive Haskell expressions -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 6.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3202 | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Related ticket: If this were implemented, #8959 (pretty-printing based on `UnicodeSyntax`) would work as expected by the submitter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 21:44:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 21:44:49 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.4c7f55f589cb600535904d8b5ea1bd12@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: gzayas Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"fbdebd30b9ff3ca76243791723b85959c6860083/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fbdebd30b9ff3ca76243791723b85959c6860083" supress warning of bang wildcard pattern-binding (i.e. let !_ = rhs). This fixes #9127 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 21:45:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 21:45:35 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.85fb3120b02034b340a1961153dcbba4@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: gzayas Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Reviewed, validated and pushed, thanks Guido for your first contribution to GHC! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 21:47:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 21:47:12 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.e9c35e03161c9bf729101271ce5a6f09@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: gzayas Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 22:00:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 22:00:04 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.7051dcd3d60c6ea90dfa93fcd31b1562@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: gzayas Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I'd love to see this documented in the user manual, please. Look at [http://www.haskell.org/ghc/docs/latest/html/users_guide/options- sanity.html sanity checking] and `-fwarn-unused-bindings`. There are really two things enabled by `-fwarn-unused_bindings`: * Warning about a named variable brought into scope but not used (unless exported or starting with underscore). e.g. {{{ let f x = rhs1 in True -- Warning for unused f let (p,q) = rhs2 in p+1 -- Warning about unused q }}} * Warning about a pattern binding that doesn't bind anything; e.g. {{{ Just _ = rhs1 -- Warning for unused binding (_, _) = rhs2 -- Warning for unused binding }}} But no warning is given for a lone wild-card pattern or banged wild-card pattern: {{{ _ = rhs3 -- No warning !_ = rhs4 -- No warning; behaves like seq }}} The former is not very different from `_v = rhs3` which elicits no warning; and can be useful to add a type constraint, e.g. `_ = x::Int`. The latter is useful as an alternative way to force evaluation. Could you add all that to the manual? Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 22:00:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 22:00:29 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.fdd41e99a8ddf7e8ed5b2784f6b3de9e@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * owner: gzayas => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 6 22:38:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jun 2014 22:38:21 -0000 Subject: [GHC] #9179: Documentation suggests to use '-hi-diffs' but it should be '-ddump-hi-diffs' Message-ID: <050.f0117dea6d928cd0e913b57370221cc6@haskell.org> #9179: Documentation suggests to use '-hi-diffs' but it should be '-ddump-hi- diffs' ------------------------------------+-------------------------------------- Reporter: shalehperry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/wrong-compilee.html The option '-hi-diffs' does not exist but '-ddump-hi-diffs' does. Please update the docs. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 00:32:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 00:32:45 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.446d6aa2c5af8f1be5acfbef33e8f284@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------ Reporter: cactus | Owner: cactus 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 | Difficulty: Unknown Test Case: | Blocked By: 5144 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dfranke): `_` in expressions is already in use for typed holes (http://www.haskell.org/ghc/docs/latest/html/users_guide/typed- holes.html). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 02:15:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 02:15:25 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.dace3175b2f1a84333228e57c718888f@haskell.org> #8779: Exhaustiveness checks for pattern synonyms --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by dfranke): * cc: dfranke (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 02:23:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 02:23:47 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.c5bf6534d70531d44eb171dd2ce8a844@haskell.org> #8779: Exhaustiveness checks for pattern synonyms --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by dfranke): In the common case where all pattern synonyms in a set of binding clauses are simply bidirectional, exhaustiveness can be inferred automatically. It would be nice if GHC did this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 05:23:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 05:23:22 -0000 Subject: [GHC] #8226: Remove the old style -- # Haddock comments. In-Reply-To: <047.96b6209768296ad11c174e077e349059@haskell.org> References: <047.96b6209768296ad11c174e077e349059@haskell.org> Message-ID: <062.bce0005a8850aa18a86951d9858aa066@haskell.org> #8226: Remove the old style -- # Haddock comments. -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Fuuzetsu): Sorry I fell behind a bit on reading GHC tickets. Yes adinapoli, those should also be removed, we do not use --# for anything and it served the same purpose as {-# as far as I know. Also the data type used to store that type of comment should be removed: https://github.com/ghc/ghc/blob/master/compiler/parser/Lexer.x#L625 FTR the Haddock ticket is now tracked at https://github.com/haskell/haddock/issues/171 Thanks for looking into this, feel free to poke me on IRC/e-mail if you need more immediate review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 05:29:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 05:29:49 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5MDU3OiBSZW1vdmUgL3Vzci9iaW4v4oCmIHJl?= =?utf-8?q?ferences?= In-Reply-To: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> References: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> Message-ID: <062.cb6b8eba6cad3d3883fb952c982737f5@haskell.org> #9057: Remove /usr/bin/? references -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: new Priority: low | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by Fuuzetsu): * priority: normal => low Comment: As far as I can tell, there's no way to pass such flags to programs while using `env` and these flags have to be accomodated for on script-by-script basis. So for example `#!/usr/bin/perl -w` becomes `#!/usr/bin/env perl` and `use warnings;` should be set instead of using `-w`. I'll look into patching out the paths I mentioned in the following few days if I get some time. It is of no high priority to me at the moment as during the build process my distro's tools patch up the shebangs anyway but it's a matter of principle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 06:43:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 06:43:54 -0000 Subject: [GHC] #9170: haddock: panic! (the 'impossible' happened) In-Reply-To: <048.9d4de3027be76ef0a09ec5d9f5740bb6@haskell.org> References: <048.9d4de3027be76ef0a09ec5d9f5740bb6@haskell.org> Message-ID: <063.b633f4eac8586d8d2ab59e1081e3ba81@haskell.org> #9170: haddock: panic! (the 'impossible' happened) ---------------------------------------+----------------------------------- Reporter: diego.saa | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Fuuzetsu): Actually I was made aware of this few weeks ago (precisely with 7.6.3 and precisely for Yi). I have in fact a check-out here of Yi that fails to Haddock with 7.6.3 but I just built the docs fine with 7.8.2 with the respective Haddock versions that come with each so yes, it does seem to have gone away. Note that I don't recall fixing anything like this specifically so it seems like it was a GHC change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 07:58:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 07:58:35 -0000 Subject: [GHC] #9179: Documentation suggests to use '-hi-diffs' but it should be '-ddump-hi-diffs' In-Reply-To: <050.f0117dea6d928cd0e913b57370221cc6@haskell.org> References: <050.f0117dea6d928cd0e913b57370221cc6@haskell.org> Message-ID: <065.4e5f4ebb7f3d0c13000cf3ddd31a0c8d@haskell.org> #9179: Documentation suggests to use '-hi-diffs' but it should be '-ddump-hi- diffs' --------------------------------------+------------------------------------ Reporter: shalehperry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"ab3f95bdfc5c001c7dd3158c52bad604d28aabf3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ab3f95bdfc5c001c7dd3158c52bad604d28aabf3" s/-hi-diffs/-ddump-hi-diffs/ in docs (#9179) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 07:58:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 07:58:51 -0000 Subject: [GHC] #9179: Documentation suggests to use '-hi-diffs' but it should be '-ddump-hi-diffs' In-Reply-To: <050.f0117dea6d928cd0e913b57370221cc6@haskell.org> References: <050.f0117dea6d928cd0e913b57370221cc6@haskell.org> Message-ID: <065.79a7a46b37762931dd33ecf924dd76bf@haskell.org> #9179: Documentation suggests to use '-hi-diffs' but it should be '-ddump-hi- diffs' --------------------------------------+------------------------------------ Reporter: shalehperry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by nomeata): Thanks for noticing, fixed and pushed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 08:05:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 08:05:35 -0000 Subject: [GHC] #9180: New magic function `staticError` Message-ID: <046.f02a1097d6c172420c24668297fdcea7@haskell.org> #9180: New magic function `staticError` ------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- While playing games with `RULES`, I had the need for a way to tell the compiler ?please spit out an error message?, in my case if list fusion fails where the user explicitly requested for it. Currently I put an `error "List did not fuse"` in the code using a `RULE`, but what I?d really like to do is to put in a `staticError "List did not fuse"` that, if appearing in Core (say, after the final simplification) causes GHC to abort and print this message. (I?m tempted to use type level strings somehow to make sure that the parameter to `staticError` is not present at the value level, and also that the string is easier to obtain. I?ll see.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 08:08:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 08:08:47 -0000 Subject: [GHC] #9181: :browse GHC.TypeLits causes panic Message-ID: <046.8fd03c7f0662245eda394b5b6f7e1e4c@haskell.org> #9181: :browse GHC.TypeLits causes panic ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: T9181 Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Upon `:browse GHC.TypeLits` I get: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20140606 for x86_64-unknown-linux): toIfaceDecl: BuiltInFamTyCon * Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 08:09:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 08:09:44 -0000 Subject: [GHC] #9181: :browse GHC.TypeLits causes panic In-Reply-To: <046.8fd03c7f0662245eda394b5b6f7e1e4c@haskell.org> References: <046.8fd03c7f0662245eda394b5b6f7e1e4c@haskell.org> Message-ID: <061.5e968ef50f745cf5dfc90d32d16ffc45@haskell.org> #9181: :browse GHC.TypeLits causes panic -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: T9181 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"b36bc2f5a9757c2b7e6967893cf2883846b8ce91/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b36bc2f5a9757c2b7e6967893cf2883846b8ce91" Test case for #9181 (:browse GHC.TypeLits panic) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 10:08:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 10:08:08 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.b1d67629aaeff2d4235e75eec6461059@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by nomeata): Sigh: #3217 is not all there is to fix. Independent of GHCi we seem to want error messages from modules with `UnicodeSyntax` printed with that syntax. So we need to instrument `SDoc` in error messages with the settings from where the setting originated. The `dynflags` passed in `SDocContext` does not work for this, as they are the dynflags in scope when the error is printed, i.e. outside the module scope. There is precedence: The `PrintUnqualified` field of `ErrMsg` and later of `PprUser` transports information about how to pretty print stuff from the location of error to when its `SDoc` is rendered. I added a `Bool` there to indicate whether `UnicodeSyntax` should be used and it seems to work, but I?m not satisfied with this design. Stored the change in the `wip/T8959` branch, see [changeset:4a4e684f4/ghc]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 10:08:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 10:08:14 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.bdf719d2900440ced467650ae46bc7ef@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by nomeata): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 10:15:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 10:15:06 -0000 Subject: [GHC] #8613: simplifier ticks exhausted In-Reply-To: <044.3c96d4abc261f1969033a0de42af80e6@haskell.org> References: <044.3c96d4abc261f1969033a0de42af80e6@haskell.org> Message-ID: <059.27a759820913996235cb4511ca008ee4@haskell.org> #8613: simplifier ticks exhausted -----------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Description changed by nomeata: Old description: > (Sent by chrisreade at mac.com ) > Compiler giving up with simplifier ticks exhausted. > Large amount of simplification may be going on to cause this. > The problem goes away when using -fsimpl-tick-factor=1000 and the code > runs. > This is the session output without the flag (asking to have bug > reported): > > chris$ ghc -O2 -rtsopts RedBlackStencilOpt.hs -v > Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version > 7.4.2 > Using binary package database: > /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d/package.cache > Using binary package database: > /Users/chris/.ghc/x86_64-darwin-7.6.3/package.conf.d/package.cache > hiding package binary-0.5.1.1 to avoid conflict with later version > binary-0.6.4.0 > hiding package Cabal-1.16.0 to avoid conflict with later version > Cabal-1.18.1.1 > wired-in package ghc-prim mapped to ghc- > prim-0.3.0.0-d5221a8c8a269b66ab9a07bdc23317dd > wired-in package integer-gmp mapped to integer- > gmp-0.5.0.0-2f15426f5b53fe4c6490832f9b20d8d7 > wired-in package base mapped to > base-4.6.0.1-6c351d70a24d3e96f315cba68f3acf57 > wired-in package rts mapped to builtin_rts > wired-in package template-haskell mapped to template- > haskell-2.8.0.0-c2c1b21dbbb37ace4b7dc26c966ec664 > wired-in package dph-seq not found. > wired-in package dph-par not found. > Hsc static flags: -static > *** Chasing dependencies: > Chasing modules from: *RedBlackStencilOpt.hs > Stable obj: [] > Stable BCO: [] > Ready for upsweep > [NONREC > ModSummary { > ms_hs_date = 2013-12-13 13:12:37 UTC > ms_mod = main:RedBlackStencilOpt, > ms_textual_imps = [import (implicit) Prelude, > import Data.Array.Repa.Stencil.Dim2 as A, > import Data.Array.Repa.Stencil as A, import > Data.Array.Repa as A] > ms_srcimps = [] > }] > *** Deleting temp files: > Deleting: > compile: input file RedBlackStencilOpt.hs > Created temporary directory: > /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 > *** Checking old interface for main:RedBlackStencilOpt: > [1 of 1] Compiling RedBlackStencilOpt ( RedBlackStencilOpt.hs, > RedBlackStencilOpt.o ) > *** Parser: > *** Renamer/typechecker: > *** Simplify: > *** CorePrep: > *** ByteCodeGen: > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > *** gcc: > '/usr/bin/gcc' '-m64' '-fno-stack-protector' '-m64' > '-L/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/base-4.6.0.1' > '--print-file-name' 'libiconv.dylib' > Loading package base ... linking ... done. > Loading package pretty-1.1.1.0 ... linking ... done. > Loading package array-0.4.0.1 ... linking ... done. > Loading package deepseq-1.3.0.1 ... linking ... done. > Loading package containers-0.5.0.0 ... linking ... done. > Loading package old-locale-1.0.0.5 ... linking ... done. > Loading package time-1.4.0.1 ... linking ... done. > Loading package random-1.0.1.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package QuickCheck-2.6 ... linking ... done. > Loading package bytestring-0.10.0.2 ... linking ... done. > Loading package primitive-0.5.0.1 ... linking ... done. > Loading package vector-0.10.0.1 ... linking ... done. > Loading package repa-3.2.3.3 ... linking ... done. > *** Simplify: > *** CorePrep: > *** ByteCodeGen: > *** Desugar: > Result size of Desugar (after optimization) > = {terms: 900, types: 1,810, coercions: 340} > *** Simplifier: > Result size of Simplifier iteration=1 > = {terms: 834, types: 1,757, coercions: 567} > Result size of Simplifier iteration=2 > = {terms: 830, types: 1,721, coercions: 567} > Result size of Simplifier > = {terms: 830, types: 1,721, coercions: 567} > *** Specialise: > Result size of Specialise > = {terms: 830, types: 1,721, coercions: 567} > *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): > Result size of Float out(FOS {Lam = Just 0, > Consts = True, > PAPs = False}) > = {terms: 993, types: 2,131, coercions: 567} > *** Float inwards: > Result size of Float inwards > = {terms: 993, types: 2,131, coercions: 567} > *** Simplifier: > *** Deleting temp files: > Deleting: > /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s > Warning: deleting non-existent > /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s > *** Deleting temp dirs: > Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 > ghc: panic! (the 'impossible' happened) > (GHC version 7.6.3 for x86_64-apple-darwin): > Simplifier ticks exhausted > When trying RuleFired Class op szipWith > 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: 60402 > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: (Sent by chrisreade at mac.com ) Compiler giving up with simplifier ticks exhausted. Large amount of simplification may be going on to cause this. The problem goes away when using -fsimpl-tick-factor=1000 and the code runs. This is the session output without the flag (asking to have bug reported): {{{ chris$ ghc -O2 -rtsopts RedBlackStencilOpt.hs -v Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version 7.4.2 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d/package.cache Using binary package database: /Users/chris/.ghc/x86_64-darwin-7.6.3/package.conf.d/package.cache hiding package binary-0.5.1.1 to avoid conflict with later version binary-0.6.4.0 hiding package Cabal-1.16.0 to avoid conflict with later version Cabal-1.18.1.1 wired-in package ghc-prim mapped to ghc- prim-0.3.0.0-d5221a8c8a269b66ab9a07bdc23317dd wired-in package integer-gmp mapped to integer- gmp-0.5.0.0-2f15426f5b53fe4c6490832f9b20d8d7 wired-in package base mapped to base-4.6.0.1-6c351d70a24d3e96f315cba68f3acf57 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.8.0.0-c2c1b21dbbb37ace4b7dc26c966ec664 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *RedBlackStencilOpt.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2013-12-13 13:12:37 UTC ms_mod = main:RedBlackStencilOpt, ms_textual_imps = [import (implicit) Prelude, import Data.Array.Repa.Stencil.Dim2 as A, import Data.Array.Repa.Stencil as A, import Data.Array.Repa as A] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file RedBlackStencilOpt.hs Created temporary directory: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 *** Checking old interface for main:RedBlackStencilOpt: [1 of 1] Compiling RedBlackStencilOpt ( RedBlackStencilOpt.hs, RedBlackStencilOpt.o ) *** Parser: *** Renamer/typechecker: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. *** gcc: '/usr/bin/gcc' '-m64' '-fno-stack-protector' '-m64' '-L/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/base-4.6.0.1' '--print-file-name' 'libiconv.dylib' Loading package base ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package QuickCheck-2.6 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package primitive-0.5.0.1 ... linking ... done. Loading package vector-0.10.0.1 ... linking ... done. Loading package repa-3.2.3.3 ... linking ... done. *** Simplify: *** CorePrep: *** ByteCodeGen: *** Desugar: Result size of Desugar (after optimization) = {terms: 900, types: 1,810, coercions: 340} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 834, types: 1,757, coercions: 567} Result size of Simplifier iteration=2 = {terms: 830, types: 1,721, coercions: 567} Result size of Simplifier = {terms: 830, types: 1,721, coercions: 567} *** Specialise: Result size of Specialise = {terms: 830, types: 1,721, coercions: 567} *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 993, types: 2,131, coercions: 567} *** Float inwards: Result size of Float inwards = {terms: 993, types: 2,131, coercions: 567} *** Simplifier: *** Deleting temp files: Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s Warning: deleting non-existent /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s *** Deleting temp dirs: Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying RuleFired Class op szipWith 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: 60402 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 10:21:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 10:21:09 -0000 Subject: [GHC] #4836: literate markdown not handled correctly by unlit In-Reply-To: <044.677d9d9819274dc3e0fccfc271c35be2@haskell.org> References: <044.677d9d9819274dc3e0fccfc271c35be2@haskell.org> Message-ID: <059.af0b4382fea68bb97f1dcd311a0c35ed@haskell.org> #4836: literate markdown not handled correctly by unlit ----------------------------------------------+---------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7120 ----------------------------------------------+---------------------------- Comment (by dominic): I have probably misunderstood but I don't think this solves the problem. I have cherry-picked your commits. For the code example above {{{ ### Ok so lets try this again. ### A page that loads and compiles: > myfact 0 = 1 > myfact n = n * n-1 Lets see if it works! }}} saved as a .lhs file I get {{{ ~/ghc $ ./inplace/bin/ghc-stage2 TheLitTest.lhs TheLitTest.lhs:1:2: lexical error at character '#' }}} Saving it as a .md file mutatis mutandis {{{ ### Ok so lets try this again. ### A page that loads and compiles: ``` module Main ( main ) where myfact 0 = 1 myfact n = n * n-1 main = undefined ``` Lets see if it works! }}} it compiles successfully but then other tools e.g. BlogLiterately don't work. They rely on the bird tracks. So I think this may solve a problem but it doesn't solve this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 11:06:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 11:06:55 -0000 Subject: [GHC] #9181: :browse GHC.TypeLits causes panic In-Reply-To: <046.8fd03c7f0662245eda394b5b6f7e1e4c@haskell.org> References: <046.8fd03c7f0662245eda394b5b6f7e1e4c@haskell.org> Message-ID: <061.83601d46a4ddaecc3ab507c337f2e242@haskell.org> #9181: :browse GHC.TypeLits causes panic -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: T9181 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): This is caused by {{{ to_ifsyn_rhs (BuiltInSynFamTyCon {}) = pprPanic "toIfaceDecl: BuiltInFamTyCon" (ppr tycon) }}} in `tyConToIfaceDecl`. Of course we don?t want `BuiltInSynFamTyCon` in interface files, but we use `tyConToIfaceDecl` (via `pprTyThing`) also for pretty-printing. So this function needs to be made ?totaler?. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 11:52:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 11:52:59 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.d4d9d740ee575cdacc13d13a908e3eb3@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by errge): I've been asked to briefly summarize the issue, since simons didn't write too much about it in the ticket itself. GHC 7.8 uses the xhtml, terminfo and haskeline packages internally. Because of the dynamic ghci transition, the related .so files have to be shipped with the build. By not shipping the devel files (not making the cabal packages visible), we force the distribution vendors to package up these libraries separately and make them available in their repos. Nothing wrong with that of course (they do this for all the other important libraries, like lens and pipes too). The problem is that they can't ship the .so files in the respective packages, because it's usually not allowed for packages to overwrite each other's files in an adhoc manner. So when they build e.g. the xhtml deb or rpm package, they have to make sure that if the resulting .so files have the same name as the ghc shipped ones, then they don't include it in the package. These kind of workarounds seem extremely kludgy and fragile to me. This naming/overwrite issue causes some headaches for NixOS too, just in a slightly different setting. I see two solutions going forward. As nomeata said in comment 16, we can simply ship our .so files in a private directory and make our dynamic programs search there (via RPATH or some other trick). Or we can simply ship these packages with GHC as we ship base, time and so many others. juhpetersen posted a patch for that in comment 14. Alternatively, we can ignore it and just force people to go with the workarounds. I'd prefer not doing that. There were also some discussion on the mailing list about discontinuing the dynamic change after 7.10 and going back to static, which would of course make this go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 11:56:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 11:56:32 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.64f6014572822faa72addcb7ffa97434@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by errge): * status: new => patch Old description: > GHC 7.8.1-rc2 installs the xhtml library, but doesn't export it, i.e. > it's completely invisible to users. Is there a particular reason why this > setup is necessary? > > If GHC needs that library internally anywhere, would it be possible to > link it statically and *not* install it? > > Or, if that's not possible, if the library needs to be installed, please > make it visible to users. New description: GHC 7.8.1-rc2 installs the xhtml library, but doesn't export it, i.e. it's completely invisible to users. Is there a particular reason why this setup is necessary? If GHC needs that library internally anywhere, would it be possible to link it statically and *not* install it? Or, if that's not possible, if the library needs to be installed, please make it visible to users. See comment 17 for a discussion on why this is causing problems for distribution vendors. -- Comment: Setting this to "please review", because two different ways have been analyzed, patch has been proposed for one of them and decision is needed from GHC HQ on how to proceed. If GHC HQ decides on the solution, I'm happy to prepare/review/test solutions on an expedited bases if it has a chance to go into 7.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 12:50:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 12:50:47 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.a0404137fb499f241b145fada403c38c@haskell.org> #9156: Duplicate record field ------------------------------------------------+-------------------------- Reporter: wojteknar | Owner: gintas Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: T9156 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by gintas): Wait, some performance tests are failing, I don't think they're flukes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 12:51:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 12:51:12 -0000 Subject: [GHC] #9181: :browse GHC.TypeLits causes panic In-Reply-To: <046.8fd03c7f0662245eda394b5b6f7e1e4c@haskell.org> References: <046.8fd03c7f0662245eda394b5b6f7e1e4c@haskell.org> Message-ID: <061.1c7e7bd909855b1fc821c0b0de83fe1f@haskell.org> #9181: :browse GHC.TypeLits causes panic -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: T9181 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"96a8980183ed12a354db1b92f271b98bccce9ae8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="96a8980183ed12a354db1b92f271b98bccce9ae8" Pretty-print built in synonym families in interfaces This closes #9181. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 12:52:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 12:52:38 -0000 Subject: [GHC] #8613: simplifier ticks exhausted In-Reply-To: <044.3c96d4abc261f1969033a0de42af80e6@haskell.org> References: <044.3c96d4abc261f1969033a0de42af80e6@haskell.org> Message-ID: <059.a9e75fc01fdea6d839998531b22d51b7@haskell.org> #8613: simplifier ticks exhausted -----------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Old description: > (Sent by chrisreade at mac.com ) > Compiler giving up with simplifier ticks exhausted. > Large amount of simplification may be going on to cause this. > The problem goes away when using -fsimpl-tick-factor=1000 and the code > runs. > This is the session output without the flag (asking to have bug > reported): > {{{ > chris$ ghc -O2 -rtsopts RedBlackStencilOpt.hs -v > Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version > 7.4.2 > Using binary package database: > /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d/package.cache > Using binary package database: > /Users/chris/.ghc/x86_64-darwin-7.6.3/package.conf.d/package.cache > hiding package binary-0.5.1.1 to avoid conflict with later version > binary-0.6.4.0 > hiding package Cabal-1.16.0 to avoid conflict with later version > Cabal-1.18.1.1 > wired-in package ghc-prim mapped to ghc- > prim-0.3.0.0-d5221a8c8a269b66ab9a07bdc23317dd > wired-in package integer-gmp mapped to integer- > gmp-0.5.0.0-2f15426f5b53fe4c6490832f9b20d8d7 > wired-in package base mapped to > base-4.6.0.1-6c351d70a24d3e96f315cba68f3acf57 > wired-in package rts mapped to builtin_rts > wired-in package template-haskell mapped to template- > haskell-2.8.0.0-c2c1b21dbbb37ace4b7dc26c966ec664 > wired-in package dph-seq not found. > wired-in package dph-par not found. > Hsc static flags: -static > *** Chasing dependencies: > Chasing modules from: *RedBlackStencilOpt.hs > Stable obj: [] > Stable BCO: [] > Ready for upsweep > [NONREC > ModSummary { > ms_hs_date = 2013-12-13 13:12:37 UTC > ms_mod = main:RedBlackStencilOpt, > ms_textual_imps = [import (implicit) Prelude, > import Data.Array.Repa.Stencil.Dim2 as A, > import Data.Array.Repa.Stencil as A, import > Data.Array.Repa as A] > ms_srcimps = [] > }] > *** Deleting temp files: > Deleting: > compile: input file RedBlackStencilOpt.hs > Created temporary directory: > /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 > *** Checking old interface for main:RedBlackStencilOpt: > [1 of 1] Compiling RedBlackStencilOpt ( RedBlackStencilOpt.hs, > RedBlackStencilOpt.o ) > *** Parser: > *** Renamer/typechecker: > *** Simplify: > *** CorePrep: > *** ByteCodeGen: > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > *** gcc: > '/usr/bin/gcc' '-m64' '-fno-stack-protector' '-m64' > '-L/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/base-4.6.0.1' > '--print-file-name' 'libiconv.dylib' > Loading package base ... linking ... done. > Loading package pretty-1.1.1.0 ... linking ... done. > Loading package array-0.4.0.1 ... linking ... done. > Loading package deepseq-1.3.0.1 ... linking ... done. > Loading package containers-0.5.0.0 ... linking ... done. > Loading package old-locale-1.0.0.5 ... linking ... done. > Loading package time-1.4.0.1 ... linking ... done. > Loading package random-1.0.1.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package QuickCheck-2.6 ... linking ... done. > Loading package bytestring-0.10.0.2 ... linking ... done. > Loading package primitive-0.5.0.1 ... linking ... done. > Loading package vector-0.10.0.1 ... linking ... done. > Loading package repa-3.2.3.3 ... linking ... done. > *** Simplify: > *** CorePrep: > *** ByteCodeGen: > *** Desugar: > Result size of Desugar (after optimization) > = {terms: 900, types: 1,810, coercions: 340} > *** Simplifier: > Result size of Simplifier iteration=1 > = {terms: 834, types: 1,757, coercions: 567} > Result size of Simplifier iteration=2 > = {terms: 830, types: 1,721, coercions: 567} > Result size of Simplifier > = {terms: 830, types: 1,721, coercions: 567} > *** Specialise: > Result size of Specialise > = {terms: 830, types: 1,721, coercions: 567} > *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): > Result size of Float out(FOS {Lam = Just 0, > Consts = True, > PAPs = False}) > = {terms: 993, types: 2,131, coercions: 567} > *** Float inwards: > Result size of Float inwards > = {terms: 993, types: 2,131, coercions: 567} > *** Simplifier: > *** Deleting temp files: > Deleting: > /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s > Warning: deleting non-existent > /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s > *** Deleting temp dirs: > Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 > ghc: panic! (the 'impossible' happened) > (GHC version 7.6.3 for x86_64-apple-darwin): > Simplifier ticks exhausted > When trying RuleFired Class op szipWith > 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: 60402 > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: (Sent by chrisreade at mac.com ) Compiler giving up with simplifier ticks exhausted. Large amount of simplification may be going on to cause this. The problem goes away when using -fsimpl-tick-factor=1000 and the code runs. This is the session output without the flag (asking to have bug reported): chris$ ghc -O2 -rtsopts RedBlackStencilOpt.hs -v Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version 7.4.2 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d/package.cache Using binary package database: /Users/chris/.ghc/x86_64-darwin-7.6.3/package.conf.d/package.cache hiding package binary-0.5.1.1 to avoid conflict with later version binary-0.6.4.0 hiding package Cabal-1.16.0 to avoid conflict with later version Cabal-1.18.1.1 wired-in package ghc-prim mapped to ghc- prim-0.3.0.0-d5221a8c8a269b66ab9a07bdc23317dd wired-in package integer-gmp mapped to integer- gmp-0.5.0.0-2f15426f5b53fe4c6490832f9b20d8d7 wired-in package base mapped to base-4.6.0.1-6c351d70a24d3e96f315cba68f3acf57 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.8.0.0-c2c1b21dbbb37ace4b7dc26c966ec664 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *RedBlackStencilOpt.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2013-12-13 13:12:37 UTC ms_mod = main:RedBlackStencilOpt, ms_textual_imps = [import (implicit) Prelude, import Data.Array.Repa.Stencil.Dim2 as A, import Data.Array.Repa.Stencil as A, import Data.Array.Repa as A] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file RedBlackStencilOpt.hs Created temporary directory: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 *** Checking old interface for main:RedBlackStencilOpt: [1 of 1] Compiling RedBlackStencilOpt ( RedBlackStencilOpt.hs, RedBlackStencilOpt.o ) *** Parser: *** Renamer/typechecker: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. *** gcc: '/usr/bin/gcc' '-m64' '-fno-stack-protector' '-m64' '-L/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/base-4.6.0.1' '--print-file-name' 'libiconv.dylib' Loading package base ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package QuickCheck-2.6 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package primitive-0.5.0.1 ... linking ... done. Loading package vector-0.10.0.1 ... linking ... done. Loading package repa-3.2.3.3 ... linking ... done. *** Simplify: *** CorePrep: *** ByteCodeGen: *** Desugar: Result size of Desugar (after optimization) = {terms: 900, types: 1,810, coercions: 340} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 834, types: 1,757, coercions: 567} Result size of Simplifier iteration=2 = {terms: 830, types: 1,721, coercions: 567} Result size of Simplifier = {terms: 830, types: 1,721, coercions: 567} *** Specialise: Result size of Specialise = {terms: 830, types: 1,721, coercions: 567} *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 993, types: 2,131, coercions: 567} *** Float inwards: Result size of Float inwards = {terms: 993, types: 2,131, coercions: 567} *** Simplifier: *** Deleting temp files: Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s Warning: deleting non-existent /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s *** Deleting temp dirs: Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying RuleFired Class op szipWith 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: 60402 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Comment (by dominic): I can reproduce this in 7.9: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20140606 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $fNumInt_$c* 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: 73680 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 13:04:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 13:04:55 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.ade0bb25d72c80cadea32396dfe264b4@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by gzayas): Simon, documentation changed as requested. Please have a look and let me know. Thanks, Guido -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 13:26:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 13:26:07 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.e11f7614741db331bca18fa7cf843c00@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by gzayas): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 13:47:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 13:47:59 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.40eeb978b7999a2b7f51c465e59a0fe5@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): > As nomeata said in comment 16, we can simply ship our .so files in a private directory and make our dynamic programs search there (via RPATH or some other trick). Or via a ?private version number? ? it should be sufficient if they have a file name that?s different from any filename resulting from a separately packaged library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 13:48:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 13:48:18 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.5e3ace1c9a686b435a162f1bdcf7fc60@haskell.org> #9156: Duplicate record field ------------------------------------------------+-------------------------- Reporter: wojteknar | Owner: gintas Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: T9156 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by gintas): * status: new => patch Comment: OK, the failures do look like a fluke, although I'm not quite sure. Could someone take a look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 14:00:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 14:00:24 -0000 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> Message-ID: <066.f25b7cd2ceaf261dcf73b9af28f83a9a@haskell.org> #3085: warn about language extensions that are not used --------------------------+------------------------------------------------ Reporter: | Owner: PVerswyvelen | Status: new Type: | Milestone: 7.6.2 feature request | Version: 6.10.1 Priority: | Keywords: warnings extensions language normal | Architecture: Unknown/Multiple Component: | Difficulty: Unknown Compiler | Blocked By: Resolution: | Related Tickets: Operating System: | Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | --------------------------+------------------------------------------------ Changes (by asr): * cc: asr@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 14:04:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 14:04:21 -0000 Subject: [GHC] #9181: :browse GHC.TypeLits causes panic In-Reply-To: <046.8fd03c7f0662245eda394b5b6f7e1e4c@haskell.org> References: <046.8fd03c7f0662245eda394b5b6f7e1e4c@haskell.org> Message-ID: <061.d7242508126ca1fa9d5f19ce624d406d@haskell.org> #9181: :browse GHC.TypeLits causes panic -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: T9181 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 14:19:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 14:19:04 -0000 Subject: [GHC] #368: Provide a Java Backend In-Reply-To: <049.9a5162d2cca544679bf8d2366946a80b@haskell.org> References: <049.9a5162d2cca544679bf8d2366946a80b@haskell.org> Message-ID: <064.b0aee4427d145b6195ba951bf8e97dc9@haskell.org> #368: Provide a Java Backend ----------------------------+---------------------------------------------- Reporter: | Owner: rainbowang | Status: new Type: feature | Milestone: ? request | Version: None Priority: lowest | Keywords: Component: | Architecture: Unknown/Multiple Compiler | Difficulty: Project (more than a week) Resolution: None | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Changes (by nomeata): * priority: normal => lowest Comment: I believe this is a low priority bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 14:27:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 14:27:14 -0000 Subject: [GHC] #3283: Selective disabling of unused bind warnings In-Reply-To: <042.99c53619193c24de1883dd2c0ccb355d@haskell.org> References: <042.99c53619193c24de1883dd2c0ccb355d@haskell.org> Message-ID: <057.43f2c815972fbef92f80630cd5c37ab5@haskell.org> #3283: Selective disabling of unused bind warnings -------------------------------------+------------------------------------ Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #17 -------------------------------------+------------------------------------ Changes (by nomeata): * related: => #17 Comment: This might be a nice beginners tickets, but is it useful to people? No comment here for a long time... It seems to be related to #17. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 14:27:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 14:27:28 -0000 Subject: [GHC] #17: Separate warnings for unused local and top-level bindings In-Reply-To: <047.fe4cdb312b5d86f34d27df1115f2c91a@haskell.org> References: <047.fe4cdb312b5d86f34d27df1115f2c91a@haskell.org> Message-ID: <062.f7f37df601c2cad27d30c60b82484010@haskell.org> #17: Separate warnings for unused local and top-level bindings -----------------------------------+--------------------------------------- Reporter: magunter | Owner: Type: feature | Status: new request | Milestone: ? Priority: lowest | Version: None Component: Compiler | Keywords: -fwarn-unused-binds Resolution: None | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: None/Unknown | Related Tickets: #3283 Test Case: | Blocking: | -----------------------------------+--------------------------------------- Changes (by nomeata): * related: => #3283 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 14:32:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 14:32:00 -0000 Subject: [GHC] #5108: Allow unicode sub/superscript symbols in both identifiers and operators In-Reply-To: <057.b2c48f6dcee48c8d27365f9afce8a850@haskell.org> References: <057.b2c48f6dcee48c8d27365f9afce8a850@haskell.org> Message-ID: <072.02be61d5fe7caa0170723923cfbca31b@haskell.org> #5108: Allow unicode sub/superscript symbols in both identifiers and operators ---------------------------------------+----------------------------------- Reporter: mikhail.vorozhtsov | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.6.2 Component: Compiler (Parser) | Version: 7.1 Resolution: | Keywords: lexer unicode Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by nomeata): * status: new => infoneeded Comment: Mikhail, did you get a chance to raise this question in the community? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 14:44:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 14:44:50 -0000 Subject: [GHC] #7845: RebindableSyntax should allow rebinding tuples and lists In-Reply-To: <044.fad5588c0529af8796de587fbdf220c1@haskell.org> References: <044.fad5588c0529af8796de587fbdf220c1@haskell.org> Message-ID: <059.ce454ab3419f70267c7f9314c2167f31@haskell.org> #7845: RebindableSyntax should allow rebinding tuples and lists -------------------------------------+------------------------------------ Reporter: exbb2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * difficulty: => Unknown Comment: For lists, is enabled if you also enable the `OverloadedLists` langauge extension. (since GHC-7.8) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 15:00:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 15:00:39 -0000 Subject: [GHC] #8753: Import constructor but not the data type In-Reply-To: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> References: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> Message-ID: <066.4430e7899753ab578fe15d1bd9b86cd1@haskell.org> #8753: Import constructor but not the data type -------------------------------------+------------------------------------ Reporter: andreas.abel | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 15:09:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 15:09:13 -0000 Subject: [GHC] #9179: Documentation suggests to use '-hi-diffs' but it should be '-ddump-hi-diffs' In-Reply-To: <050.f0117dea6d928cd0e913b57370221cc6@haskell.org> References: <050.f0117dea6d928cd0e913b57370221cc6@haskell.org> Message-ID: <065.97713d60703ef9d0c113f4804fe39469@haskell.org> #9179: Documentation suggests to use '-hi-diffs' but it should be '-ddump-hi- diffs' --------------------------------------+------------------------------------ Reporter: shalehperry | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 15:11:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 15:11:49 -0000 Subject: [GHC] #9086: main :: IO Int does different things with runghc and when compiled In-Reply-To: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> References: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> Message-ID: <057.e3692f5f1c93938d25a267af59078368@haskell.org> #9086: main :: IO Int does different things with runghc and when compiled ------------------------------------------------+-------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by nomeata): Seems to be a left-over from how commands are handled in `GHCi`, where the result of an `IO` action is printed (if it has `Show` and is not `()`, it seems). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 15:52:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 15:52:53 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.7e5a0de2df22bc109b73d061f9eb9676@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:19 nomeata]: >> As nomeata said in comment 16, we can simply ship our .so files in a private directory and make our dynamic programs search there (via RPATH or some other trick). > Or via a ?private version number? ? it should be sufficient if they have a file name that?s different from any filename resulting from a separately packaged library. If the purpose of those DSO are actually not really shared, what about simply linking them statically so that no orphaned DSOs are left over? Is there any value in having DSOs that are used by only one executable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 16:03:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 16:03:56 -0000 Subject: [GHC] #4836: literate markdown not handled correctly by unlit In-Reply-To: <044.677d9d9819274dc3e0fccfc271c35be2@haskell.org> References: <044.677d9d9819274dc3e0fccfc271c35be2@haskell.org> Message-ID: <059.ffb33f0c230bea6c5bf976de34a2d547@haskell.org> #4836: literate markdown not handled correctly by unlit ----------------------------------------------+---------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7120 ----------------------------------------------+---------------------------- Comment (by elliottt): I've had success using this with octopress, with this page as an example: https://github.com/elliottt/elliottt.github.com/blob/source/source/_posts/2013-02-19 -serenade-in-haskell.markdown I used ```haskell as the starting block, so that github would highlight the haskell blocks, though ``` also works. Do you know if BlogLiterally will process the fenced code blocks? I know that pandoc is happy to process them, so I figured that it should just work with anything that depends on that. Additionally, bird tracks in markdown are for quoted blocks, not code, so if that's how BlogLiterally is expecting to find the code, that could be a problem. Does BlogLiterally process .lhs files? If so, that could also be a problem, as markdown processing requires the .md extension, instead of .lhs. The reason for this is that .lhs processing allows CPP macros, but in markdown the # means a section header. The different extension signals different flags to unlit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 16:45:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 16:45:01 -0000 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> Message-ID: <066.a7c6231933b0284d7d691cd6d5ed5220@haskell.org> #3085: warn about language extensions that are not used --------------------------+------------------------------------------------ Reporter: | Owner: PVerswyvelen | Status: new Type: | Milestone: 7.6.2 feature request | Version: 6.10.1 Priority: | Keywords: warnings extensions language normal | Architecture: Unknown/Multiple Component: | Difficulty: Unknown Compiler | Blocked By: Resolution: | Related Tickets: Operating System: | Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | --------------------------+------------------------------------------------ Comment (by asr): Replying to [comment:18 NeilMitchell]: > HLint 1.6.6 above above can warn on unused language extensions: http://community.haskell.org/~ndm/hlint > I used HLint 1.8.61 for removing unused language extensions from [http://wiki.portal.chalmers.se/agda/pmwiki.php Agda]. HLint made a great job. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 18:15:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 18:15:52 -0000 Subject: [GHC] #9182: Empty case analysis for function clauses Message-ID: <046.2b1b9f70625d24c57bb7f92b03a8aab4@haskell.org> #9182: Empty case analysis for function clauses ------------------------------------+------------------------------------- Reporter: dfranke | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Thanks to `-XEmptyCase`, the following is legal: {{{ module Empty where data Empty empty :: Empty -> a empty x = case x of { } }}} However, if I leave off the last line, GHC will complain that `The type signature for ?empty? lacks an accompanying binding`. I think this program should be accepted. It isn't that I'm not giving a definition for `empty`; it's that I'm defining it to be a function with no accompanying equations, as could be represented in Template Haskell by $(return [FunD (mkName "empty") []]) Currently, this too is rejected, with GHC complaining `Function binding for ?empty? has no equations`. I think this should be legal, with an empty list of clauses in a function definition being treated the same way as an empty list of matches in a case expression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 18:19:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 18:19:22 -0000 Subject: [GHC] #9182: Empty case analysis for function clauses In-Reply-To: <046.2b1b9f70625d24c57bb7f92b03a8aab4@haskell.org> References: <046.2b1b9f70625d24c57bb7f92b03a8aab4@haskell.org> Message-ID: <061.81bf5b01adefda11db34f71747bee806@haskell.org> #9182: Empty case analysis for function clauses -------------------------------------+------------------------------------ Reporter: dfranke | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by dfranke: Old description: > Thanks to `-XEmptyCase`, the following is legal: > > {{{ > module Empty where > > data Empty > > empty :: Empty -> a > empty x = case x of { } > }}} > > However, if I leave off the last line, GHC will complain that `The type > signature for ?empty? lacks an accompanying binding`. > > I think this program should be accepted. It isn't that I'm not giving a > definition for `empty`; it's that I'm defining it to be a function with > no accompanying equations, as could be represented in Template Haskell by > > $(return [FunD (mkName "empty") []]) > > Currently, this too is rejected, with GHC complaining `Function binding > for ?empty? has no equations`. I think this should be legal, with an > empty list of clauses in a function definition being treated the same way > as an empty list of matches in a case expression. New description: Thanks to `-XEmptyCase`, the following is legal: {{{ module Empty where data Empty empty :: Empty -> a empty x = case x of { } }}} However, if I leave off the last line, GHC will complain that `The type signature for ?empty? lacks an accompanying binding`. I think this program should be accepted. It isn't that I'm not giving a definition for `empty`; it's that I'm defining it to be a function with no accompanying equations, as could be represented in Template Haskell by {{{$(return [FunD (mkName "empty") []])}}} Currently, this too is rejected, with GHC complaining `Function binding for ?empty? has no equations`. I think this should be legal, with an empty list of clauses in a function definition being treated the same way as an empty list of matches in a case expression. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 19:20:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 19:20:26 -0000 Subject: [GHC] #8753: Import constructor but not the data type In-Reply-To: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> References: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> Message-ID: <066.592fbd9a6415bd153b4f7da979146dfe@haskell.org> #8753: Import constructor but not the data type -------------------------------------+------------------------------------ Reporter: andreas.abel | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Is this in the manual? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 19:32:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 19:32:22 -0000 Subject: [GHC] #9182: Empty case analysis for function clauses In-Reply-To: <046.2b1b9f70625d24c57bb7f92b03a8aab4@haskell.org> References: <046.2b1b9f70625d24c57bb7f92b03a8aab4@haskell.org> Message-ID: <061.4555168b16713e347cce5c95b9733467@haskell.org> #9182: Empty case analysis for function clauses -------------------------------------+------------------------------------ Reporter: dfranke | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Fuuzetsu): But empty does have one case, where `x = undefined`. You can't pattern match on it but it's there. I imagine that this is in attempt to simulate : ? ?. ? ? ? where we use the impossible pattern in empty but that's just not the case in Haskell and even in Agda &c the binding is necessary anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 20:40:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 20:40:05 -0000 Subject: [GHC] #5108: Allow unicode sub/superscript symbols in both identifiers and operators In-Reply-To: <057.b2c48f6dcee48c8d27365f9afce8a850@haskell.org> References: <057.b2c48f6dcee48c8d27365f9afce8a850@haskell.org> Message-ID: <072.d9376d4b082fd589dfe6f39a965a4030@haskell.org> #5108: Allow unicode sub/superscript symbols in both identifiers and operators ---------------------------------------+----------------------------------- Reporter: mikhail.vorozhtsov | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.6.2 Component: Compiler (Parser) | Version: 7.1 Resolution: | Keywords: lexer unicode Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by mikhail.vorozhtsov): Oh, completely forgot about this one. Sorry. I'll start a thread on the list next week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 21:47:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 21:47:39 -0000 Subject: [GHC] #8753: Import constructor but not the data type In-Reply-To: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> References: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> Message-ID: <066.1b047f23afef0b5cf59a4cf1cd6a2bf2@haskell.org> #8753: Import constructor but not the data type -------------------------------------+------------------------------------ Reporter: andreas.abel | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: closed => new * resolution: fixed => * component: Compiler => Documentation * type: feature request => task Comment: Doesn?t seem like it. http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html #pattern-synonyms mentions `pattern Foo` in export/import list, but does not say that proper constructors can also be addressed this way. I guess it should also be mentioned in http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html #explicit-namespaces Anywhere else where this should be mentioned? (Reopening as a task.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 21:50:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 21:50:47 -0000 Subject: [GHC] #9182: Empty case analysis for function clauses In-Reply-To: <046.2b1b9f70625d24c57bb7f92b03a8aab4@haskell.org> References: <046.2b1b9f70625d24c57bb7f92b03a8aab4@haskell.org> Message-ID: <061.36da689e22e950eaec8c7a712d4b0007@haskell.org> #9182: Empty case analysis for function clauses -------------------------------------+------------------------------------ Reporter: dfranke | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Tricky. I believe the `The type signature for ?empty? lacks an accompanying binding.` message is emitted early, possibly during renaming, when there is no way to know that `Empty` is empty. Or are you suggesting to disable this error message completely when `EmptyCase` is active? And what?s wrong with writing `empty x = case x of { }`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 7 22:03:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jun 2014 22:03:15 -0000 Subject: [GHC] #9182: Empty case analysis for function clauses In-Reply-To: <046.2b1b9f70625d24c57bb7f92b03a8aab4@haskell.org> References: <046.2b1b9f70625d24c57bb7f92b03a8aab4@haskell.org> Message-ID: <061.0467aa0199c8cc3c95e65e07e4bfa540@haskell.org> #9182: Empty case analysis for function clauses -------------------------------------+------------------------------------ Reporter: dfranke | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dfranke): Yes, with EmptyCase active I would take any type declaration without an accompanying binding as denoting an empty definition, and then issue a warning about an inexhaustive pattern match later on when appropriate. Having to write the empty case expression doesn't prevent you from doing anything. It just adds clutter, and allowing empty case analysis in some syntactic contexts but not others is an unnecessary inconsistency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 06:15:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 06:15:36 -0000 Subject: [GHC] #368: Provide a Java Backend In-Reply-To: <049.9a5162d2cca544679bf8d2366946a80b@haskell.org> References: <049.9a5162d2cca544679bf8d2366946a80b@haskell.org> Message-ID: <064.29e42b4a00a6eb78763a6b6c35b8aceb@haskell.org> #368: Provide a Java Backend ----------------------------+---------------------------------------------- Reporter: | Owner: rainbowang | Status: closed Type: feature | Milestone: ? request | Version: None Priority: lowest | Keywords: Component: | Architecture: Unknown/Multiple Compiler | Difficulty: Project (more than a week) Resolution: wontfix | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: None => wontfix Comment: Tickets like this don't really serve a useful purpose, closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 07:35:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 07:35:18 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.9d3d7df1a48330b85eee8dfa425d5024@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by slyfox): Replying to [comment:20 hvr]: > Replying to [comment:19 nomeata]: > >> As nomeata said in comment 16, we can simply ship our .so files in a private directory and make our dynamic programs search there (via RPATH or some other trick). > > Or via a ?private version number? ? it should be sufficient if they have a file name that?s different from any filename resulting from a separately packaged library. > If the purpose of those DSO are actually not really shared, what about simply linking them statically so that no orphaned DSOs are left over? Is there any value in having DSOs that are used by only one executable? (not very strong pro) Sometimes DSO linking is preferred (to reduce overall code size/exported amount of symbols) of a single module (as a workaround of host OS). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 07:55:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 07:55:46 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.b26837aa59a5a1ff559c60fac9977236@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: skeuchel Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): @skeuchel: Good work so far?. I think you can also do this for `dropWhile`. It?s true that `dropWhile` does not perform allocation on its own, but if you have `sum $ dropWhile (<100) [0..1000]`, there is value in fusing this: `dropWhile` needs to be a good consumer to avoid the allocations in the producer. And once that has been fused, the result is allocating, so `dropWhile` also should be a good producer. ? [private communication] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 07:57:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 07:57:27 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.058c5820241e09d0c687183641dc43d4@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by slyfox): Replying to [comment:17 errge]: > I've been asked to briefly summarize the issue, since simons didn't write too much about it in the ticket itself. > > GHC 7.8 uses the xhtml, terminfo and haskeline packages internally. Because of the dynamic ghci transition, the related .so files have to be shipped with the build. By not shipping the devel files (not making the cabal packages visible), we force the distribution vendors to package up these libraries separately and make them available in their repos. Nothing wrong with that of course (they do this for all the other important libraries, like lens and pipes too). The problem is that they can't ship the .so files in the respective packages, because it's usually not allowed for packages to overwrite each other's files in an adhoc manner. So when they build e.g. the xhtml deb or rpm package, they have to make sure that if the resulting .so files have the same name as the ghc shipped ones, then they don't include it in the package. These kind of workarounds seem extremely kludgy and fragile to me. This naming/overwrite issue causes some headaches for NixOS too, just in a slightly different setting. > > I see two solutions going forward. > > As nomeata said in comment 16, we can simply ship our .so files in a private directory and make our dynamic programs search there (via RPATH or some other trick). > > Or we can simply ship these packages with GHC as we ship base, time and so many others. juhpetersen posted a patch for that in comment 14. > > Alternatively, we can ignore it and just force people to go with the workarounds. I'd prefer not doing that. There were also some discussion on the mailing list about discontinuing the dynamic change after 7.10 and going back to static, which would of course make this go away. Thanks for the detailed explanation! ghc's xhtml is already a private lib. You can't accidentally use/link against it: {{{ /usr/lib64/ghc-7.8.2/xhtml-3000.2.1/libHSxhtml-3000.2.1-ghc7.8.2.so }}} On gentoo we just install external haskell libs in other location: {{{ /usr/lib64/xhtml-3000.2.1/ghc-7.8.2/libHSxhtml-3000.2.1-ghc7.8.2.so }}} and it's the package registered with cabal/seen with '''ghci -package xhtml'''. (As you see gentoo ships both .so files, allowing user to rebuild xhtml with any random ghc options out there). I see a problem in one single case: if you install haskell libs in ghc's private subdir. I'd strongly suggest against that practice and pick any other random dir out there. If we would support multiple ghc versions --prefix might be a /usr/$(libdir)/gentoo-ghc-7.8.2 Anyway, cabal can find them anywhere. Or i've misunderstood the clash problem completely? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 08:30:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 08:30:50 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.5c49b47731b44f862a3364ee43fd3aff@haskell.org> #9156: Duplicate record field ------------------------------------------------+-------------------------- Reporter: wojteknar | Owner: gintas Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: T9156 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by gintas): * cc: nomeata (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 08:33:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 08:33:50 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.d2d08350dd990810b9868fa297479fae@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: skeuchel Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Blaisorblade): @nomeata: while @skeuchel is the owner, I'm the OP. Thanks for explaining me why fusing `dropWhile` is important. Was your comment addressed at the branch I posted, or is there some other work from skeuchel? (I saw the [private communication] and didn't get it either). In case it is relevant, it seems to me harder to fuse dropWhile. Writing dropWhile as a fold is harder (technically, because it is not a catamorphism but a paramorphism). When the predicate fails, you want to return the rest of the list without processing it, but the original list is not available: dropWhileF p c n x xs = if p x then xs else I see that can be accomplished using, in essence, the reader monad: make the fold produce a function taking the list as extra argument. However, I understand that's often not a good idea, or even a non-starter, for performance. So, what's the way forward? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 08:43:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 08:43:37 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.749058e5b80f0881855241c1a4125e28@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: skeuchel Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): Yes, @skeuchel is here at ZuriHac and is working on this. He took your changes and did validating and nofib runs and other cleanup stuff. It just seems that he is just a little shy about talking about it here :-) You might be right about `dropWhile`. In that case, a `[Note]` in the code, explaining why we do not fuse `dropWhile`, would be helpful -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 08:59:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 08:59:52 -0000 Subject: [GHC] #4836: literate markdown not handled correctly by unlit In-Reply-To: <044.677d9d9819274dc3e0fccfc271c35be2@haskell.org> References: <044.677d9d9819274dc3e0fccfc271c35be2@haskell.org> Message-ID: <059.c85a0e083bacacaf0b281ac45d0d8da8@haskell.org> #4836: literate markdown not handled correctly by unlit ----------------------------------------------+---------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7120 ----------------------------------------------+---------------------------- Comment (by dominic): With your patches for markdown and a .md file {{{ ### Ok so lets try this again. ### A page that loads and compiles: ``` module Main where myfact 0 = 1 myfact n = n * n-1 main = putStrLn (show (myfact 5)) ``` Lets see if it works! [ghci] :!which ghc myfact 5 }}} this compiles so hurrah! But BlogLiteraly does '''not''' a) do syntax highlighting b) evaluate "myfact 5" {{{ ~/ghc $ BlogLiteratelyD --ghci TheLitTest.md

Ok so lets try this again.

A page that loads and compiles:

module Main where

 myfact 0 = 1
 myfact n = n * n-1

 main = putStrLn (show (myfact 5))

Lets see if it works!

ghci> :!which ghc
   /usr/local/bin/ghc

 ghci> myfact 5
}}} On the other hand with a .lhs file {{{ ### Ok so lets try this again. ### A page that loads and compiles: module Main where > myfact 0 = 1 > myfact n = n * n-1 > main = putStrLn (show (myfact 5)) Lets see if it works! [ghci] :!which ghc myfact 5 }}} This does not compile {{{ ~/ghc $ ./inplace/bin/ghc-stage2 TheLitTest.lhs TheLitTest.lhs:1:2: lexical error at character '#' }}} But BlogLiterately produces code which is syntax highlighted and evaluates "myfact 5". {{{ ~/ghc $ BlogLiteratelyD --ghci TheLitTest.lhs

Ok so lets try this again.

A page that loads and compiles:

module Main where

> myfact 0 = 1
 > myfact n = n * n-1
 
> main = putStrLn (show (myfact 5))

Lets see if it works!

ghci> :!which ghc
   /usr/local/bin/ghc

 ghci> myfact 5
   24
}}} I've discussed this ticket (not BlogLiterately) with Simon Marlow and we concluded that we should try changing the order of unlit and cpp. There may be literate programs which have e.g. #ifdef in their literate (non- code / not in chevrons) block and these will now fail but we concluded that this is the correct behaviour (I hope I am not misquoting Simon here). If this works then I think supporting .md files becomes more straightforward and BlogLiterately will work (and I will remove the workaround that Brent put in to make it handle # correctly when it calls ghci). Does that make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 09:26:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 09:26:22 -0000 Subject: [GHC] #9183: GHC shouldn't expand constraint synonyms Message-ID: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> #9183: GHC shouldn't expand constraint synonyms ------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ {-# LANGUAGE ConstraintKinds #-} type ShowX = Show showX :: ShowX a => a -> String showX = show }}} If I now ask for the type of showX, I get: {{{ *Main> :t showX showX :: Show a => a -> String }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 09:27:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 09:27:05 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.8ddc634bc6c5b4e27e47807f1b9d1ecf@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: skeuchel Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by skeuchel): Hi @Blaisorblade @nomeata, I took the changes from your branch and added a test case for this. However, it causes a 3.9% regression in terms of allocation of the rewrite test in nofib. This occurrence of takeWhile [https://github.com/ghc/nofib/blob/master/spectral/rewrite/Main.lhs#L193] is rewritten to takeWhileFB and then later written back without being fused. However, it seems to change the inline cost of string_of which will result that it will be inlined later and ultimately this results in losing sharing in one case. See this diff [http://lpaste.net/105275] of the output of the inliner/rewriter for some more details. You can clearly see the duplicated let bindings in the core output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 09:30:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 09:30:56 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.47f31277e5feec44b7abeeeb4563c180@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: skeuchel Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): Great analysis. I think the change can go in nevertheless. Optimization is hardly ever a win in all cases, and I think the regression is just a random knock-on- effect that could well have been an improvement. Also, it is not takeWhile specific, but rather a problem with the list-fusion setup in general. I?d say we can merge this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 09:34:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 09:34:36 -0000 Subject: [GHC] #8942: Duplicate symbol error when loading an archive twice In-Reply-To: <046.0073cee3c08e66b73b01434c442d5dd0@haskell.org> References: <046.0073cee3c08e66b73b01434c442d5dd0@haskell.org> Message-ID: <061.137b8bd9289da424384d48bd14493ed3@haskell.org> #8942: Duplicate symbol error when loading an archive twice -----------------------------------+------------------------------------ Reporter: gelisam | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: can't repro when `DYNAMIC_GHC_PROGRAMS=YES`, so we can't create a test; closing the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 09:35:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 09:35:46 -0000 Subject: [GHC] #9086: main :: IO Int does different things with runghc and when compiled In-Reply-To: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> References: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> Message-ID: <057.942c563ddf515a7f9be2c59c5aadf99e@haskell.org> #9086: main :: IO Int does different things with runghc and when compiled ------------------------------------------------+-------------------------- Reporter: nh2 | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by gintas): * owner: => gintas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 09:38:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 09:38:19 -0000 Subject: [GHC] #8939: Should check the return value of clock_gettime In-Reply-To: <043.a2c7af0ae4422e35397ef595bd0448d7@haskell.org> References: <043.a2c7af0ae4422e35397ef595bd0448d7@haskell.org> Message-ID: <058.f863a4bc4612e6fed6cea88425af804d@haskell.org> #8939: Should check the return value of clock_gettime -------------------------------+------------------------------------------- Reporter: uznx | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Already fixed in HEAD: ee1343712bb7854ef5b7180b1e600ac61be4ca13 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 09:39:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 09:39:35 -0000 Subject: [GHC] #8938: Should fallback instead of EXIT_FAILURE on clock_gettime failure In-Reply-To: <043.a14957746ae331f43904850115d79702@haskell.org> References: <043.a14957746ae331f43904850115d79702@haskell.org> Message-ID: <058.8a75642691d49a1cc38fe0f3cc3d66dd@haskell.org> #8938: Should fallback instead of EXIT_FAILURE on clock_gettime failure -------------------------------+------------------------------------------- Reporter: uznx | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by simonmar): * status: infoneeded => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 09:56:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 09:56:19 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.45c47f2cf1b5c796f1a259109f74c69c@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: skeuchel Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by skeuchel): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 10:03:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 10:03:11 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.75706899b7cfa03aa2840392cb3feb92@haskell.org> #9156: Duplicate record field ------------------------------------------------+-------------------------- Reporter: wojteknar | Owner: gintas Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: T9156 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by gintas): The 0002-Refactored-record-field-duplicate-code-to-use-nested.patch is broken, I accidentally uploaded a stale version. Sorry about that. Use 0002-fixed-refactor.patch instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 10:21:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 10:21:43 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.c550879697bb1f218e1f17ec0db07265@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Marlow ): In [changeset:"2f8b4c9330b455d4cb31c186c747a7db12a69251/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2f8b4c9330b455d4cb31c186c747a7db12a69251" Fix obscure problem with using the system linker (#8935) See Note [RTLD_LOCAL] for a summary of the problem and solution, and }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 10:21:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 10:21:43 -0000 Subject: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS In-Reply-To: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> References: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> Message-ID: <060.f605abb023ef9516df1f696577f0f210@haskell.org> #4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: ? Component: Runtime System | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Simon Marlow ): In [changeset:"9fd507e5758f4141ac2619f0db57136bcab035c6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9fd507e5758f4141ac2619f0db57136bcab035c6" Raise exceptions when blocked in bad FDs (fixes Trac #4934) Before the patch any call to 'select()' with 'bad_fd' led to: - unblocking of all threads - hiding exception for 'threadWaitRead bad_fd' The patch fixes both cases in this way: after 'select()' failure we iterate over each blocked descriptor and poll individually to see it's actual status, which is: - READY (move to run queue) - BLOCKED (leave in blocked queue) - INVALID (send an IOErrror exception) Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 10:21:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 10:21:44 -0000 Subject: [GHC] #8973: Fewer CPSZ: lines with -dshow-passes In-Reply-To: <046.f2d0f40d983e764406f283f1eadeeb66@haskell.org> References: <046.f2d0f40d983e764406f283f1eadeeb66@haskell.org> Message-ID: <061.3efb0bde7e0ee2f11e9e72cc4cb7bee0@haskell.org> #8973: Fewer CPSZ: lines with -dshow-passes -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonmar 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 | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Marlow ): In [changeset:"c0258176ad255ac42a68df75ac4287630a6c82c0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c0258176ad255ac42a68df75ac4287630a6c82c0" Don't use showPass in the backend (#8973) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 10:22:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 10:22:19 -0000 Subject: [GHC] #8973: Fewer CPSZ: lines with -dshow-passes In-Reply-To: <046.f2d0f40d983e764406f283f1eadeeb66@haskell.org> References: <046.f2d0f40d983e764406f283f1eadeeb66@haskell.org> Message-ID: <061.e2cf3a81f8fe7f1351961ba96c13a387@haskell.org> #8973: Fewer CPSZ: lines with -dshow-passes -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 10:23:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 10:23:50 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.da0d54f94aad15fc81d64058f10440e0@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: skeuchel Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): The patch you attached looks good to me. @Blaisorblade, what do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 10:25:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 10:25:26 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.81b61cae7750aac46783326af4472941@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * status: patch => merge Comment: Committed with a few changes and comments by me. I'm not sure whether the second patch is required, but I refactored that bit anyway. Please re- open if there's still a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 10:44:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 10:44:15 -0000 Subject: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS In-Reply-To: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> References: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> Message-ID: <060.866503290a8b2e1c1f3ebfa582da51df@haskell.org> #4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: ? Component: Runtime System | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonmar): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 13:37:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 13:37:21 -0000 Subject: [GHC] #95: GHCi :edit command should jump to the the last error In-Reply-To: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> References: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> Message-ID: <067.b61f4e48722ef7e396978a987dd605bb@haskell.org> #95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: martijnislief | Status: patch Type: feature | Milestone: ? request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: None | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by lortabac): * cc: hvr (added) * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 13:40:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 13:40:29 -0000 Subject: [GHC] #9086: main :: IO Int does different things with runghc and when compiled In-Reply-To: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> References: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> Message-ID: <057.28b13ecb2308e311e874bb62e085c7d8@haskell.org> #9086: main :: IO Int does different things with runghc and when compiled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gintas Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by gintas): * cc: nomeata (added) * difficulty: Unknown => Easy (less than 1 hour) * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 14:12:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 14:12:18 -0000 Subject: [GHC] #8226: Remove the old style -- # Haddock comments. In-Reply-To: <047.96b6209768296ad11c174e077e349059@haskell.org> References: <047.96b6209768296ad11c174e077e349059@haskell.org> Message-ID: <062.dbee1248fd61b1279c1a15426203c6fb@haskell.org> #8226: Remove the old style -- # Haddock comments. -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: adinapoli Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by adinapoli): * owner: => adinapoli -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 15:32:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 15:32:42 -0000 Subject: [GHC] #8825: ghc can't determine gcc version on ru_RU locale In-Reply-To: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> References: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> Message-ID: <060.b58990d32aca96496821298e92dc61dd@haskell.org> #8825: ghc can't determine gcc version on ru_RU locale -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by slyfox): For current gcc-git things are quite scary: {{{ ~/dev/git/gcc/gcc/po:git grep -A1 'gcc version %s %s' | grep 'po-' | grep -v 'gcc version' be.po-msgstr "?????? gcc %s\n" da.po-msgstr "GCC version %s\n" de.po-msgstr "gcc-Version %s %s\n" el.po-msgstr "?????? gcc %s\n" es.po-msgstr "gcc versi?n %s %s\n" fi.po-msgstr "gcc-versio %s %s\n" fr.po-msgstr "version gcc %s\n" hr.po-msgstr "gcc ina?ica %s %s\n" id.po-msgstr "versi gcc %s %s\n" ja.po-msgstr "gcc ????? %s %s\n" nl.po-msgstr "gcc versie %s %s\n" ru.po-msgstr "gcc ?????? %s %s\n" sr.po-msgstr "gcc ??????? %s\n" sv.po- tr.po-msgstr "gcc %s s?r?m?\n" vi.po-msgstr "gcc phi?n b?n %s %s\n" zh_CN.po-msgstr "gcc ?? %s %s\n" zh_TW.po-msgstr "gcc ?? %s %s\n" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 16:18:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 16:18:00 -0000 Subject: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS In-Reply-To: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> References: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> Message-ID: <060.3ebb07807cc9156258f5d599f1f99526@haskell.org> #4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by hvr): * milestone: ? => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 16:19:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 16:19:06 -0000 Subject: [GHC] #8939: Should check the return value of clock_gettime In-Reply-To: <043.a2c7af0ae4422e35397ef595bd0448d7@haskell.org> References: <043.a2c7af0ae4422e35397ef595bd0448d7@haskell.org> Message-ID: <058.053b32bc2731d52295131609d4143d6e@haskell.org> #8939: Should check the return value of clock_gettime -------------------------------+------------------------------------------- Reporter: uznx | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by hvr): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 16:22:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 16:22:47 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.fe2dc4a1601ddbe7ad30ae0424176c2c@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: skeuchel Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Blaisorblade): Thanks for taking care of this! The performance changes make sense to me, especially to fft2 which does use takeWhile. (I saw them on one OS X desktop, which however seemed to like suspending and had more stable timing; I didn't see them on a Linux machine which was otherwise more stable). On the regression, I agree it seems accidental. I'm confused that s1 and s2 are not joined by CSE. Delite/LMS, for instance, uses hash consing to prevent such programs from being formed in memory (the second definition is in a nested scope, but it seems this should not be a problem here). But I guess CSE in GHC would break programs using IO after the definition of IO is inlined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 16:36:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 16:36:18 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC Message-ID: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------------+------------------------------- Reporter: aspidites | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: python | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- According to the [https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows wiki], it is preferred that a user have Python 2.7 installed before attempting to build GHC. As I'm on Arch Linux the default Python version is 3.4. As such, rather than simply changing the shebang line to explicitly ask for version 2, I made it so that the scripts all use syntax that works properly for versions 2.7 to 3.4. I don't think I've used anything that disallows 2.6, but don't have that version available to check against. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 16:39:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 16:39:16 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.64b10cc347455c1cb62758042b19add2@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------+------------------------------------------- Reporter: aspidites | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Description changed by aspidites: Old description: > According to the > [https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > wiki], it is preferred that a user have Python 2.7 installed before > attempting to build GHC. As I'm on Arch Linux the default Python version > is 3.4. As such, rather than simply changing the shebang line to > explicitly ask for version 2, I made it so that the scripts all use > syntax that works properly for versions 2.7 to 3.4. I don't think I've > used anything that disallows 2.6, but don't have that version available > to check against. New description: According to the [https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows wiki], it is preferred that a user have Python 2.7 installed before attempting to build GHC. As I'm on Arch Linux the default Python version is 3.4. As such, rather than simply changing the shebang line to explicitly ask for version 2, I made it so that the scripts all use syntax that works properly for versions 2.7 to 3.4. I don't think I've used anything that disallows 2.6, but don't have that version available to check against. I should note that the changes were as minimal as possible. That is, I didn't bother refactoring to use more modern idioms (such as string substitution vs concatenation). As these are helper scripts, I doubt doing so would be much help, but I wouldn't mind doing so upon request. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 20:14:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 20:14:13 -0000 Subject: [GHC] #9086: main :: IO Int does different things with runghc and when compiled In-Reply-To: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> References: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> Message-ID: <057.c2bd89bb6bba52b4932953da858f95f0@haskell.org> #9086: main :: IO Int does different things with runghc and when compiled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gintas Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): Thanks for the patch! It is common to comment when you change the status of the ticket, something like ?I worked on this and here is the result. From my point of view, it is good to go. Can someone review and push it? and possibly more (e.g. whether it was hard or easy, whether you like the result or not). A simple status change may be overlooked. Besides that, the patch (which has a sufficient comment and a test case) looks good from my pov. Unless someone complains I?ll push it soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 21:18:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 21:18:43 -0000 Subject: [GHC] #95: GHCi :edit command should jump to the the last error In-Reply-To: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> References: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> Message-ID: <067.40401723bb3a0cc52b135b17ad22512c@haskell.org> #95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: martijnislief | Status: patch Type: feature | Milestone: ? request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: None | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by nomeata): Hi lortabac. Thanks for your patch. One thing that is definitely missing is documentation: You should explain this behaviour in the user manual for `:edit`. I would name the field `errors` a bit more self-descriptive. Maybe `lastErrorLocations`? Why do you need `unsafeCoerce`? Can?t you create the `IORef` locally when initializing `GHCiState`, in `interactiveUI`, and also pass it as a first parameter to your `ghciLogAction`? Your `filter` could be more readable a `find` (from `Data.List`). That?s it for now :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 8 21:18:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jun 2014 21:18:56 -0000 Subject: [GHC] #95: GHCi :edit command should jump to the the last error In-Reply-To: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> References: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> Message-ID: <067.f3e2c27b7e38d5f0d8017372e3f01093@haskell.org> #95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: lortabac martijnislief | Status: patch Type: feature | Milestone: ? request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: None | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by nomeata): * owner: => lortabac -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 00:34:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 00:34:37 -0000 Subject: [GHC] #8753: Import constructor but not the data type In-Reply-To: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> References: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> Message-ID: <066.1d06ae22900c2d59cab38097b31c9944@haskell.org> #8753: Import constructor but not the data type -------------------------------------+------------------------------------ Reporter: andreas.abel | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): That looks sufficient to me... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 06:46:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 06:46:32 -0000 Subject: [GHC] #9185: glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknowns archs Message-ID: <050.ec9d0ec38ab57c70c2fd6acc66f09adc@haskell.org> #9185: glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknowns archs -------------------------+------------------------------------------------- Reporter: | Owner: juhpetersen | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Linux Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Stg.h defines _BSD_SOURCE which glibc 2.20 deprecates with warnings in favour of _DEFAULT_SOURCE. Since the verbose warning is output for every ghc invocation when building it is rather annoying and induces testsuite failures. The warning look like this: {{{ In file included from /usr/include/math.h:26:0: 0, from /usr/lib64/ghc-7.6.3/include/Stg.h:65, from /tmp/ghc783_0/ghc783_0.hc:3: /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" ^ }}} Solution/workaround is to define "_DEFAULT_SOURCE" and that works. I asked in https://bugzilla.redhat.com/show_bug.cgi?id=1067110#c13 about how best to fix Stg.h and got the answer to just add _DEFAULT_SOURCE. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 06:52:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 06:52:30 -0000 Subject: [GHC] #9185: glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknowns archs In-Reply-To: <050.ec9d0ec38ab57c70c2fd6acc66f09adc@haskell.org> References: <050.ec9d0ec38ab57c70c2fd6acc66f09adc@haskell.org> Message-ID: <065.d63d292272b07e79d5459a12dc100ced@haskell.org> #9185: glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknowns archs -------------------------------------------------+------------------------- Reporter: juhpetersen | Owner: Type: bug | juhpetersen Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: 7.8.2 Operating System: Linux | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by juhpetersen): * owner: => juhpetersen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 07:50:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 07:50:49 -0000 Subject: [GHC] #9180: New magic function `staticError` In-Reply-To: <046.f02a1097d6c172420c24668297fdcea7@haskell.org> References: <046.f02a1097d6c172420c24668297fdcea7@haskell.org> Message-ID: <061.2c5b36ff55327ed571b77fb8a80e2737@haskell.org> #9180: New magic function `staticError` -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I'd be happy with something like this, provided * It's reported by Lint * It has runtime behaviour too (in case you don't run Lint) Of course I could be wrong about this, but making it another Lint check seems right to me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 07:54:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 07:54:29 -0000 Subject: [GHC] #8613: simplifier ticks exhausted In-Reply-To: <044.3c96d4abc261f1969033a0de42af80e6@haskell.org> References: <044.3c96d4abc261f1969033a0de42af80e6@haskell.org> Message-ID: <059.6754d58ee65df1bf5f9d50acce7771d3@haskell.org> #8613: simplifier ticks exhausted -----------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Description changed by simonpj: Old description: > (Sent by chrisreade at mac.com ) > Compiler giving up with simplifier ticks exhausted. > Large amount of simplification may be going on to cause this. > The problem goes away when using -fsimpl-tick-factor=1000 and the code > runs. > This is the session output without the flag (asking to have bug > reported): > > chris$ ghc -O2 -rtsopts RedBlackStencilOpt.hs -v > Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version > 7.4.2 > Using binary package database: > /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d/package.cache > Using binary package database: > /Users/chris/.ghc/x86_64-darwin-7.6.3/package.conf.d/package.cache > hiding package binary-0.5.1.1 to avoid conflict with later version > binary-0.6.4.0 > hiding package Cabal-1.16.0 to avoid conflict with later version > Cabal-1.18.1.1 > wired-in package ghc-prim mapped to ghc- > prim-0.3.0.0-d5221a8c8a269b66ab9a07bdc23317dd > wired-in package integer-gmp mapped to integer- > gmp-0.5.0.0-2f15426f5b53fe4c6490832f9b20d8d7 > wired-in package base mapped to > base-4.6.0.1-6c351d70a24d3e96f315cba68f3acf57 > wired-in package rts mapped to builtin_rts > wired-in package template-haskell mapped to template- > haskell-2.8.0.0-c2c1b21dbbb37ace4b7dc26c966ec664 > wired-in package dph-seq not found. > wired-in package dph-par not found. > Hsc static flags: -static > *** Chasing dependencies: > Chasing modules from: *RedBlackStencilOpt.hs > Stable obj: [] > Stable BCO: [] > Ready for upsweep > [NONREC > ModSummary { > ms_hs_date = 2013-12-13 13:12:37 UTC > ms_mod = main:RedBlackStencilOpt, > ms_textual_imps = [import (implicit) Prelude, > import Data.Array.Repa.Stencil.Dim2 as A, > import Data.Array.Repa.Stencil as A, import > Data.Array.Repa as A] > ms_srcimps = [] > }] > *** Deleting temp files: > Deleting: > compile: input file RedBlackStencilOpt.hs > Created temporary directory: > /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 > *** Checking old interface for main:RedBlackStencilOpt: > [1 of 1] Compiling RedBlackStencilOpt ( RedBlackStencilOpt.hs, > RedBlackStencilOpt.o ) > *** Parser: > *** Renamer/typechecker: > *** Simplify: > *** CorePrep: > *** ByteCodeGen: > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > *** gcc: > '/usr/bin/gcc' '-m64' '-fno-stack-protector' '-m64' > '-L/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/base-4.6.0.1' > '--print-file-name' 'libiconv.dylib' > Loading package base ... linking ... done. > Loading package pretty-1.1.1.0 ... linking ... done. > Loading package array-0.4.0.1 ... linking ... done. > Loading package deepseq-1.3.0.1 ... linking ... done. > Loading package containers-0.5.0.0 ... linking ... done. > Loading package old-locale-1.0.0.5 ... linking ... done. > Loading package time-1.4.0.1 ... linking ... done. > Loading package random-1.0.1.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package QuickCheck-2.6 ... linking ... done. > Loading package bytestring-0.10.0.2 ... linking ... done. > Loading package primitive-0.5.0.1 ... linking ... done. > Loading package vector-0.10.0.1 ... linking ... done. > Loading package repa-3.2.3.3 ... linking ... done. > *** Simplify: > *** CorePrep: > *** ByteCodeGen: > *** Desugar: > Result size of Desugar (after optimization) > = {terms: 900, types: 1,810, coercions: 340} > *** Simplifier: > Result size of Simplifier iteration=1 > = {terms: 834, types: 1,757, coercions: 567} > Result size of Simplifier iteration=2 > = {terms: 830, types: 1,721, coercions: 567} > Result size of Simplifier > = {terms: 830, types: 1,721, coercions: 567} > *** Specialise: > Result size of Specialise > = {terms: 830, types: 1,721, coercions: 567} > *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): > Result size of Float out(FOS {Lam = Just 0, > Consts = True, > PAPs = False}) > = {terms: 993, types: 2,131, coercions: 567} > *** Float inwards: > Result size of Float inwards > = {terms: 993, types: 2,131, coercions: 567} > *** Simplifier: > *** Deleting temp files: > Deleting: > /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s > Warning: deleting non-existent > /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s > *** Deleting temp dirs: > Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 > ghc: panic! (the 'impossible' happened) > (GHC version 7.6.3 for x86_64-apple-darwin): > Simplifier ticks exhausted > When trying RuleFired Class op szipWith > 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: 60402 > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: (Sent by chrisreade at mac.com ) Compiler giving up with simplifier ticks exhausted. Large amount of simplification may be going on to cause this. The problem goes away when using -fsimpl-tick-factor=1000 and the code runs. This is the session output without the flag (asking to have bug reported): {{{ chris$ ghc -O2 -rtsopts RedBlackStencilOpt.hs -v Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version 7.4.2 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d/package.cache Using binary package database: /Users/chris/.ghc/x86_64-darwin-7.6.3/package.conf.d/package.cache hiding package binary-0.5.1.1 to avoid conflict with later version binary-0.6.4.0 hiding package Cabal-1.16.0 to avoid conflict with later version Cabal-1.18.1.1 wired-in package ghc-prim mapped to ghc- prim-0.3.0.0-d5221a8c8a269b66ab9a07bdc23317dd wired-in package integer-gmp mapped to integer- gmp-0.5.0.0-2f15426f5b53fe4c6490832f9b20d8d7 wired-in package base mapped to base-4.6.0.1-6c351d70a24d3e96f315cba68f3acf57 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.8.0.0-c2c1b21dbbb37ace4b7dc26c966ec664 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *RedBlackStencilOpt.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2013-12-13 13:12:37 UTC ms_mod = main:RedBlackStencilOpt, ms_textual_imps = [import (implicit) Prelude, import Data.Array.Repa.Stencil.Dim2 as A, import Data.Array.Repa.Stencil as A, import Data.Array.Repa as A] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file RedBlackStencilOpt.hs Created temporary directory: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 *** Checking old interface for main:RedBlackStencilOpt: [1 of 1] Compiling RedBlackStencilOpt ( RedBlackStencilOpt.hs, RedBlackStencilOpt.o ) *** Parser: *** Renamer/typechecker: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. *** gcc: '/usr/bin/gcc' '-m64' '-fno-stack-protector' '-m64' '-L/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/base-4.6.0.1' '--print-file-name' 'libiconv.dylib' Loading package base ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package QuickCheck-2.6 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package primitive-0.5.0.1 ... linking ... done. Loading package vector-0.10.0.1 ... linking ... done. Loading package repa-3.2.3.3 ... linking ... done. *** Simplify: *** CorePrep: *** ByteCodeGen: *** Desugar: Result size of Desugar (after optimization) = {terms: 900, types: 1,810, coercions: 340} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 834, types: 1,757, coercions: 567} Result size of Simplifier iteration=2 = {terms: 830, types: 1,721, coercions: 567} Result size of Simplifier = {terms: 830, types: 1,721, coercions: 567} *** Specialise: Result size of Specialise = {terms: 830, types: 1,721, coercions: 567} *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 993, types: 2,131, coercions: 567} *** Float inwards: Result size of Float inwards = {terms: 993, types: 2,131, coercions: 567} *** Simplifier: *** Deleting temp files: Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s Warning: deleting non-existent /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s *** Deleting temp dirs: Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying RuleFired Class op szipWith 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: 60402 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 Jun 9 08:39:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 08:39:50 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.1d5db506f62fdd69b02710e9b3974562@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: skeuchel Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonpj): Good work. * Could someone post the nofib results? * Like Blaisorblade I don't understand why CSE doesn't catch the duplicate redex. Can someone post the result of `-dverbose-core2core -ddump-inlinings`? Microsoft's network won't me see the hpaste/lpaste site at the moment (investigating) so I can't see anything you post there at the moment. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 12:00:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 12:00:08 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.a19267a95f47a04d409ae5505ae7ee06@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by jstolarek): I did some more reading and I finally understand Ross' answers :-) Section 3.2 of John Hughes' "Programming with Arrows" was really helpful in understanding the idea of the stack. But I don't yet understand the implementation and I still have problems reading the comments. I figured a good way of improving my understanding will be implementing a prototype solution outlined in [ticket:7828#comment:9 comment 9]. I wanted to begin by implementing it only for selected language constructs and I got stuck on typechecking !BindStmt in !TcMatches. Currently there is only the monadic !BindStmt. In my prototype I want to distinguish between the monadic and arrow !BindStmt. This means I need to write typechecking for the latter (in !TcMatches). I'm not sure how to do that as I don't know what is the type signature for arrow bind. I tried to deduce that based on the comments in !DsArrows, but I'm not sure if this is a correct approach. Can I once again ask for help in reading the comments? {{{ -- D; xs1 |-a c : () --> t -- D; xs' |-a do { ss } : t' xs2 = xs' - defs(p) -- ----------------------------------- -- D; xs |-a do { p <- c; ss } : t' -- -- ---> premap (\ (xs) -> (((xs1),()),(xs2))) -- (first c >>> arr (\ (p, (xs2)) -> (xs'))) >>> ss }}} I'm totally confused by `(\ (xs) -> (((xs1),()),(xs2)))`. Where do `xs1` and `xs2` come from, if we only bind `xs` as the input to `do { p <- c; ss }`? Also, do I understand correctly that bind expression generated in desugaring of arrow do-notation does not have a source-level equivalent? If so is it even correct to represent it using the !BindStmt constructor? In my prototype I'm ignoring Ross' proposal of the new desugaring. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 12:07:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 12:07:36 -0000 Subject: [GHC] #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) In-Reply-To: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> References: <045.9c2a676dd820e1dff3d2e442d533f7ca@haskell.org> Message-ID: <060.ba3c6d719cbca79193f39acbdaccb783@haskell.org> #9155: O2: allocateRegsAndSpill: Cannot read from uninitialized register %vI_s154O (GHC version 7.8.2 for x86_64-unknown-linux) ---------------------------------------+---------------------------------- Reporter: slyfox | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.3 Component: Compiler (NCG) | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 12:07:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 12:07:40 -0000 Subject: [GHC] #9080: GHC error on Win 8.1 64bit In-Reply-To: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> References: <043.c0aa3d5bf848f70ddef90000b43fffd8@haskell.org> Message-ID: <058.855c196d9f0727028a432d6586f771d8@haskell.org> #9080: GHC error on Win 8.1 64bit ---------------------------------------+---------------------------------- Reporter: maun | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 12:07:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 12:07:47 -0000 Subject: [GHC] #9050: Panic when compiling cmm file together with -outputdir In-Reply-To: <044.0c851e057b25561ca3c3a92b801901b3@haskell.org> References: <044.0c851e057b25561ca3c3a92b801901b3@haskell.org> Message-ID: <059.d469f21adb6044c0cea0a9025275b2ce@haskell.org> #9050: Panic when compiling cmm file together with -outputdir ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 12:07:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 12:07:52 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.9c5aba0677a64860cb46672d30cecdde@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 12:07:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 12:07:59 -0000 Subject: [GHC] #7241: GHC-7.6.1 panics on template haskell code In-Reply-To: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> References: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> Message-ID: <061.83b31929d28e4b6dcdf76f75ab81b01e@haskell.org> #7241: GHC-7.6.1 panics on template haskell code ---------------------------------------+----------------------------------- Reporter: akamaus | Owner: Yuras Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 12:08:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 12:08:28 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.5c54484856442908bb4ea749ca1698f4@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 12:29:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 12:29:16 -0000 Subject: [GHC] Batch modify: #7651, #7919, #8974, #9007, #7028, #7475, #7655, #8975, #5987, #7298, #7411, #7478, #7521, #7567, #7602, #8228, #8736, #8819, #8960, #9012, #3658, #5757, #7143, #7305, #7665, #7695, #8362, #8849, #8951, #8976, #8981, #9003, #9034, #9046, #9100, #8303 Message-ID: <20140609122916.1B7A92406B@ghc.haskell.org> Batch modification to #7651, #7919, #8974, #9007, #7028, #7475, #7655, #8975, #5987, #7298, #7411, #7478, #7521, #7567, #7602, #8228, #8736, #8819, #8960, #9012, #3658, #5757, #7143, #7305, #7665, #7695, #8362, #8849, #8951, #8976, #8981, #9003, #9034, #9046, #9100, #8303 by thoughtpolice: milestone to 7.8.4 Comment: Moving to 7.8.4. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 12:33:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 12:33:03 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.e1cf3745ed3419c495f904d335430ee4@haskell.org> #9023: Error when using empty record update on binary pattern synonym ------------------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Test Case: patsyn/should_compile/T9023 | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by thoughtpolice): I had a merge conflict while merging this - looking into it... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:01:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:01:34 -0000 Subject: [GHC] #9167: Associated type is accepted even without mentioning class parameters In-Reply-To: <047.2d5de3ba88af5354277dc53a66fecc69@haskell.org> References: <047.2d5de3ba88af5354277dc53a66fecc69@haskell.org> Message-ID: <062.7704ad9a136c37e10f14cd6c09315f88@haskell.org> #9167: Associated type is accepted even without mentioning class parameters -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"66bddbb27fd9c383f85005b8c6e1961d25d7a7dd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="66bddbb27fd9c383f85005b8c6e1961d25d7a7dd" Check that an associated type mentions at least one type variable from the class Fixes Trac #9167 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:01:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:01:34 -0000 Subject: [GHC] #9166: Missing documentation for the -fwarn-inline-rule-shadowing warning In-Reply-To: <042.6f4a914d89b764cde200d92eb3de3c17@haskell.org> References: <042.6f4a914d89b764cde200d92eb3de3c17@haskell.org> Message-ID: <057.5e83e8ea96912c187a133373627d3381@haskell.org> #9166: Missing documentation for the -fwarn-inline-rule-shadowing warning -------------------------------------+------------------------------------ Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"52509d8f07f64c95ff4f6090755f51992c501d0c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="52509d8f07f64c95ff4f6090755f51992c501d0c" Document -fwarn-inline-rule-shadowing (Trac #9166) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:01:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:01:34 -0000 Subject: [GHC] #8753: Import constructor but not the data type In-Reply-To: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> References: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> Message-ID: <066.d4c3f6a7acd46e779047e82916ad9622@haskell.org> #8753: Import constructor but not the data type -------------------------------------+------------------------------------ Reporter: andreas.abel | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"59cdb992df5bd8bdc563b30c2103c323a7d57f15/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="59cdb992df5bd8bdc563b30c2103c323a7d57f15" Document explicit import/export of data constructors (Trac #8753) I also added sub-sections to the pattern synonym documentation }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:08:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:08:02 -0000 Subject: [GHC] #9171: Clarify error messages when there is a kind mismatch In-Reply-To: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> References: <050.ab34299b8caf40d88d3e22f1280a77b0@haskell.org> Message-ID: <065.d5df8b1c59298d25b922c92f1ffce855@haskell.org> #9171: Clarify error messages when there is a kind mismatch ----------------------------------------------+---------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4b4d81a6b97555a8dbeda2e6387ee151af962473/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4b4d81a6b97555a8dbeda2e6387ee151af962473" Suggest -fprint-explicit-kinds when only kind variables are ambiguous This was triggered by looking at Trac #9171. See Note [Suggest -fprint-explicit-kinds] in TcErrors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:08:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:08:28 -0000 Subject: [GHC] #9166: Missing documentation for the -fwarn-inline-rule-shadowing warning In-Reply-To: <042.6f4a914d89b764cde200d92eb3de3c17@haskell.org> References: <042.6f4a914d89b764cde200d92eb3de3c17@haskell.org> Message-ID: <057.3d6bc6e542f3b1da38252aa30494f375@haskell.org> #9166: Missing documentation for the -fwarn-inline-rule-shadowing warning -------------------------------------+------------------------------------ Reporter: asr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Good point. Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:08:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:08:44 -0000 Subject: [GHC] #8753: Import constructor but not the data type In-Reply-To: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> References: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> Message-ID: <066.5a4913bba203b8833d550333562a1972@haskell.org> #8753: Import constructor but not the data type -------------------------------------+------------------------------------ Reporter: andreas.abel | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Good idea, done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:09:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:09:40 -0000 Subject: [GHC] #9167: Associated type is accepted even without mentioning class parameters In-Reply-To: <047.2d5de3ba88af5354277dc53a66fecc69@haskell.org> References: <047.2d5de3ba88af5354277dc53a66fecc69@haskell.org> Message-ID: <062.f6994b02247b7fbe3cf87f709d24885e@haskell.org> #9167: Associated type is accepted even without mentioning class parameters -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: low | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple indexed_types/should_fail/T9167 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed_types/should_fail/T9167 * resolution: => fixed Comment: Good point. Done. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:10:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:10:42 -0000 Subject: [GHC] #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` In-Reply-To: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> References: <045.d73e4d82c0360b056c656eb47667cabb@haskell.org> Message-ID: <060.208540991a1890b276b4703a0b338043@haskell.org> #9127: Don't warn about pattern-bindings of the form `let !_ = rhs` -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: patch => closed * resolution: => fixed Comment: Thank you. I edited a bit more and committed {{{ commit aa18a46d85a4995f0daea63d44e627f11d03ce95 Author: Simon Peyton Jones Date: Mon Jun 9 13:58:23 2014 +0100 Improve documentation for -fwarn-unused-binds }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:12:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:12:54 -0000 Subject: [GHC] #9178: improve orphan instance warning In-Reply-To: <043.fcde19f8eb765ccd6976e8ca3285d142@haskell.org> References: <043.fcde19f8eb765ccd6976e8ca3285d142@haskell.org> Message-ID: <058.90cecb79fee96b8b484968e5a7092eb1@haskell.org> #9178: improve orphan instance warning -------------------------------------+------------------------------------ Reporter: fphh | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): OK with me. Do others like the new error message? It's a user matter not an implementation matter. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:15:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:15:20 -0000 Subject: [GHC] #9178: improve orphan instance warning In-Reply-To: <043.fcde19f8eb765ccd6976e8ca3285d142@haskell.org> References: <043.fcde19f8eb765ccd6976e8ca3285d142@haskell.org> Message-ID: <058.0ab3d35ab903128f15f3c50379f93a8d@haskell.org> #9178: improve orphan instance warning -------------------------------------+------------------------------------ Reporter: fphh | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"877a9577280f4b6aa6ef47f7a27d9b741b8234cf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="877a9577280f4b6aa6ef47f7a27d9b741b8234cf" Better warning message for orphan instances (Ticket #9178) Including a test case. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:16:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:16:07 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.72d3699f9772b139615c8dbac966250b@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9164 -------------------------------------+------------------------------------ Comment (by simonpj): OK so * I think we have consensus that `Ptr` should have phantom role. Joachim, could you push that through? * Am am not sure what the story is on `FunPtr`. Maybe it doesn't matter for now; but if we leave it as it is, could we add a comment to the role signature saying that it's a conservative choice, and pointing to this ticket? It'd be nice to get this done and closed. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:16:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:16:41 -0000 Subject: [GHC] #9178: improve orphan instance warning In-Reply-To: <043.fcde19f8eb765ccd6976e8ca3285d142@haskell.org> References: <043.fcde19f8eb765ccd6976e8ca3285d142@haskell.org> Message-ID: <058.240a4b90e7ada8c3a64435a88b9c848a@haskell.org> #9178: improve orphan instance warning -------------------------------------+------------------------------------ Reporter: fphh | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: Also ok with me. That makes two of us, so I pushed it. Nevertheless: If someone wants to improve it, feel free to do so. Congrats, Heinrich, for your first contribution to GHC, I hope there will be more! :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:19:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:19:35 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.08c7f95e072742e388a1dac3afa0b34b@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"4caadb7cbee5c176abb99df25c4cc1657ae57f40/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4caadb7cbee5c176abb99df25c4cc1657ae57f40" Ship xhtml, terminfo, haskeline (#8919) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:20:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:20:19 -0000 Subject: [GHC] #9128: Possible bug in strictness analyzer when where clause declared NOINLINE In-Reply-To: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> References: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> Message-ID: <060.7b8f57577416b8a0c3f578e97dc6f09d@haskell.org> #9128: Possible bug in strictness analyzer when where clause declared NOINLINE ---------------------------------+----------------------------------------- Reporter: aalevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strictness bytestring Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | ---------------------------------+----------------------------------------- Comment (by simonpj): I would love a smaller test case. I'm currently stalled thus {{{ cabal install --with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc- stage2 Resolving dependencies... [1 of 1] Compiling Main ( /tmp/postgresql-libpq-0.9.0.1-63567 /postgresql-libpq-0.9.0.1/dist/setup/setup.hs, /tmp/postgresql- libpq-0.9.0.1-63567/postgresql-libpq-0.9.0.1/dist/setup/Main.o ) Linking /tmp/postgresql-libpq-0.9.0.1-63567/postgresql- libpq-0.9.0.1/dist/setup/setup ... Configuring postgresql-libpq-0.9.0.1... setup: The program 'pg_config' is required but it could not be found. Failed to install postgresql-libpq-0.9.0.1 cabal: Error: some packages failed to install: postgresql-libpq-0.9.0.1 failed during the configure step. The exception was: ExitFailure 1 postgresql-orm-0.3.0 depends on postgresql-libpq-0.9.0.1 which failed to install. postgresql-simple-0.4.2.2 depends on postgresql-libpq-0.9.0.1 which failed to install. }}} I gather that `pg_config` is part of !PostgreSQL, which I am reluctant to install on my (shared) Linux box. (I have no clue how to even begin.) But perhaps it is not really necessary? At the moment this looks like a somewhat serious bug (in the demand analyser) which I have no way to reproduce. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:27:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:27:36 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.1399757c40d609987cd0740811293e69@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: skeuchel Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by skeuchel): @spj: I'm currently traveling back from ZuriHac. Will do so when I'm back home tonight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:32:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:32:34 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.5bb30a08bc19df5c2c89648246690c68@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 13:46:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 13:46:34 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.32febcdaadc8c91df2a51decb9ecd0bb@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by ross): Replying to [comment:20 jstolarek]: > Can I once again ask for help in reading the comments? > > {{{ > -- D; xs1 |-a c : () --> t > -- D; xs' |-a do { ss } : t' xs2 = xs' - defs(p) > -- ----------------------------------- > -- D; xs |-a do { p <- c; ss } : t' > -- > -- ---> premap (\ (xs) -> (((xs1),()),(xs2))) > -- (first c >>> arr (\ (p, (xs2)) -> (xs'))) >>> ss > }}} > I'm totally confused by `(\ (xs) -> (((xs1),()),(xs2)))`. Where do `xs1` and `xs2` come from, if we only bind `xs` as the input to `do { p <- c; ss }`? They are subsets of `xs`: `xs1` is the variables used by `c`, while `xs2` is the variables used by `ss` but not bound in `p`. So the command 'c' gets local environment `xs1` and stack `()`. The translations of statements are arrows that take an environment (here `xs2`) as input. > Also, do I understand correctly that bind expression generated in desugaring of arrow do-notation does not have a source-level equivalent? If so is it even correct to represent it using the !BindStmt constructor? > > In my prototype I'm ignoring Ross' proposal of the new desugaring. I don't understand that question - I don't see a bind expression in the generated code. Do you mean the `BindStmt` emitted by the type checker? No, that wouldn't correspond to something one could write in the command sublanguage. Part of the motivation for my proposal is that the desugaring of do notation would have a source-level equivalent, albeit still in the command sublanguage, but it could be checked using the existing rules for commands. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 14:09:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 14:09:59 -0000 Subject: [GHC] #95: GHCi :edit command should jump to the the last error In-Reply-To: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> References: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> Message-ID: <067.3445f194c4866450bce5718b4eaac0fe@haskell.org> #95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: lortabac martijnislief | Status: patch Type: feature | Milestone: ? request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: None | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by lortabac): I followed your suggestions and I also fixed a small mistake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 14:27:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 14:27:09 -0000 Subject: [GHC] #9175: Bad interaction between Pattern Synonyms and Text In-Reply-To: <047.311a35a65ef21c36ac9cb789bb411456@haskell.org> References: <047.311a35a65ef21c36ac9cb789bb411456@haskell.org> Message-ID: <062.98f3ac6a2b5e22b4bcd88271cae49c40@haskell.org> #9175: Bad interaction between Pattern Synonyms and Text ---------------------------------------+----------------------------------- Reporter: emertens | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 14:30:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 14:30:12 -0000 Subject: [GHC] Batch modify: #9061, #9071, #9096, #9102, #9106 Message-ID: <20140609143012.5B0402406B@ghc.haskell.org> Batch modification to #9061, #9071, #9096, #9102, #9106 by thoughtpolice: milestone to 7.8.3 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 15:58:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 15:58:24 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.ec92071f5e862f5fb02d35961d6d78a3@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by slyfox): Ok, so mechanics to break ghc is to install package in ghc's private dir: http://www.reddit.com/r/haskell/comments/22wu92/problems_installing_ghc_782_on_debian_ubuntu_x86/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 16:00:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 16:00:14 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata Message-ID: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> #9186: GHC panic when compiling compdata ------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When testing ghc-7.8.2.20140609 with Stackage, I came across the following ghc panic: [51 of 62] Compiling Data.Comp.Ordering ( src/Data/Comp/Ordering.hs, dist/build/Data/Comp/Ordering.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2.20140609 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc4836_0/ghc4836_257.so: undefined symbol: compdatazm0zi8zi1zi0_DataziCompziDeriveziUtils_zdwabstractConType_info Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Failed to install compdata-0.8.1.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 16:02:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 16:02:08 -0000 Subject: [GHC] #8897: Can't change "Full Name" in preferences In-Reply-To: <050.cac5fdb9d34ae50c72ea407a1870d09e@haskell.org> References: <050.cac5fdb9d34ae50c72ea407a1870d09e@haskell.org> Message-ID: <065.6f34ef399fddd298e2283843365c0e4c@haskell.org> #8897: Can't change "Full Name" in preferences -------------------------------------+------------------------------------ Reporter: novadenizen | Owner: hvr Type: bug | Status: new Priority: lowest | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thomie): * priority: normal => lowest * version: 7.6.3 => Comment: Workaround: also change the email address, then change it back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 16:19:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 16:19:13 -0000 Subject: [GHC] #9187: Reduce number of missing wiki links by setting ignore_missing_pages in TracIni Message-ID: <045.4d53bdd0b5be9010b74f4b8918421269@haskell.org> #9187: Reduce number of missing wiki links by setting ignore_missing_pages in TracIni -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The GHC wiki currently has lots of missing links, which makes for harder reading. A partial solution, from http://trac.edgewall.org/wiki/CamelCase: "There's an option (ignore_missing_pages in the [wiki] section of TracIni) to simply ignore links to missing pages when the link is written using the CamelCase style, instead of that word being replaced by a gray link followed by a question mark." Could this option be set for the GHC wiki? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 16:38:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 16:38:03 -0000 Subject: [GHC] #9167: Associated type is accepted even without mentioning class parameters In-Reply-To: <047.2d5de3ba88af5354277dc53a66fecc69@haskell.org> References: <047.2d5de3ba88af5354277dc53a66fecc69@haskell.org> Message-ID: <062.0f6a2673a73d4dd54d8ee77aac24e71b@haskell.org> #9167: Associated type is accepted even without mentioning class parameters -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: low | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple indexed_types/should_fail/T9167 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by archblob): The error message now says {{{ The associated type ?F? mentions none of the type variables of the class ?C k a? In the class declaration for ?C? }}} but {{{#!haskell class C (a :: k) where type F (b :: k) }}} is accepted although none of the class type variables are mentioned in the definition for `F` . If this is the intended behavior maybe the error message should say type or kind variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 17:39:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 17:39:50 -0000 Subject: [GHC] #4836: literate markdown not handled correctly by unlit In-Reply-To: <044.677d9d9819274dc3e0fccfc271c35be2@haskell.org> References: <044.677d9d9819274dc3e0fccfc271c35be2@haskell.org> Message-ID: <059.435326fa5a5b649fb423ce1f46e74015@haskell.org> #4836: literate markdown not handled correctly by unlit ----------------------------------------------+---------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7120 ----------------------------------------------+---------------------------- Comment (by elliottt): Moving CPP after unlit solves the problem with the sections defined by #, but it doesn't change the fact that in markdown, bird track blocks are actually quotations, not code [1]. What about this as a compromise (assuming my patch gets accepted): move unlit before CPP, to avoid problems with #, and keep the separate processing for .md/.markdown, allowing the distinction between bird tracks and code blocks in markdown. This way, you can write markdown in a .lhs file and use bird tracks for code blocks, and I can write haskell in a .md file using fenced code blocks, and still be able to write quotation blocks. [1] http://daringfireball.net/projects/markdown/syntax#blockquote -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 17:41:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 17:41:18 -0000 Subject: [GHC] #9188: quot with a power of two is not optimized to a shift Message-ID: <044.a5f82f80802d358b9f352746a0446791@haskell.org> #9188: quot with a power of two is not optimized to a shift ------------------------------+-------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- The follow code: {{{ module Test where f :: Int -> Int f n = n `quot` 2 }}} results in the following core: {{{ Test.f :: GHC.Types.Int -> GHC.Types.Int Test.f = \ (n_aeH :: GHC.Types.Int) -> case n_aeH of _ { GHC.Types.I# ww_aiQ -> GHC.Types.I# (GHC.Prim.quotInt# ww_aiQ 2) } }}} which in turn generates this Cmm {{{ sjI_ret() { Just sjI_info: const 0; const 32; } cjX: Hp = Hp + 16; if (Hp > I64[BaseReg + 144]) goto ck3; _sjH::I64 = %MO_S_Quot_W64(I64[R1 + 7], 2); I64[Hp - 8] = PicBaseReg + GHC.Types.I#_con_info; I64[Hp + 0] = _sjH::I64; R1 = Hp - 7; Sp = Sp + 8; jump (I64[Sp + 0]); // [R1] ck1: jump (I64[BaseReg - 16]); // [R1] ck3: I64[BaseReg + 192] = 16; goto ck1; } }}} which finally ends up as this assembly: {{{ sjI_info: _cjX: addq $16,%r12 cmpq 144(%r13),%r12 ja _ck3 movl $2,%ecx movq 7(%rbx),%rax cqto idivq %rcx movq %rax,%rbx leaq GHC.Types.I#_con_info(%rip),%rax movq %rax,-8(%r12) movq %rbx,0(%r12) leaq -7(%r12),%rbx addq $8,%rbp jmp *0(%rbp) }}} Ideally this should have turned into a shift, not a division. `compiler/nativeGen/X86/CodeGen.hs` lacks any peephole optimizations for division. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 18:43:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 18:43:44 -0000 Subject: [GHC] #95: GHCi :edit command should jump to the the last error In-Reply-To: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> References: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> Message-ID: <067.0dda7ba8a97a71caea80c095888aa3bd@haskell.org> #95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: lortabac martijnislief | Status: patch Type: feature | Milestone: ? request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: None | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by nomeata): Better! So time for the next round of suggestions. I found this code confusing {{{ let ... setGhciErrors e = writeIORef lastErrLocations (errs ++ e) setGhciErrors $ errLocation srcSpan }}} why not {{{ let ... writeIORef lastErrLocations (errs ++ errLocation srcSpan) }}} In fact I find the whole section there a bit strange. Some suggestions: * Use `modifyIORef` * Write something like {{{ case srcSpan of RealSrcSpan rsp -> modifyIORef lastErrLocations (++ [srcLocFile (realSrcSpanStart x) , srcLocLine (realSrcSpanStart x) ]) _ -> return () }}} so you don?t have to introduce so many local functions and do tricks with `++ []`. * `find (\(f, _) -> f == mkFastString file) errs` can even simplified to `lookup (mkFastSTring file)` I would put {{{ ghciState <- lift getGHCiState liftIO $ writeIORef (lastErrorLocations ghciState) [] }}} in a function `resetLastErrorLocations :: GHCi ()`. Naming that code also serves as documentation, and you don?t clutter the local name space of `doLoad` with the `ghciState` I wonder if things work well if the user uses a different path to the filename than GHC; maybe one wants to use a function that can check if two filenames point to the same file. But maybe that is a refinement that can be added later. Can you come up with a way to test this? Maybe by setting the editor to use to `/bin/echo`, which will put `+123` in the output that the test suite would check? See [Building/RunningTests/Adding] and shout if you need help creating a test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 18:56:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 18:56:07 -0000 Subject: [GHC] #9188: quot with a power of two is not optimized to a shift In-Reply-To: <044.a5f82f80802d358b9f352746a0446791@haskell.org> References: <044.a5f82f80802d358b9f352746a0446791@haskell.org> Message-ID: <059.e230998c57c434b48264388d83048e2c@haskell.org> #9188: quot with a power of two is not optimized to a shift --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8311 --------------------------------------------+------------------------------ Changes (by rwbarton): * related: => #8311 Comment: See also #8311. Note that `quot` by 2 rounds towards zero, so for negative `Int`s it's not quite just a shift. The LLVM backend does handle this well, producing this sequence for the division: {{{ 7c: 48 89 d0 mov %rdx,%rax 7f: 48 c1 e8 3f shr $0x3f,%rax 83: 48 01 d0 add %rdx,%rax ; add sign bit to move towards 0 86: 48 d1 f8 sar %rax }}} A `div` by 2 really would be a single arithmetic shift, but at the Cmm level there is still a function call to `divInt#` :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 18:56:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 18:56:34 -0000 Subject: [GHC] #8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) In-Reply-To: <047.86e8206e31b6dc590c59487f4d1109a7@haskell.org> References: <047.86e8206e31b6dc590c59487f4d1109a7@haskell.org> Message-ID: <062.aee479d14aa23b09094b847e3ef0f8fa@haskell.org> #8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9188 -------------------------------------+------------------------------------ Changes (by rwbarton): * related: => #9188 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 18:59:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 18:59:06 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.35cac076f3727a767bc76c255ebcbdc4@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9164 -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"1946922c61df427e59f8a00572fd4dd6501abd98/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1946922c61df427e59f8a00572fd4dd6501abd98" Make Ptr's parameter phantom and implement castPtr with coerce, which gives 12% less allocation in reverse-complem 7.3% less allocation in fasta. Binary sizes fell 0.1%. as reported and discussed in #9163. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 19:00:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 19:00:15 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.c119b48b8895baf4c323cc71e4e76704@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9164 -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 19:04:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 19:04:35 -0000 Subject: [GHC] #9178: improve orphan instance warning In-Reply-To: <043.fcde19f8eb765ccd6976e8ca3285d142@haskell.org> References: <043.fcde19f8eb765ccd6976e8ca3285d142@haskell.org> Message-ID: <058.b75818a16305a7fc418692f4d390c5a1@haskell.org> #9178: improve orphan instance warning -------------------------------------+------------------------------------ Reporter: fphh | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"707bde533dcb16bf8f5a30179d098b343e54fe7b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="707bde533dcb16bf8f5a30179d098b343e54fe7b" Update test results with new orphan instance warning It seems that the patch in #9178 was not fully validated. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 20:33:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 20:33:07 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.66360625809603c084bd6e459abfca86@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------+------------------------------------------- Reporter: aspidites | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by monoidal): You've changed `lambda (f,x):` to `lambda f, x:`. They're not the same! Apart from that, looks good to me. The `__future__` import is not supported in 2.5, but that version is so old I think there's no point in supporting it (and it's likely the scripts currently don't work with it, anyway). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 20:48:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 20:48:56 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.51aab6341e43901c10861fc2e677124d@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9164 -------------------------------------+------------------------------------ Comment (by simonmar): I think it would be good to do this for `FunPtr` too, if it's not too hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 20:58:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 20:58:37 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.8309f2530a71a9f632fd1254243f93cb@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------+------------------------------------------- Reporter: aspidites | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by aspidites): My mistake. I've corrected this by manually unpacking the tuple. The alternative would have been to unpack the tuple as it was being sent into the lambda, but I figured this way was less disruptive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 20:59:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 20:59:15 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.7b1a954bb716bd9a77bcc2a3d0dca9d5@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9164 -------------------------------------+------------------------------------ Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: I had to revert the patch, adding `NoImplicitPrelude` to `Data.Coerce` makes the build system trip over. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 9 22:19:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jun 2014 22:19:20 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.4c7db534e4b2a24fdfb064561955a0be@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9164 -------------------------------------+------------------------------------ Changes (by simonpj): * cc: core-libraries-committee@? (added) Comment: FWIW I'd also be happy to treat `FunPtr` just like `Ptr` (ie phantom). I'll add the core-libraries-committee in cc Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 07:26:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 07:26:40 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.88f28a1c434bd98b39dfdd0b84a4da45@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9164 -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"5bdbd510a78f0c17d702fa9399cc0501cfd00fac/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5bdbd510a78f0c17d702fa9399cc0501cfd00fac" Make Ptr's parameter phantom and implement castPtr with coerce, which gives 12% less allocation in reverse-complem 7.3% less allocation in fasta. Binary sizes fell 0.1%. as reported and discussed in #9163. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 07:35:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 07:35:05 -0000 Subject: [GHC] #9188: quot with a power of two is not optimized to a shift In-Reply-To: <044.a5f82f80802d358b9f352746a0446791@haskell.org> References: <044.a5f82f80802d358b9f352746a0446791@haskell.org> Message-ID: <059.272e623ad002752b8e27d945a3a58f22@haskell.org> #9188: quot with a power of two is not optimized to a shift --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8311, | #5615 --------------------------------------------+------------------------------ Changes (by jstolarek): * related: #8311 => #8311, #5615 Comment: Johan, do you think we can consider your report a duplicate of #5615? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 07:59:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 07:59:20 -0000 Subject: [GHC] #9188: quot with a power of two is not optimized to a shift In-Reply-To: <044.a5f82f80802d358b9f352746a0446791@haskell.org> References: <044.a5f82f80802d358b9f352746a0446791@haskell.org> Message-ID: <059.9a2b78f38f739ed0f3cd459c7159d030@haskell.org> #9188: quot with a power of two is not optimized to a shift --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8311, | #5615 --------------------------------------------+------------------------------ Changes (by tibbe): * status: new => closed * resolution: => duplicate Comment: Duplicate of #5615. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 08:00:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 08:00:23 -0000 Subject: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2. In-Reply-To: <046.611e1011b849d674524f2ee05d864a89@haskell.org> References: <046.611e1011b849d674524f2ee05d864a89@haskell.org> Message-ID: <061.e41bf6a6966e3e45622998a1bd4db623@haskell.org> #5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by tibbe): * cc: tibbe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 08:45:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 08:45:37 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.6a7d65f9767c7f38f56d09401fc389fb@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 7623, 8664 --------------------------------------------+------------------------------ Comment (by nomeata): Can we get this into 7.8.3 or 7.8.4? Debian will have to add this patch anyways, and I?m always keen on reducing delta. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 09:32:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 09:32:19 -0000 Subject: [GHC] #9185: glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknown archs (was: glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknowns archs) In-Reply-To: <050.ec9d0ec38ab57c70c2fd6acc66f09adc@haskell.org> References: <050.ec9d0ec38ab57c70c2fd6acc66f09adc@haskell.org> Message-ID: <065.bed5cbeb9ca7e029cef00c90b03701d6@haskell.org> #9185: glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknown archs -------------------------------------------------+------------------------- Reporter: juhpetersen | Owner: Type: bug | juhpetersen Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: 7.8.2 Operating System: Linux | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 09:47:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 09:47:10 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.78cbf49ab161b63357ef2e97300909e1@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 10:22:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 10:22:12 -0000 Subject: [GHC] #9189: Linking fails on OSX when -staticlib and -threaded are enabled Message-ID: <044.0c8606ec248a61b17a138fdb6cbb90d5@haskell.org> #9189: Linking fails on OSX when -staticlib and -threaded are enabled -------------------------------------+------------------------------------- Reporter: frode | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: pthread staticlib | Operating System: MacOS X threaded | Type of failure: Compile-time Architecture: x86 | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I'm trying to build a library with ffi exported functions to be called from ObjectiveC in an Xcode project on OSX. With just -staticlib it works, but when I add -threaded as well I get a linker error saying that it cannot find pthread. This happens even with a trivial program: {{{ Test.hs: module Test where main :: IO () main = putStrLn "Hello" }}} {{{ $ ghc Test.hs -staticlib -threaded [1 of 1] Compiling Test ( Test.hs, Test.o ) Linking liba.a ... error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lpthread error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lpthread is not an object file (not allowed in a library) }}} The linker command that fails: {{{ *** Linker: libtool -static -o liba.a Test.o -L/usr/local/lib/ghc-7.8.2/base-4.7.0.0 -L/usr/local/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/usr/local/lib/ghc-7.8.2 /ghc-prim-0.3.1.0 -L/usr/local/lib/ghc-7.8.2/rts-1.0 /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -lHSbase-4.7.0.0 -lHSinteger-gmp-0.5.1.0 -lHSghc-prim-0.3.1.0 -lHSrts_thr -lCffi -lpthread }}} If I make a script that removes the -lpthread argument, it links ok and the project works with multiple threads calling my ffi-functions simultaneously. It was suggested by Bob on Haskell Cafe that it should not link against libpthread on OSX since it is included in libSystem (like IOS): https://groups.google.com/d/msg/haskell-cafe/GGEkifs_-uY/uzHeV-Z2E2YJ https://github.com/ghc/ghc/blob/master/compiler/main/DriverPipeline.hs#L1869-L1873 OSX version 10.9.3 Verbose output: {{{ $ ghc Test.hs -staticlib -threaded -v Glasgow Haskell Compiler, Version 7.8.2, stage 2 booted by GHC version 7.6.3 Using binary package database: /usr/local/lib/ghc-7.8.2/package.conf.d/package.cache Using binary package database: /Users/frode/.ghc/x86_64-darwin-7.8.2/package.conf.d/package.cache hiding package Cabal-1.18.1.3 to avoid conflict with later version Cabal-1.20.0.0 hiding package hoauth2-0.3.6.2 to avoid conflict with later version hoauth2-0.3.7 hiding package hoauth2-0.3.6.1 to avoid conflict with later version hoauth2-0.3.7 wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 wired-in package integer-gmp mapped to integer- gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 wired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: hiding package Cabal-1.18.1.3 to avoid conflict with later version Cabal-1.20.0.0 hiding package hoauth2-0.3.6.2 to avoid conflict with later version hoauth2-0.3.7 hiding package hoauth2-0.3.6.1 to avoid conflict with later version hoauth2-0.3.7 wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 wired-in package integer-gmp mapped to integer- gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 wired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *Test.hs Stable obj: [Test] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2014-06-10 10:02:41 UTC ms_mod = main:Test, ms_textual_imps = [import (implicit) Prelude] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file Test.hs Created temporary directory: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0 *** Checking old interface for main:Test: [1 of 1] Skipping Test ( Test.hs, Test.o ) Upsweep completely successful. *** Deleting temp files: Deleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_1.s Warning: deleting non-existent /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_1.s link: linkables are ... LinkableM (2014-06-10 10:02:55 UTC) main:Test [DotO Test.o] Linking liba.a ... *** C Compiler: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_2.c -o /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -I/usr/local/lib/ghc-7.8.2/include *** Linker: libtool -static -o liba.a Test.o -L/usr/local/lib/ghc-7.8.2/base-4.7.0.0 -L/usr/local/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/usr/local/lib/ghc-7.8.2 /ghc-prim-0.3.1.0 -L/usr/local/lib/ghc-7.8.2/rts-1.0 /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -lHSbase-4.7.0.0 -lHSinteger-gmp-0.5.1.0 -lHSghc-prim-0.3.1.0 -lHSrts_thr -lCffi -lpthread error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lpthread error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lpthread is not an object file (not allowed in a library) *** Deleting temp files: Deleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_2.c *** Deleting temp dirs: Deleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 10:59:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 10:59:34 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.abaf657db1ee3a5eff4d0f6bb3e75ff8@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by jstolarek): > They are subsets of xs: xs1 is the variables used by c, while xs2 is the > variables used by ss but not bound in p. So the command 'c' gets local > environment xs1 and stack (). The translations of statements are arrows that > take an environment (here xs2) as input. That starts to make sense :-) As I understand `x1` and `x2` need not be disjoint - is that correct? I am yet to understand the rules for encoding the input parameters to the arrows. Is there a general rule that says when and in what order things are put on the stack? Is it the case that elements on the stack are never accessed and need to be popped if they are to be used? I know all of this could be deduced from the source code, but sadly this is not straightforward (at least for me). > I don't understand that question - I don't see a bind expression in the generated code. What I meant is that desugaring of arrow bind is completely different from monadic bind (which is desugared to `>>=`+lambda) so perhaps it deserves its own internal representation. But in fact this is what my prototype implements ie. it distingushes arrow and monadic bind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 13:51:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 13:51:45 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.48366a0df16dc2d5e119d0a71e3ac4f6@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature | Status: patch request | Milestone: ? Priority: normal | Version: 6.6.1 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by archblob): * cc: hvr (added) * status: new => patch Comment: There may be some nuances in the whole linking stuff that I don't understand, so please review. As far as I can tell the patch works as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 13:52:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 13:52:40 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.5282b4e329e6070928d23f349756a85a@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------+------------------------------------------- Reporter: guest | Owner: archblob Type: feature | Status: patch request | Milestone: ? Priority: normal | Version: 6.6.1 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by archblob): * owner: => archblob -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 14:29:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 14:29:43 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.3b5c9b6130787c7fe12a542db96501f7@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9164 -------------------------------------+------------------------------------ Changes (by goldfire): * owner: => goldfire Comment: As noted previously, `FunPtr`'s roles are a little fiddlier. I'll take this one, and add a bunch of comments while I'm at it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 15:02:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 15:02:58 -0000 Subject: [GHC] #9190: Iface type variable out of scope: s Message-ID: <046.ae688232714aa8206efce4424bf2e376@haskell.org> #9190: Iface type variable out of scope: s ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I just tried to install criterion with the current GHC HEAD, and `statistics` failed with this message: {{{ /home/jojo/.cabal/lib/x86_64-linux-ghc-7.9.20140609/math- functions-0.1.5.2/Numeric/Sum.hi Declaration for R:MVectorsKBNSum: Iface type variable out of scope: s Cannot continue after interface file error }}} I tried to reproduce this with smaller code than `statistics`, but could not trigger it. The interface dump gives me: {{{ 661d69e55c1491128ac1ed3c03f864e2 axiom TFCo:R:MVectorsKB2Sum:: Data.Vector.Unboxed.Base.MVector s0 Numeric.Sum.KB2Sum = Numeric.Sum.R:MVectorsKB2Sum s0 a69bb56c3760003bcb7d99cd40c3d843 axiom TFCo:R:MVectorsKBNSum:: Data.Vector.Unboxed.Base.MVector s0 Numeric.Sum.KBNSum = Numeric.Sum.R:MVectorsKBNSum s0 }}} ? not sure if there is a `forall` missing or note. Note that these data types are generated using template haskell [http://hdiff.luite.com/cgit /math- functions/tree/Numeric/Sum.hs?id=06b09eb4f110f99fb51a9ec0ec598fba54ac0986#n123 source]. In order to reproduce this, run someting like `cabal install --with-compiler=.../inplace/bin/ghc-stage2 --ghc- option=-XTypeFamilies .` in `statistics-0.11.0.3` with the attached patch applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 16:03:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 16:03:45 -0000 Subject: [GHC] #9187: Reduce number of missing wiki links by setting ignore_missing_pages in TracIni In-Reply-To: <045.4d53bdd0b5be9010b74f4b8918421269@haskell.org> References: <045.4d53bdd0b5be9010b74f4b8918421269@haskell.org> Message-ID: <060.fd2a425a5069b13a15457cb0f86b094e@haskell.org> #9187: Reduce number of missing wiki links by setting ignore_missing_pages in TracIni -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by jstolarek): +1 from me. It's annoying to have VariousCamelCase words turned into links automatically (yes, I know this can be prevented with !, but still). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 16:54:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 16:54:42 -0000 Subject: [GHC] #9183: GHC shouldn't expand constraint synonyms In-Reply-To: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> References: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> Message-ID: <063.94b794084815c8a880ae5fde0729fbff@haskell.org> #9183: GHC shouldn't expand constraint synonyms -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I see what you want, but I don't see how to achieve it. Recall that * `:info f` takes a name `f` and tells you stuff about `f` * `:type e` takes an abritrary expression `e` and tells you its type If you use `:info showX` you'll see the type you expect. If you use `:type showX` you are using `:type` with an "arbitrary expression" that turns out to be a single identifier. So GHC instantiates it with fresh type variables, generates constraints, simplifies them, and then re- generalises. The instantiation, constraint simplification, and regeneration is what expands the constraint synonym, and I don't see a robust way to stop that happening. We could make `:type` behave like `:info` when given a bare identifier. Or, in those same circumstances, we would make `:type` refrain from the "instantiate, simplify, generalise" hoopla. But that would make `:type` on a bare identifier behave subtly differently to the way it does now.Is that special case worth it? Or would it be better to encourage users to use `:info` whenever possible? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 17:41:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 17:41:03 -0000 Subject: [GHC] #9187: Reduce number of missing wiki links by setting ignore_missing_pages in TracIni In-Reply-To: <045.4d53bdd0b5be9010b74f4b8918421269@haskell.org> References: <045.4d53bdd0b5be9010b74f4b8918421269@haskell.org> Message-ID: <060.19516d06be5d38258f40a35539d6a148@haskell.org> #9187: Reduce number of missing wiki links by setting ignore_missing_pages in TracIni -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by hvr): I've changed that setting, so effective immediately CamelCase identifiers LikeThis w/o a matching wiki-page name will display as non-links... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 18:45:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 18:45:49 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.dd2bb5bd038d0bd34de1e0fcd103f50a@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by ross): Replying to [comment:22 jstolarek]: > > They are subsets of xs: xs1 is the variables used by c, while xs2 is the > > variables used by ss but not bound in p. So the command 'c' gets local > > environment xs1 and stack (). The translations of statements are arrows that > > take an environment (here xs2) as input. > > That starts to make sense :-) As I understand `x1` and `x2` need not be > disjoint - is that correct? That's right. If a variable is used by both `c` and `ss`, it will be in both sets. > I am yet to understand the rules for encoding the input parameters to the arrows. > Is there a general rule that says when and in what order things are put on the stack? > Is it the case that elements on the stack are never accessed and need to be popped > if they are to be used? Things are added to the stack by `HsCmdApp` and removed with `HsCmdLam`, but stacks can also be modified by `HsCmdArrForm` - there are some examples in the "Primitive constructs" section in teh arrow notation part of the GHC User's Guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 18:55:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 18:55:19 -0000 Subject: [GHC] #9115: The kind of (=>) In-Reply-To: <047.79a80bb2b897dcc6ec2d89a1e91dba60@haskell.org> References: <047.79a80bb2b897dcc6ec2d89a1e91dba60@haskell.org> Message-ID: <062.d2ea720b0752d2c4a9f99316d132e932@haskell.org> #9115: The kind of (=>) -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Here's a reason: normally, if we know `(a b c) ~ (d e f)`, it is reasonable to conclude `a ~ d`, `b ~ e` and `c ~ f`. But, what if `a` is really `(=>)`? Could `b` become `(Eq a, Eq [a])` and `e` become `Eq [a]`? Is it the case that `(Eq a, Eq [a]) ~ Eq [a]`? These are logically equivalent, but are they equal in the sense of `(~)`? I would hope not. Indeed, even asking whether `(a => b) ~ (c => d)` right now is forbidden. There may be a reasonable way forward here, but it's not abundantly obvious. If you want More Thought put into this, do you have a use case in mind? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 19:35:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 19:35:02 -0000 Subject: [GHC] #9063: Default associated type instances are too general In-Reply-To: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> References: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> Message-ID: <062.d85d2cac0332d11b787dcef77d2a5ece@haskell.org> #9063: Default associated type instances are too general -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): This might just be related to #9151. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 19:50:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 19:50:19 -0000 Subject: [GHC] #9191: Semi-exported names Message-ID: <045.d5439bf8b076b8ab603179ac5dbb9835@haskell.org> #9191: Semi-exported names --------------------------------------+------------------------------------ Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (CodeGen) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: --------------------------------------+------------------------------------ It's generally inadvisable to add exports to a well-known module because they may clash with existing code using the module and importing it in its entirety. As a work-around, I propose allowing a module to export a name that will only be visible in a module that lists it explicitly. Something approximately like module Foo (a, b, explicit c) simply import Foo would not bring c into scope, but import Foo (c) would bring in c (and nothing else). To get everything, we could use something like import Foo revealing (c) and to be a bit picky, import Foo hiding (a) revealing (c). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 20:16:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 20:16:39 -0000 Subject: [GHC] #9191: Semi-exported names In-Reply-To: <045.d5439bf8b076b8ab603179ac5dbb9835@haskell.org> References: <045.d5439bf8b076b8ab603179ac5dbb9835@haskell.org> Message-ID: <060.275c7bdff1e74139a175e66f51a7d961@haskell.org> #9191: Semi-exported names -------------------------------------+------------------------------------ Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by dfeuer): * component: Compiler (CodeGen) => Compiler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 20:18:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 20:18:30 -0000 Subject: [GHC] #9191: Semi-exported names In-Reply-To: <045.d5439bf8b076b8ab603179ac5dbb9835@haskell.org> References: <045.d5439bf8b076b8ab603179ac5dbb9835@haskell.org> Message-ID: <060.5e7a5016eafc4e2e8bbb8a605f5b80aa@haskell.org> #9191: Semi-exported names -------------------------------------+------------------------------------ Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by dfeuer: Old description: > It's generally inadvisable to add exports to a well-known module because > they may clash with existing code using the module and importing it in > its entirety. As a work-around, I propose allowing a module to export a > name that will only be visible in a module that lists it explicitly. > Something approximately like > > module Foo (a, b, explicit c) > > simply > > import Foo > > would not bring c into scope, but > > import Foo (c) > > would bring in c (and nothing else). To get everything, we could use > something like > > import Foo revealing (c) > > and to be a bit picky, > > import Foo hiding (a) revealing (c). New description: It's generally inadvisable to add exports to a well-known module because they may clash with existing code using the module and importing it in its entirety. As a work-around, I propose allowing a module to export a name that will only be visible in a module that lists it explicitly. If we had module Foo (a, b, hidden c) then simply import Foo would not bring c into scope, but import Foo (c) would bring in c (and nothing else). To get everything, we could use something like import Foo revealing (c) and to be a bit picky, import Foo hiding (a) revealing (c). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 20:37:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 20:37:39 -0000 Subject: [GHC] #9191: Semi-exported names In-Reply-To: <045.d5439bf8b076b8ab603179ac5dbb9835@haskell.org> References: <045.d5439bf8b076b8ab603179ac5dbb9835@haskell.org> Message-ID: <060.523b136af27587efacd0070f3cb2105a@haskell.org> #9191: Semi-exported names -------------------------------------+------------------------------------ Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): While the *goal* of this suggestion is great, the *means* is a bit questionable, or at least theres some folks already working to spec out an even better approach (though nothings mature yet) I think the work in progress to endow GHC with a module type system actually subsumes this idea. see http://plv.mpi-sws.org/backpack/ and https://ghc.haskell.org/trac/ghc/wiki/Backpack In that setting, you import wrt a *signature* of what you expect a module to have, which will be a subset of the module exports. This naturally solves your revealing/hiding/hidden/explicit notions in a much nicer way I think. Do you think those works will subsume your proposal? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 20:52:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 20:52:31 -0000 Subject: [GHC] #3372: Allow for multiple linker instances In-Reply-To: <049.b54da97038a1da97405ea7b63a99f067@haskell.org> References: <049.b54da97038a1da97405ea7b63a99f067@haskell.org> Message-ID: <064.f31407462ec9b842b320c6185058be6c@haskell.org> #3372: Allow for multiple linker instances -------------------------------------+------------------------------------ Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thomie): Corresponding wiki page: [wiki:MultipleLinkerInstances] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 21:20:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 21:20:49 -0000 Subject: [GHC] #9192: Add sameByteArray# Message-ID: <044.4adc5b0f7cf12ed14c392d7866ef0f7f@haskell.org> #9192: Add sameByteArray# ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We have `sameMutableByteArray#` so we ought to have `sameByteArray#` as well, allowing for cheap equality checks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 10 21:21:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jun 2014 21:21:55 -0000 Subject: [GHC] #4442: Add unaligned version of indexWordArray# In-Reply-To: <044.4c85d11a3d9c22b5e6021cb85ad43106@haskell.org> References: <044.4c85d11a3d9c22b5e6021cb85ad43106@haskell.org> Message-ID: <059.9b20aca58a8a42820b9e45665c48d533@haskell.org> #4442: Add unaligned version of indexWordArray# --------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: libraries (other) | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by tibbe): * cc: duncan (added) * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 00:40:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 00:40:31 -0000 Subject: [GHC] #9191: Semi-exported names In-Reply-To: <045.d5439bf8b076b8ab603179ac5dbb9835@haskell.org> References: <045.d5439bf8b076b8ab603179ac5dbb9835@haskell.org> Message-ID: <060.28b3b44d41c1574a75704c6c89b3d3c5@haskell.org> #9191: Semi-exported names -------------------------------------+------------------------------------ Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dfeuer): Replying to [comment:3 carter]: > Do you think those works will subsume your proposal? I don't believe so. Backpack appears to build a whole new layer on top of the primitive module system to impose constraints on modules, support separate type-checking, etc. It (or something similar) looks likely to become an important part of the Haskell ecosystem, supporting large projects and interdependent libraries. My proposal is a much more restricted one, filling in a small gap in the underlying module system itself that can cause trouble when modifying a module that ''old'' code imports in its entirety. This old code (which, since it uses unrestricted module import, was probably written with more of an eye toward release date than long-term maintenance) may never be retrofitted to use a system like Backpack. The specific use-case I had in mind was adding `uncons :: [a] -> Maybe (a, [a])` to `Data.List`. It obviously ''belongs'' there, but adding it could break a lot of modules that just `import Data.List`. If it were possible to make it hidden, so only modules that want it would get it, then all would be fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 06:22:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 06:22:49 -0000 Subject: [GHC] #9115: The kind of (=>) In-Reply-To: <047.79a80bb2b897dcc6ec2d89a1e91dba60@haskell.org> References: <047.79a80bb2b897dcc6ec2d89a1e91dba60@haskell.org> Message-ID: <062.759274b14b1a88b9f57888ba5dfc2d53@haskell.org> #9115: The kind of (=>) -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by kosmikus): Thanks a lot for the answer. This is indeed the kind of problem I was suspecting behind the limitation, but I wasn't quite sure what issues there are. I don't need this in any way. I've just been explaining constraint kinds in the context of Haskell courses and talks a couple of times recently, and I always thought it would be nice to be able to get GHCi to output the kind of `=>`. But I completely understand that it may be problematic to make `=>` completely first class. Feel free to close if you think this has no chance of being implemented any time soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 08:44:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 08:44:25 -0000 Subject: [GHC] #9164: Hunt down uses of `castPtr` In-Reply-To: <046.786745c4f6f3f83d0a16b89841bd178e@haskell.org> References: <046.786745c4f6f3f83d0a16b89841bd178e@haskell.org> Message-ID: <061.9859f92d24986c5e449296af016cd25f@haskell.org> #9164: Hunt down uses of `castPtr` -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Since #9163 could be solved with castPtr being free, then this ticket becomes moot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 08:55:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 08:55:14 -0000 Subject: [GHC] #9190: Iface type variable out of scope: s In-Reply-To: <046.ae688232714aa8206efce4424bf2e376@haskell.org> References: <046.ae688232714aa8206efce4424bf2e376@haskell.org> Message-ID: <061.9fcfa3a1133e1a3f161019935e7896c6@haskell.org> #9190: Iface type variable out of scope: s -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I managed to extract a smaller example exhibiting the problem: {{{ module T9190 (pfxSumR) where import Numeric.Sum import qualified Data.Vector.Generic as G import qualified Data.Vector.Unboxed as U pfxSumR :: U.Vector Double -> U.Vector Double pfxSumR = G.map kbn . G.scanr (flip add) zero }}} The problem only occurs with `-O`, and would not occur with {{{ -- No error with: -- pfxSumR :: U.Vector KBNSum -> U.Vector Double -- pfxSumR = G.map kbn . G.scanr (flip add) zero }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 08:55:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 08:55:27 -0000 Subject: [GHC] #9190: Iface type variable out of scope: s In-Reply-To: <046.ae688232714aa8206efce4424bf2e376@haskell.org> References: <046.ae688232714aa8206efce4424bf2e376@haskell.org> Message-ID: <061.e07123e5ea609793637afb633cf2ae4e@haskell.org> #9190: Iface type variable out of scope: s -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by nomeata: Old description: > I just tried to install criterion with the current GHC HEAD, and > `statistics` failed with this message: > > {{{ > /home/jojo/.cabal/lib/x86_64-linux-ghc-7.9.20140609/math- > functions-0.1.5.2/Numeric/Sum.hi > Declaration for R:MVectorsKBNSum: > Iface type variable out of scope: s > Cannot continue after interface file error > }}} > > I tried to reproduce this with smaller code than `statistics`, but could > not trigger it. > > The interface dump gives me: > {{{ > 661d69e55c1491128ac1ed3c03f864e2 > axiom TFCo:R:MVectorsKB2Sum:: > Data.Vector.Unboxed.Base.MVector s0 Numeric.Sum.KB2Sum > = Numeric.Sum.R:MVectorsKB2Sum s0 > a69bb56c3760003bcb7d99cd40c3d843 > axiom TFCo:R:MVectorsKBNSum:: > Data.Vector.Unboxed.Base.MVector s0 Numeric.Sum.KBNSum > = Numeric.Sum.R:MVectorsKBNSum s0 > }}} > ? not sure if there is a `forall` missing or note. Note that these data > types are generated using template haskell [http://hdiff.luite.com/cgit > /math- > functions/tree/Numeric/Sum.hs?id=06b09eb4f110f99fb51a9ec0ec598fba54ac0986#n123 > source]. > > In order to reproduce this, run someting like > `cabal install --with-compiler=.../inplace/bin/ghc-stage2 --ghc- > option=-XTypeFamilies .` in `statistics-0.11.0.3` with the attached patch > applied. New description: I just tried to install criterion with the current GHC HEAD, and `statistics` failed with this message: {{{ /home/jojo/.cabal/lib/x86_64-linux-ghc-7.9.20140609/math- functions-0.1.5.2/Numeric/Sum.hi Declaration for R:MVectorsKBNSum: Iface type variable out of scope: s Cannot continue after interface file error }}} I tried to reproduce this with smaller code than `statistics`, but could not trigger it. The interface dump gives me: {{{ 661d69e55c1491128ac1ed3c03f864e2 axiom TFCo:R:MVectorsKB2Sum:: Data.Vector.Unboxed.Base.MVector s0 Numeric.Sum.KB2Sum = Numeric.Sum.R:MVectorsKB2Sum s0 a69bb56c3760003bcb7d99cd40c3d843 axiom TFCo:R:MVectorsKBNSum:: Data.Vector.Unboxed.Base.MVector s0 Numeric.Sum.KBNSum = Numeric.Sum.R:MVectorsKBNSum s0 }}} ? not sure if there is a `forall` missing or not. Note that these data types are generated using template haskell [http://hdiff.luite.com/cgit /math- functions/tree/Numeric/Sum.hs?id=06b09eb4f110f99fb51a9ec0ec598fba54ac0986#n123 source]. In order to reproduce this, run someting like `cabal install --with-compiler=.../inplace/bin/ghc-stage2 --ghc- option=-XTypeFamilies .` in `statistics-0.11.0.3` with the attached patch applied. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 08:59:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 08:59:08 -0000 Subject: [GHC] #9190: Iface type variable out of scope: s In-Reply-To: <046.ae688232714aa8206efce4424bf2e376@haskell.org> References: <046.ae688232714aa8206efce4424bf2e376@haskell.org> Message-ID: <061.a02c9d51a994c2b317af02347a957748@haskell.org> #9190: Iface type variable out of scope: s -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): The interface of `Numeric.Sum`, when printed with GHC 7.6.3, looks like this {{{ axiom TFCo:R:MVectorsKBNSum [(s0, *)] :: Data.Vector.Unboxed.Base.MVector s0 Numeric.Sum.KBNSum ~# Numeric.Sum.R:MVectorsKBNSum s0 }}} Does `[(s0,*)]` indicate the type variables this axiom is abstracted over? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 08:59:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 08:59:39 -0000 Subject: [GHC] #9190: Iface type variable out of scope: s In-Reply-To: <046.ae688232714aa8206efce4424bf2e376@haskell.org> References: <046.ae688232714aa8206efce4424bf2e376@haskell.org> Message-ID: <061.dbb66522ba47d199be117c6f7634a295@haskell.org> #9190: Iface type variable out of scope: s -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Old description: > I just tried to install criterion with the current GHC HEAD, and > `statistics` failed with this message: > > {{{ > /home/jojo/.cabal/lib/x86_64-linux-ghc-7.9.20140609/math- > functions-0.1.5.2/Numeric/Sum.hi > Declaration for R:MVectorsKBNSum: > Iface type variable out of scope: s > Cannot continue after interface file error > }}} > > I tried to reproduce this with smaller code than `statistics`, but could > not trigger it. > > The interface dump gives me: > {{{ > 661d69e55c1491128ac1ed3c03f864e2 > axiom TFCo:R:MVectorsKB2Sum:: > Data.Vector.Unboxed.Base.MVector s0 Numeric.Sum.KB2Sum > = Numeric.Sum.R:MVectorsKB2Sum s0 > a69bb56c3760003bcb7d99cd40c3d843 > axiom TFCo:R:MVectorsKBNSum:: > Data.Vector.Unboxed.Base.MVector s0 Numeric.Sum.KBNSum > = Numeric.Sum.R:MVectorsKBNSum s0 > }}} > ? not sure if there is a `forall` missing or not. Note that these data > types are generated using template haskell [http://hdiff.luite.com/cgit > /math- > functions/tree/Numeric/Sum.hs?id=06b09eb4f110f99fb51a9ec0ec598fba54ac0986#n123 > source]. > > In order to reproduce this, run someting like > `cabal install --with-compiler=.../inplace/bin/ghc-stage2 --ghc- > option=-XTypeFamilies .` in `statistics-0.11.0.3` with the attached patch > applied. New description: I just tried to install criterion with the current GHC HEAD, and `statistics` failed with this message: {{{ /home/jojo/.cabal/lib/x86_64-linux-ghc-7.9.20140609/math- functions-0.1.5.2/Numeric/Sum.hi Declaration for R:MVectorsKBNSum: Iface type variable out of scope: s Cannot continue after interface file error }}} I tried to reproduce this with smaller code than `statistics`, but could not trigger it. The interface dump gives me: {{{ 661d69e55c1491128ac1ed3c03f864e2 axiom TFCo:R:MVectorsKB2Sum:: Data.Vector.Unboxed.Base.MVector s0 Numeric.Sum.KB2Sum = Numeric.Sum.R:MVectorsKB2Sum s0 a69bb56c3760003bcb7d99cd40c3d843 axiom TFCo:R:MVectorsKBNSum:: Data.Vector.Unboxed.Base.MVector s0 Numeric.Sum.KBNSum = Numeric.Sum.R:MVectorsKBNSum s0 }}} ? not sure if there is a `forall` missing or note. Note that these data types are generated using template haskell [http://hdiff.luite.com/cgit /math- functions/tree/Numeric/Sum.hs?id=06b09eb4f110f99fb51a9ec0ec598fba54ac0986#n123 source]. In order to reproduce this, run someting like `cabal install --with-compiler=.../inplace/bin/ghc-stage2 --ghc- option=-XTypeFamilies .` in `statistics-0.11.0.3` with the attached patch applied. -- Comment (by simonpj): I tried reproducing this, but the `cabal install` process fell over much earlier in `mwc-random`: {{{ System\Random\MWC\Distributions.hs:83:5: Illegal equational constraint PrimState m ~ PrimState m (Use GADTs or TypeFamilies to permit this) When checking that `normalTail' has the inferred type `forall (m1 :: * -> *). (PrimMonad m1, PrimState m1 ~ PrimState m) => Bool -> m1 Double' In an equation for `standard': standard gen = loop where .... }}} This is more fallout from #8883. (The inferred type also looks ambiguous, but it isn't because the type variable `m` is free in the environment.) Very similar errors show up in `vector-algorithms`. Both are solved by `-XMonoLocalBinds`. I'm not sure why this didn't happen to you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 09:00:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 09:00:37 -0000 Subject: [GHC] #9190: Iface type variable out of scope: s In-Reply-To: <046.ae688232714aa8206efce4424bf2e376@haskell.org> References: <046.ae688232714aa8206efce4424bf2e376@haskell.org> Message-ID: <061.57c8bcf10b5a57ced45cf4f889700ef8@haskell.org> #9190: Iface type variable out of scope: s -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): You can work around this with passing `--ghc-option=-XTypeFamilies` to `cabal`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 09:00:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 09:00:47 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.4d6bf1029768ac6b135a081240dd8e0a@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------------------+-------------------------- Reporter: Blaisorblade | Owner: Type: bug | jstolarek Priority: normal | Status: closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: typecheck/should_fail/T8883 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by simonpj): See more fallout in #9190 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 09:04:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 09:04:24 -0000 Subject: [GHC] #9190: Iface type variable out of scope: s In-Reply-To: <046.ae688232714aa8206efce4424bf2e376@haskell.org> References: <046.ae688232714aa8206efce4424bf2e376@haskell.org> Message-ID: <061.f37079bf07d2b441ede61db9127c8abc@haskell.org> #9190: Iface type variable out of scope: s -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 09:14:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 09:14:24 -0000 Subject: [GHC] #9190: Iface type variable out of scope: s In-Reply-To: <046.ae688232714aa8206efce4424bf2e376@haskell.org> References: <046.ae688232714aa8206efce4424bf2e376@haskell.org> Message-ID: <061.dbb6ed60252d69ebfcf9a7decaf7268d@haskell.org> #9190: Iface type variable out of scope: s -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): If the above interface output is indeed a symptom of something being wrong, then this module (extracted from math-functions) suffices to reproduce it (still needs vector-th-unbox, slowly working towards less dependencies). I cannot trigger the the actual error with that, though. {{{ {-# LANGUAGE MultiParamTypeClasses, TemplateHaskell, TypeFamilies #-} module T9190a where import Data.Vector.Unboxed.Deriving (derivingUnbox) data KBNSum = KBNSum Double Double derivingUnbox "KBNSum" [t| KBNSum -> (Double, Double) |] [| \ (KBNSum a b) -> (a, b) |] [| \ (a, b) -> KBNSum a b |] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 09:25:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 09:25:27 -0000 Subject: [GHC] #9190: Iface type variable out of scope: s In-Reply-To: <046.ae688232714aa8206efce4424bf2e376@haskell.org> References: <046.ae688232714aa8206efce4424bf2e376@haskell.org> Message-ID: <061.45d9ab5f73c1b51f0b542603418624e9@haskell.org> #9190: Iface type variable out of scope: s -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): And finally, the last dependency not in GHC reduced to this module {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} module T9190b (derivingUnbox) where import Control.Applicative import Data.Vector.Unboxed.Base (MVector (..)) import Language.Haskell.TH derivingUnbox :: String -> TypeQ -> DecsQ derivingUnbox name argsQ = do let mvName = mkName $ "MV_" ++ name args <- argsQ (_, typ, rep) <- case args of ForallT _ cxts (ArrowT `AppT` typ `AppT` rep) -> return (cxts, typ, rep) ArrowT `AppT` typ `AppT` rep -> return ([], typ, rep) _ -> fail "Expecting a type of the form: cxts => typ -> rep" s <- VarT <$> newName "s" let newtypeMVector = NewtypeInstD [] ''MVector [s, typ] (NormalC mvName [(NotStrict, ConT ''MVector `AppT` s `AppT` rep)]) [] return [ newtypeMVector] }}} to be used with {{{ {-# LANGUAGE MultiParamTypeClasses, TemplateHaskell, TypeFamilies #-} module T9190a where import T9190b data KBNSum = KBNSum Double Double derivingUnbox "KBNSum" [t| KBNSum -> (Double, Double) |] }}} There we see a new variable `s` being introduced and put in the type of the newtype declaration. Is it TH?s responsibility to abstract over `s` here, or GHCs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 09:37:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 09:37:35 -0000 Subject: [GHC] #9193: GHC panic usinig HList and Lens Message-ID: <046.9f95251275f5e9d2bafb5ce9f0fa0ed3@haskell.org> #9193: GHC panic usinig HList and Lens -------------------------------------------+------------------------------- Reporter: maxigit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: x86 | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- This bug might have been fixed in GHC 7.8.2 but I haven't been able to test it. Some packages required to reproduce the bug are broken under 7.8.*. GHC 'panic' whilst trying to compile the following. Strangely, removing doing the last line of code 'manually' in ghci works. {{{ {-# LANGUAGE TypeFamilies, DataKinds, PolyKinds, TypeOperators #-} {-# LANGUAGE NoMonomorphismRestriction #-} module Database.Harehouse.SQLFragment where import Data.HList import Control.Lens hiding(from) x = hLens' (Label :: Label "x") }}} Note. I'm using HList-0.3.4.1 and lens-4.1.2.1. I think it wasn't working with lens 4.2 either, but since I tried to install ghc 7.8.2 I haven't be able to reinstall lens 4.2. (cabal hell). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 09:52:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 09:52:06 -0000 Subject: [GHC] #9193: GHC panic usinig HList and Lens In-Reply-To: <046.9f95251275f5e9d2bafb5ce9f0fa0ed3@haskell.org> References: <046.9f95251275f5e9d2bafb5ce9f0fa0ed3@haskell.org> Message-ID: <061.4f3d436a9867fd233aa5613836e9788e@haskell.org> #9193: GHC panic usinig HList and Lens -------------------------------+------------------------------------------- Reporter: maxigit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by archblob): Everything works with 7.8.2. What was the panic about exactly ? Is this the complete code that caused the problem ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 10:02:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 10:02:35 -0000 Subject: [GHC] #9193: GHC panic usinig HList and Lens In-Reply-To: <046.9f95251275f5e9d2bafb5ce9f0fa0ed3@haskell.org> References: <046.9f95251275f5e9d2bafb5ce9f0fa0ed3@haskell.org> Message-ID: <061.3cba2a31512cfb9b3a221c9c724c8fdf@haskell.org> #9193: GHC panic usinig HList and Lens -------------------------------+------------------------------------------- Reporter: maxigit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by maxigit): There is only one line of code ... I get the following error message {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): lookupVers2 <
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} So I did I. As I said I tried with 7.8.2 but I couldn't install some dependencies which are mainly text and distributive :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 10:38:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 10:38:34 -0000 Subject: [GHC] #9190: Iface type variable out of scope: s In-Reply-To: <046.ae688232714aa8206efce4424bf2e376@haskell.org> References: <046.ae688232714aa8206efce4424bf2e376@haskell.org> Message-ID: <061.54f0aa9d712e4b5701dfab1c32f35fec@haskell.org> #9190: Iface type variable out of scope: s -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Further reduced the problem: {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} module T9190b where import Language.Haskell.TH data family Family a b foo :: DecsQ foo = do s <- VarT `fmap` newName "s" return [ NewtypeInstD [] ''Family [s, ConT ''Double] (NormalC (mkName "Foo") [(NotStrict, TupleT 0) ]) [] ] }}} and {{{ {-# LANGUAGE TypeFamilies, TemplateHaskell #-} module T9190a where import T9190b foo }}} yields {{{ b179ce4def4d6d8b892ce82aab2d2a37 newtype instance T9190b.Family s GHC.Types.Double = Foo () RecFlag: Recursive b179ce4def4d6d8b892ce82aab2d2a37 axiom TFCo:R:FamilysDouble:: T9190b.Family s0 GHC.Types.Double = T9190a.R:FamilysDouble s0 family instance T9190b.Family [.], [GHC.Types.Double] = T9190a.TFCo:R:FamilysDouble }}} I?m off traveling to OPSLL, but I hope that this makes it easier for someone else to pick up the issue. (But maybe I?m completely off the track here, and the interface is actually fine ? I just discovered that with `-fprint-explicit-foralls` this reads {{{ b179ce4def4d6d8b892ce82aab2d2a37 axiom TFCo:R:FamilysDouble:: forall s0. T9190b.Family s0 GHC.Types.Double = T9190a.R:FamilysDouble s0 }}} and this hiding of `forall` is new in 7.8 or 7.9 compared to 7.6, which had printed the `s0` directly. :-( ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 10:42:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 10:42:16 -0000 Subject: [GHC] #9187: Reduce number of missing wiki links by setting ignore_missing_pages in TracIni In-Reply-To: <045.4d53bdd0b5be9010b74f4b8918421269@haskell.org> References: <045.4d53bdd0b5be9010b74f4b8918421269@haskell.org> Message-ID: <060.0a637d174de3c2988f49bb76ff7617e6@haskell.org> #9187: Reduce number of missing wiki links by setting ignore_missing_pages in TracIni -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 10:59:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 10:59:10 -0000 Subject: [GHC] #9193: GHC panic usinig HList and Lens In-Reply-To: <046.9f95251275f5e9d2bafb5ce9f0fa0ed3@haskell.org> References: <046.9f95251275f5e9d2bafb5ce9f0fa0ed3@haskell.org> Message-ID: <061.389ae825f6eae7205e978defbd4f75c2@haskell.org> #9193: GHC panic usinig HList and Lens -------------------------------+------------------------------------------- Reporter: maxigit | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Perhaps a dup of #8230, #8225, #7502? I'll close as fixed, but reopen if you disagree. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 11:07:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 11:07:54 -0000 Subject: [GHC] #9193: GHC panic usinig HList and Lens In-Reply-To: <046.9f95251275f5e9d2bafb5ce9f0fa0ed3@haskell.org> References: <046.9f95251275f5e9d2bafb5ce9f0fa0ed3@haskell.org> Message-ID: <061.904dd051c1ec00ec2e2144519562efb1@haskell.org> #9193: GHC panic usinig HList and Lens -------------------------------+------------------------------------------- Reporter: maxigit | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by maxigit): It's definitely a duplicate of #8225 : adding {{{ import GHC.TypeLits }}} solves the problem. This workaround should be enough until I can get 7.8.* working. Thank you very much for your really quick answers. Max -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 11:40:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 11:40:26 -0000 Subject: [GHC] #9115: The kind of (=>) In-Reply-To: <047.79a80bb2b897dcc6ec2d89a1e91dba60@haskell.org> References: <047.79a80bb2b897dcc6ec2d89a1e91dba60@haskell.org> Message-ID: <062.712dfbd5240c102800c575b4adcf07f3@haskell.org> #9115: The kind of (=>) -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: new => closed * resolution: => wontfix Comment: I will close, but your post made me realize something. Instead of writing `(Eq a, Show a, Read a) => a -> a`, I can write `Eq a => Show a => Read a => a -> a`, which I somehow like more. Haven't checked how it Haddocks, though... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 12:20:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 12:20:29 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.7823f03eba1c8ad0ddb9c5de656c755a@haskell.org> #9163: Ptr should have a phantom role ------------------------------------------------+-------------------------- Reporter: simonpj | Owner: Type: bug | goldfire Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: roles/should_compile/Roles2 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: #9164 ------------------------------------------------+-------------------------- Changes (by goldfire): * testcase: => roles/should_compile/Roles2 Comment: Patch on the way... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 12:21:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 12:21:06 -0000 Subject: [GHC] #9062: Role: ~# should be ~R# In-Reply-To: <044.7f1566c191cb9df0ca4c1915de3a4096@haskell.org> References: <044.7f1566c191cb9df0ca4c1915de3a4096@haskell.org> Message-ID: <059.2419abeffd0d19ff32a1b3f9f36c63e1@haskell.org> #9062: Role: ~# should be ~R# -------------------------------------------------+------------------------- Reporter: conal | Owner: Type: bug | goldfire Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: 7.8.2 Operating System: MacOS X | Keywords: Type of failure: None/Unknown | Architecture: Test Case: roles/should_compile/Roles13 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * testcase: => roles/should_compile/Roles13 Comment: Patch on the way... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 12:25:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 12:25:07 -0000 Subject: [GHC] #9097: Change GHC.Exts.Any to a type family In-Reply-To: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> References: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> Message-ID: <062.f76bc8b7ca865c3c31b69d3e0c4d2b96@haskell.org> #9097: Change GHC.Exts.Any to a type family -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: task | goldfire Priority: high | Status: new Component: Compiler | Milestone: Resolution: | 7.10.1 Operating System: Unknown/Multiple | Version: 7.8.2 Type of failure: None/Unknown | Keywords: Test Case: indexed- | Architecture: types/should_fail/T9097 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * testcase: => indexed-types/should_fail/T9097 Comment: Patch on the way... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 12:29:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 12:29:51 -0000 Subject: [GHC] #9085: Inaccessible equations in a closed type family should be a warning, not an error In-Reply-To: <047.6f253560297252689a57f29dc4617e22@haskell.org> References: <047.6f253560297252689a57f29dc4617e22@haskell.org> Message-ID: <062.ec52dd2192000ced56d324f759542f37@haskell.org> #9085: Inaccessible equations in a closed type family should be a warning, not an error -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | goldfire Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: indexed- | Unknown/Multiple types/should_compile/T9085 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * testcase: => indexed-types/should_compile/T9085 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 12:33:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 12:33:49 -0000 Subject: [GHC] #7673: Windows: run "git config --global core.autocrlf false" before cloning the repo In-Reply-To: <047.12821fb51193c8ec9bb34376058ac256@haskell.org> References: <047.12821fb51193c8ec9bb34376058ac256@haskell.org> Message-ID: <062.8cf9643cc51310b935334b828cdc84fb@haskell.org> #7673: Windows: run "git config --global core.autocrlf false" before cloning the repo -------------------------------+------------------------------------ Reporter: morabbin | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------ Changes (by thomie): * status: closed => new * cc: hvr (added) * component: Compiler => Trac & Git * version: 7.6.2 => * owner: => hvr * resolution: fixed => Comment: Running {{{./sync-all get}}} will now execute {{{'git reset --hard'}}} if core.autocrlf=true, which could result in data loss when uncommitted changes are present. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 12:34:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 12:34:26 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.c71127112c5630c12eaa970490a4e991@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -----------------------------------------------+--------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: libraries/base/tests/T9111 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Changes (by goldfire): * testcase: => libraries/base/tests/T9111 Comment: Patch on the way... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 12:43:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 12:43:36 -0000 Subject: [GHC] #9194: Remove magic parsing of (~) Message-ID: <047.22060322fda4067ab1167cb54140f19a@haskell.org> #9194: Remove magic parsing of (~) ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It seems that `(~)` has magical parsing: {{{ Prelude> :i (~) :1:2: parse error on input ?~? Prelude> :k (~) (~) :: k -> k -> Constraint Prelude> :i (+) -- for comparison class Num a where (+) :: a -> a -> a ... -- Defined in ?GHC.Num? infixl 6 + }}} Now that type operators do not need to start with a colon, this magic seems unnecessary. The `(~)` syntax does not need to be wired-in, unless I'm missing something. (The ''definition'' of `(~)` needs to be wired in -- it's just the syntax that doesn't need to be.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 12:45:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 12:45:35 -0000 Subject: [GHC] #9194: Remove magic parsing of (~) In-Reply-To: <047.22060322fda4067ab1167cb54140f19a@haskell.org> References: <047.22060322fda4067ab1167cb54140f19a@haskell.org> Message-ID: <062.41c0ee4a85385485756ed266f04a24dd@haskell.org> #9194: Remove magic parsing of (~) -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I suppose this means that it should be exported from `Prelude` and be hidable, available for user definitions, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 12:49:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 12:49:49 -0000 Subject: [GHC] #9097: Change GHC.Exts.Any to a type family In-Reply-To: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> References: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> Message-ID: <062.78d3dfd8e0931a73bc887e6563950aa5@haskell.org> #9097: Change GHC.Exts.Any to a type family -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: task | goldfire Priority: high | Status: new Component: Compiler | Milestone: Resolution: | 7.10.1 Operating System: Unknown/Multiple | Version: 7.8.2 Type of failure: None/Unknown | Keywords: Test Case: indexed- | Architecture: types/should_fail/T9097 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:18:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:18:07 -0000 Subject: [GHC] #9183: GHC shouldn't expand constraint synonyms In-Reply-To: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> References: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> Message-ID: <063.cc93e2cb523a46e47178224e495b8adc@haskell.org> #9183: GHC shouldn't expand constraint synonyms -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Feuerbach): I just assumed this can be similar to how ghc doesn't expand ordinary type synonyms unless necessary, but from what you're saying it sounds like it's different for constraints? An even more important feature would be to preserve the synonym names in type errors. That'd allow to make such errors more domain-specific and informative, while an expanded version is very complex and essentially reveals a lot of internal details of the library. Would it make sense to have something like {{{ newtype MyConstraint (a :: *) = MyConstraint (Show a, Eq a, Num a) :: Constraint }}} or {{{ data MyConstraint (a :: *) = MyConstraint (Show a) (Eq a) (Num a) :: Constraint }}} that wouldn't expand automatically? Just like we can improve the quality of error messages in ordinary Haskell by replacing type synonyms with newtypes or data types? (I don't have a clear vision of how this should work; this is just an idea.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:31:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:31:58 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.695aecb23a571ef1e0308a00e00d4016@haskell.org> #9163: Ptr should have a phantom role ------------------------------------------------+-------------------------- Reporter: simonpj | Owner: Type: bug | goldfire Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: roles/should_compile/Roles2 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: #9164 ------------------------------------------------+-------------------------- Comment (by Richard Eisenberg ): In [changeset:"9e6c6b4206cd893434e49cd893eb67081eeffe99/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9e6c6b4206cd893434e49cd893eb67081eeffe99" Make FunPtr's role be phantom; add comments. This change also updates castFunPtr to make it free at runtime. This fixes #9163. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:31:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:31:58 -0000 Subject: [GHC] #9167: Associated type is accepted even without mentioning class parameters In-Reply-To: <047.2d5de3ba88af5354277dc53a66fecc69@haskell.org> References: <047.2d5de3ba88af5354277dc53a66fecc69@haskell.org> Message-ID: <062.8dfa15c7272521aeb0b85c6199e273ee@haskell.org> #9167: Associated type is accepted even without mentioning class parameters -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: low | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple indexed_types/should_fail/T9167 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Richard Eisenberg ): In [changeset:"1153194ca1ec867ca01675a902cdf7dab72b5dab/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1153194ca1ec867ca01675a902cdf7dab72b5dab" Clarify error message. See #9167. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:31:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:31:59 -0000 Subject: [GHC] #9097: Change GHC.Exts.Any to a type family In-Reply-To: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> References: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> Message-ID: <062.83b17bc33a9f10ca56e09caf99364f8a@haskell.org> #9097: Change GHC.Exts.Any to a type family -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: task | goldfire Priority: high | Status: new Component: Compiler | Milestone: Resolution: | 7.10.1 Operating System: Unknown/Multiple | Version: 7.8.2 Type of failure: None/Unknown | Keywords: Test Case: indexed- | Architecture: types/should_fail/T9097 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Richard Eisenberg ): In [changeset:"051d694fc978ad28ac3043d296cafddd3c2a7050/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="051d694fc978ad28ac3043d296cafddd3c2a7050" Fix #9097. `Any` is now an abstract (that is, no equations) closed type family. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:31:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:31:59 -0000 Subject: [GHC] #9085: Inaccessible equations in a closed type family should be a warning, not an error In-Reply-To: <047.6f253560297252689a57f29dc4617e22@haskell.org> References: <047.6f253560297252689a57f29dc4617e22@haskell.org> Message-ID: <062.932679101e9fc4b1d640634b224e3736@haskell.org> #9085: Inaccessible equations in a closed type family should be a warning, not an error -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | goldfire Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: indexed- | Unknown/Multiple types/should_compile/T9085 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Richard Eisenberg ): In [changeset:"6a1d7f9736098d47463a71323d28ece792a59e52/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6a1d7f9736098d47463a71323d28ece792a59e52" Fix #9085. Inaccessible equations in a closed type family now leads to a warning, not an error. This echoes what happens at the term level. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:31:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:31:59 -0000 Subject: [GHC] #9062: Role: ~# should be ~R# In-Reply-To: <044.7f1566c191cb9df0ca4c1915de3a4096@haskell.org> References: <044.7f1566c191cb9df0ca4c1915de3a4096@haskell.org> Message-ID: <059.f94d206ba2d805c534c97288f692a035@haskell.org> #9062: Role: ~# should be ~R# -------------------------------------------------+------------------------- Reporter: conal | Owner: Type: bug | goldfire Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: 7.8.2 Operating System: MacOS X | Keywords: Type of failure: None/Unknown | Architecture: Test Case: roles/should_compile/Roles13 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Richard Eisenberg ): In [changeset:"e79e2c3996181a1179cf4a1357981f4ed9759203/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e79e2c3996181a1179cf4a1357981f4ed9759203" Fix #9062. Removed (pprEqPred (coercionKind co)) in favor of (pprType (coercionType co)). Also had to make "~R#" a *symbolic* identifier and BuiltInSyntax to squelch prefix notation and module prefixes in output. These changes are both sensible independent of #9062. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:31:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:31:59 -0000 Subject: [GHC] #9097: Change GHC.Exts.Any to a type family In-Reply-To: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> References: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> Message-ID: <062.fc2e0b28bd21b090433255bf1c1fd699@haskell.org> #9097: Change GHC.Exts.Any to a type family -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: task | goldfire Priority: high | Status: new Component: Compiler | Milestone: Resolution: | 7.10.1 Operating System: Unknown/Multiple | Version: 7.8.2 Type of failure: None/Unknown | Keywords: Test Case: indexed- | Architecture: types/should_fail/T9097 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Richard Eisenberg ): In [changeset:"7b10d013a50a9fe4f100a2cb8b02a28e8d398357/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7b10d013a50a9fe4f100a2cb8b02a28e8d398357" Test #9097. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:32:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:32:05 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.7a47f4aa86c83e73610a7b0fbe9eb301@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -----------------------------------------------+--------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: libraries/base/tests/T9111 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Comment (by Richard Eisenberg ): In [changeset:"9dbf3409716fe0ec2a57688124d1ee903db77f0e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9dbf3409716fe0ec2a57688124d1ee903db77f0e" Fix #9111. Data.Typeable.Internal should now derive instances for all types defined in modules beneath it. Still to do: Typeable instances for type literals, but that's a very separate matter. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:32:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:32:06 -0000 Subject: [GHC] #9085: Inaccessible equations in a closed type family should be a warning, not an error In-Reply-To: <047.6f253560297252689a57f29dc4617e22@haskell.org> References: <047.6f253560297252689a57f29dc4617e22@haskell.org> Message-ID: <062.ec740da7be09301e6271e3053878d9dc@haskell.org> #9085: Inaccessible equations in a closed type family should be a warning, not an error -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | goldfire Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: indexed- | Unknown/Multiple types/should_compile/T9085 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Richard Eisenberg ): In [changeset:"f502617065c8716a062c83fc923c3b3a2395c4a8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f502617065c8716a062c83fc923c3b3a2395c4a8" Test #9085. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:32:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:32:06 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.dbf12be51b34c6b8aa70bd5d79f66e6f@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -----------------------------------------------+--------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: libraries/base/tests/T9111 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Comment (by Richard Eisenberg ): In [changeset:"f73d42f0c88153bcfec23d8f35d0721272539867/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f73d42f0c88153bcfec23d8f35d0721272539867" Test #9111. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:35:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:35:17 -0000 Subject: [GHC] #9183: GHC shouldn't expand constraint synonyms In-Reply-To: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> References: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> Message-ID: <063.7243d849ba8c445cfd18a529bf21d9d2@haskell.org> #9183: GHC shouldn't expand constraint synonyms -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): You can do the `MyConstraint` trick today: {{{ class (Show a, Eq a, Num a) => MyConstraint a instance (Show a, Eq a, Num a) => MyConstraint a }}} Haven't tested this in error messages, exactly, but my guess is that it will behave better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:36:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:36:17 -0000 Subject: [GHC] #9062: Role: ~# should be ~R# In-Reply-To: <044.7f1566c191cb9df0ca4c1915de3a4096@haskell.org> References: <044.7f1566c191cb9df0ca4c1915de3a4096@haskell.org> Message-ID: <059.8256649706286914d3bad3bb37125626@haskell.org> #9062: Role: ~# should be ~R# -------------------------------------------------+------------------------- Reporter: conal | Owner: Type: bug | goldfire Priority: normal | Status: Component: Compiler | closed Resolution: fixed | Milestone: Operating System: MacOS X | Version: 7.8.2 Type of failure: None/Unknown | Keywords: Test Case: roles/should_compile/Roles13 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:36:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:36:54 -0000 Subject: [GHC] #9097: Change GHC.Exts.Any to a type family In-Reply-To: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> References: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> Message-ID: <062.379663ec850fc7a6cbbf16bd30ced251@haskell.org> #9097: Change GHC.Exts.Any to a type family -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: task | goldfire Priority: high | Status: Component: Compiler | closed Resolution: fixed | Milestone: Operating System: Unknown/Multiple | 7.10.1 Type of failure: None/Unknown | Version: 7.8.2 Test Case: indexed- | Keywords: types/should_fail/T9097 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:38:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:38:46 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.5981260a699eb85c728828e1a2da1ba6@haskell.org> #9163: Ptr should have a phantom role ------------------------------------------------+-------------------------- Reporter: simonpj | Owner: Type: bug | goldfire Priority: normal | Status: merge Component: Compiler | Milestone: 7.8.4 Resolution: | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: roles/should_compile/Roles2 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: #9164 ------------------------------------------------+-------------------------- Changes (by goldfire): * status: new => merge * milestone: => 7.8.4 Comment: I believe this closes this ticket. Suggesting merging because of related performance improvement, but it's not critical. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:40:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:40:21 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.12526b7d3803376d2b26d98b9772d111@haskell.org> #9163: Ptr should have a phantom role ------------------------------------------------+-------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: roles/should_compile/Roles2 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #9164 ------------------------------------------------+-------------------------- Changes (by goldfire): * owner: goldfire => * status: merge => new Comment: Can't disown a "merge" ticket. Reopening to disown. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:40:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:40:40 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.cdc1f04c578c767c2b99fdbf0f464bac@haskell.org> #9163: Ptr should have a phantom role ------------------------------------------------+-------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: roles/should_compile/Roles2 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #9164 ------------------------------------------------+-------------------------- Changes (by goldfire): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:40:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:40:42 -0000 Subject: [GHC] #9183: GHC shouldn't expand constraint synonyms In-Reply-To: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> References: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> Message-ID: <063.2fae0dc7556fcd27a822d5f248c426ed@haskell.org> #9183: GHC shouldn't expand constraint synonyms -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Feuerbach): Ah, right! I've used this trick in the past many times, but every now and then I get lured by the nice-looking constraint synonyms, and forget about the alternative. So, it looks like the semantics is not a problem. Perhaps it'd be possible to introduce a better syntax for it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:44:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:44:33 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.ef48d2b1c5aec02e1695f62e7e54cec8@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -----------------------------------------------+--------------------------- Reporter: goldfire | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: libraries/base/tests/T9111 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: The above commit should make all `base` types be `Typeable`, along with promoted data constructors. See #8778 about `Typeable` for `Nat` and `Symbol` types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:46:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:46:24 -0000 Subject: [GHC] #9183: GHC shouldn't expand constraint synonyms In-Reply-To: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> References: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> Message-ID: <063.52cf623ee9bb3990a61f63eebf6b9d71@haskell.org> #9183: GHC shouldn't expand constraint synonyms -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Have you tested this idea in your use case? Do the error messages improve? Personally, I don't think it's necessary to introduce a new syntax for this idiom (just one more thing to remember/maintain), but I don't feel strongly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:46:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:46:37 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.6d0802ac45b00f6d1943ccb151f0862c@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Changes (by crockeea): * cc: ecrockett0@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:48:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:48:42 -0000 Subject: [GHC] #9085: Inaccessible equations in a closed type family should be a warning, not an error In-Reply-To: <047.6f253560297252689a57f29dc4617e22@haskell.org> References: <047.6f253560297252689a57f29dc4617e22@haskell.org> Message-ID: <062.7def864d2bb554f213c2f7aebabcf0e4@haskell.org> #9085: Inaccessible equations in a closed type family should be a warning, not an error -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | goldfire Priority: normal | Status: merge Component: Compiler | Milestone: 7.8.4 Resolution: | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: indexed- | Unknown/Multiple types/should_compile/T9085 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * status: new => merge * milestone: => 7.8.4 Comment: Recommending merge, but this is really minor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:50:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:50:10 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.d1afbeadfe013033648ae24560af9a7e@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Changes (by archblob): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:50:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:50:14 -0000 Subject: [GHC] #9183: GHC shouldn't expand constraint synonyms In-Reply-To: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> References: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> Message-ID: <063.70bf5e932f285bc582b7eaa3f0a128c4@haskell.org> #9183: GHC shouldn't expand constraint synonyms -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Feuerbach): Just tested it ? doesn't seem to work. {{{ {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} class Show a => MyC a instance Show a => MyC a foo :: MyC a => a -> String foo = show }}} :t foo shows {{{ foo :: Show a => a -> String }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:52:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:52:30 -0000 Subject: [GHC] #9183: GHC shouldn't expand constraint synonyms In-Reply-To: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> References: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> Message-ID: <063.2f9781a84cd6f61e5f119ba6cd63d545@haskell.org> #9183: GHC shouldn't expand constraint synonyms -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): That doesn't surprise me terribly, because of the reasons Simon cites above. How does it work in proper error messages, though? I think more care is taken there than in `:t`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 13:54:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 13:54:57 -0000 Subject: [GHC] #9097: Change GHC.Exts.Any to a type family In-Reply-To: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> References: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> Message-ID: <062.2bde2786955e7d0da485f868c75691c7@haskell.org> #9097: Change GHC.Exts.Any to a type family -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: task | goldfire Priority: high | Status: Component: Compiler | closed Resolution: fixed | Milestone: Operating System: Unknown/Multiple | 7.10.1 Type of failure: None/Unknown | Version: 7.8.2 Test Case: indexed- | Keywords: types/should_fail/T9097 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): Richard: excellent, thank you. But could you add some comments with the defn of `Any` that explain the subtleties. There is a very good reason why `Any` should be a type family, and this should be noted (with a pointer to this ticket). And there was a very good reason that it initially was a data type, and this too might be worth noting. The diffs don't seem to cover these points unless I'm mis-reading. thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 14:00:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 14:00:19 -0000 Subject: [GHC] #9183: GHC shouldn't expand constraint synonyms In-Reply-To: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> References: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> Message-ID: <063.6d3aeea1e55991649067cf88b880ee9d@haskell.org> #9183: GHC shouldn't expand constraint synonyms -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Feuerbach): Doesn't help there, either. {{{ *Main> foo id :13:1: No instance for (Show (a0 -> a0)) arising from a use of ?foo? In the expression: foo id In an equation for ?it?: it = foo id }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 14:02:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 14:02:16 -0000 Subject: [GHC] #9097: Change GHC.Exts.Any to a type family In-Reply-To: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> References: <047.47dea3c2ecf59fa4dca4d4cf3a712a78@haskell.org> Message-ID: <062.575cfbd017ade055f54985003e4d01b6@haskell.org> #9097: Change GHC.Exts.Any to a type family -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: task | goldfire Priority: high | Status: Component: Compiler | closed Resolution: fixed | Milestone: Operating System: Unknown/Multiple | 7.10.1 Type of failure: None/Unknown | Version: 7.8.2 Test Case: indexed- | Keywords: types/should_fail/T9097 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): You're absolutely right that the diffs don't cover this -- that's because the explanation was already there: {{{ Note [Any types] ~~~~~~~~~~~~~~~~ The type constructor Any of kind forall k. k has these properties: ... * It is a *closed* type family, with no instances. This means that if ty :: '(k1, k2) we add a given coercion g :: ty ~ (Fst ty, Snd ty) If Any was a *data* type, then we'd get inconsistency because 'ty' could be (Any '(k1,k2)) and then we'd have an equality with Any on one side and '(,) on the other. See also #9097. ... }}} It seems that this comment was left when you reverted the last time you made this change. Well, it's now correct again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 14:03:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 14:03:32 -0000 Subject: [GHC] #9183: GHC shouldn't expand constraint synonyms In-Reply-To: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> References: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> Message-ID: <063.c78e9c5c0658f06175d6119bea6f53c5@haskell.org> #9183: GHC shouldn't expand constraint synonyms -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Hm. I guess this fruit isn't as low-hanging as I thought... deferring to others for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 14:47:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 14:47:06 -0000 Subject: [GHC] #9183: GHC shouldn't expand constraint synonyms In-Reply-To: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> References: <048.2da606d7e452dc3338ae8c1f7a883333@haskell.org> Message-ID: <063.850372212a030b34392d2ba17cc90e1f@haskell.org> #9183: GHC shouldn't expand constraint synonyms -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I really don't see what we can reasonably do here. e.g. {{{ type Foo a = (Eq a, Ix a) }}} Now if you instantiate and re-generalise it's really not possible to reconstruct the `Foo a`. I suppose you could have a magical special case when there is a type synonym for a single constraint. That might, just, be possible. But it'd be a bit of effort to push it through, so I propose to wait until more people yell. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 14:53:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 14:53:48 -0000 Subject: [GHC] #9194: Remove magic parsing of (~) In-Reply-To: <047.22060322fda4067ab1167cb54140f19a@haskell.org> References: <047.22060322fda4067ab1167cb54140f19a@haskell.org> Message-ID: <062.a0290cc739fbc9a28bb74be6574ea206@haskell.org> #9194: Remove magic parsing of (~) -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Yes, I suspect that `(~)` pre-dated `-XTypeOperators`. Good idea: I'd be happy if someone did this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 15:40:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 15:40:22 -0000 Subject: [GHC] #9194: Remove magic parsing of (~) In-Reply-To: <047.22060322fda4067ab1167cb54140f19a@haskell.org> References: <047.22060322fda4067ab1167cb54140f19a@haskell.org> Message-ID: <062.26be2e7365f3a5699692a55f23796151@haskell.org> #9194: Remove magic parsing of (~) -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Replying to [comment:2 simonpj]: > Yes, I suspect that `(~)` pre-dated `-XTypeOperators`. And, crucially, allowing type operators to skip the opening colon. Your comment does make me think that this change would then require users to specify `TypeOperators` whenever they use `(~)`. This would be a breaking change that would likely affect a lot of code, and perhaps for little gain. We could just special-case `(~)` not to require `TypeOperators`, but is that any better than the status quo? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 19:22:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 19:22:38 -0000 Subject: [GHC] #9046: Panic in GHCi when using :print In-Reply-To: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> References: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> Message-ID: <060.243db0b534f7ee69d5bc79f7b9f0aad2@haskell.org> #9046: Panic in GHCi when using :print -------------------------------------+------------------------------------ Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by archblob): For `:info _t1` we get: {{{ WARNING: file compiler/main/PprTyThing.hs, line 153 _t1 _t1 :: Num t => [t] -- Defined at }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 19:43:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 19:43:48 -0000 Subject: [GHC] #9195: ImpredicativeTypes and ConstraintKinds don't interact as expected Message-ID: <050.891dda4540243320d80c0b42f302fbb5@haskell.org> #9195: ImpredicativeTypes and ConstraintKinds don't interact as expected ----------------------------+---------------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Given this code: {{{ {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, ImpredicativeTypes, ConstraintKinds #-} class P a b instance P a b type Test a = forall b. P a b }}} I would expect to be able to actually use the Test Constraint in a function, like so: {{{ foo :: Test a => a -> a foo = id }}} But GHC complains that: {{{ Illegal polymorphic or qualified type: Test a In the type signature for ?foo?: foo :: Test a => a -> a }}} I get the exact same error message if I replace ImpredicativeTypes with RankNTypes. If this is intended behavior under ImpredicativeTypes, how difficult would it be to add another extension that allows this type of polymorphism? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 19:57:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 19:57:07 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.3506f1c789406a0f97327774da47dded@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------------------+-------------------------- Reporter: Blaisorblade | Owner: Type: bug | jstolarek Priority: normal | Status: closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: typecheck/should_fail/T8883 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Simon Peyton Jones ): In [changeset:"56f8777f99d9fd849ca6f1151fead3f62707f308/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="56f8777f99d9fd849ca6f1151fead3f62707f308" Improve error message in Trac #8883 The improvement is to report the inferred type in the error message, as suggested in email on ghc-deves (10 Jun 14). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 19:57:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 19:57:08 -0000 Subject: [GHC] #9190: Iface type variable out of scope: s In-Reply-To: <046.ae688232714aa8206efce4424bf2e376@haskell.org> References: <046.ae688232714aa8206efce4424bf2e376@haskell.org> Message-ID: <061.4bcd5833fdcb70d508b3125e585a0e81@haskell.org> #9190: Iface type variable out of scope: s -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"e5257f8fe20f5278c23693f1523e298e6fdaa064/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e5257f8fe20f5278c23693f1523e298e6fdaa064" Fix tyConToIfaceDecl (Trac #9190) There are three bugs here, one serious * We were failing to tidy the type arguments in an IfTyConParent This is what was causing Trac #9190. * toIfaceTcArgs is careful to suppress kind arguments, but there was a clone, tidyToIfaceTcArgs in IfaceSyn which didn't. Now the latter goes via the former. * When pretty-printing a IfaceDecl for an algebraic data type, and doing so in Haskell-98 syntax, we were silently assuming that the universal type variables of the TyCon and the DataCon were the same. But that has not been true for some time. Result: a very confusing display. Solution: during the conversion to IfaceSyn, take the opportunity to make the universal type variables line up exactly. This is very easy to do, makes the pretty-printing easy, and leaves open the future possiblity of not serialising the universal type variables of the data constructor. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 19:57:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 19:57:08 -0000 Subject: [GHC] #9128: Possible bug in strictness analyzer when where clause declared NOINLINE In-Reply-To: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> References: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> Message-ID: <060.6e0df861143f822a8e72eec8ed60548d@haskell.org> #9128: Possible bug in strictness analyzer when where clause declared NOINLINE ---------------------------------+----------------------------------------- Reporter: aalevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strictness bytestring Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | ---------------------------------+----------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7d9feb264a4fc3c15d1e5f88f2e7a04202ed9743/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7d9feb264a4fc3c15d1e5f88f2e7a04202ed9743" Fix a serious, but rare, strictness analyser bug (Trac #9128) In a special case for trivial RHSs (see DmdAnal.unpackTrivial), I'd forgotten to include a demand for the RHS itself. See Note [Remember to demand the function itself]. Thanks to David Terei for guiding me to the bug, at PLDI in Edinburgh. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 19:57:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 19:57:09 -0000 Subject: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS In-Reply-To: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> References: <045.715babeb9b3b7ae09fbdae7fcb37f116@haskell.org> Message-ID: <060.0199595602fddc8a1a5b5ccda77b4e14@haskell.org> #4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7f467d0fbb1424f638a0d39caf57b9c0198421a8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7f467d0fbb1424f638a0d39caf57b9c0198421a8" Fix Windows build (wibble to fix for Trac #4934) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 20:19:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 20:19:02 -0000 Subject: [GHC] #95: GHCi :edit command should jump to the the last error In-Reply-To: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> References: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> Message-ID: <067.6574dc2198ffd932f3914193d5fe9cfe@haskell.org> #95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: lortabac martijnislief | Status: patch Type: feature | Milestone: ? request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: None | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by lortabac): I added a `sameFile` function to check whether two paths point to the same file. However I can't find any readable alternative to: {{{ curFileErrs <- filterM (\(f, _) -> unpackFS f `sameFile` file) errs return $ case curFileErrs of (_, line):_ -> " +" ++ show line _ -> "" }}} As far as the test is concerned, I just followed the enumeration in the ghci directory, so I called it `prog013`. It would be nice to make it a bit more self-descriptive but I have no idea how. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 20:50:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 20:50:07 -0000 Subject: [GHC] #9196: Higher-rank constraint treated as type instead Message-ID: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> #9196: Higher-rank constraint treated as type instead ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE RankNTypes #-} module Bug where class P z foo :: (forall b. P (a, b)) => a -> a foo x = x }}} I get {{{ Bug.hs:7:9: Couldn't match expected type ?a -> a? with actual type ?P (a, b0)? Relevant bindings include x :: forall b. P (a, b) (bound at Bug.hs:7:5) foo :: (forall b. P (a, b)) -> a -> a (bound at Bug.hs:7:1) In the expression: x In an equation for ?foo?: foo x = x }}} I expected my code to be rejected, but not with that error message. It seems that GHC thinks `forall b. P (a, b))` has kind `*`, not kind `Constraint`. Encountered while experimenting with #9195. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 21:07:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 21:07:38 -0000 Subject: [GHC] #9168: reading/writing blocking FDs over FD_SETSIZE is broken In-Reply-To: <047.7e804364d376ec9b9bd7772943568384@haskell.org> References: <047.7e804364d376ec9b9bd7772943568384@haskell.org> Message-ID: <062.29398b8760eaa1df67faf7e6e64e5d25@haskell.org> #9168: reading/writing blocking FDs over FD_SETSIZE is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nicolast): Can't the changes from #4934 (9fd507e5758f4141ac2619f0db57136bcab035c6) trigger this as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 21:18:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 21:18:34 -0000 Subject: [GHC] #9128: Possible bug in strictness analyzer when where clause declared NOINLINE In-Reply-To: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> References: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> Message-ID: <060.6716d5db66a7f4ee963259e63eb1b9c4@haskell.org> #9128: Possible bug in strictness analyzer when where clause declared NOINLINE -------------------------------------+------------------------------------- Reporter: aalevy | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strictness Operating System: Linux | bytestring Type of failure: Runtime crash | Architecture: x86_64 (amd64) Test Case: | Difficulty: Unknown simplCore/should_run/T9128 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => simplCore/should_run/T9128 * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 22:40:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 22:40:31 -0000 Subject: [GHC] #9197: FFI types should be usable in foreign import decls without revealing representations Message-ID: <045.1e66fe66ff436f9c3e1f990da91bd5b9@haskell.org> #9197: FFI types should be usable in foreign import decls without revealing representations ------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This is another go at #5529 but with, we hope, clearer and better arguments. The original FFI spec defined a whole bunch of FFI types that are acceptable in foreign import/export declarations, including lots of things defined in Foreign.C.*. The original spec defined these as abstract types. The original FFI spec also allowed for automatic newtype unwrapping in foreign declarations. In 2009 Simon PJ [pointed out http://www.haskell.org/pipermail/haskell-prime/2009-February/002726.html] that automatic newtype unwrapping breaks abstraction for user-defined types. In that same thread [I suggested http://www.haskell.org/pipermail /haskell-prime/2009-February/002727.html] that the breaking of abstraction for user types should be fixed, but that the intent of the FFI spec to have the FFI types as abstract should be kept. Manuel [argued http://www.haskell.org/pipermail/haskell-prime/2009-February/002729.html] that the C FFI types should actually not be abstract, and thus no special case for them was needed. On the basis of that thread the decision in #5529 was to only allow FFI decls to look through newtypes when the constructor is available, plus for a few types GHC uses to represent the C FFI types, like Int32 etc. Johan and I want to argue that it still makes sense as a user to not be forced into knowing the representation of the C FFI types to be able to use them. This is similar to but slightly weaker than the rationale of the FFI spec originally making those types abstract. Manuels argument is essentially that sometimes you need to know concrete types when those can change, e.g. CInt might be Int32 or Int64 and you should be free to depend on that difference. Manuel's argument is fine when the "concrete" representation exists as yet another portable type, as is the case for Int32. Of course we don't insist that the representation for Int or Int32 be exposed, in large part because they cannot have a Haskell implementation independent representation. The important point is Johan and I are defining/writing a portable low level ByteArray library that could be considered alongside the FFI's definition of some of the Foreign.* libraries: it defines and API for some low level types and functions but different Haskell implementations will implement them differently. For GHC we implement `data ByteArray = BA ByteArray#`. We want to make this an FFI type, in the same sense as the FFI spec defines the C types to be FFI types. (You could consider our library as a Haskell extension and implementations following this extension will support this type for FFI in a similar way to the FFI spec). Of course for this implementation of `ByteArray` the representation crosses the boundary into implementation dependent, unlike the case for `newtype CInt = CInt Int32` where both are still portable types. So, we think the right thing to do is to again be able to declare certain types (those defined in the FFI spec and its extensions) as being valid types to use in FFI decls, without their constructors being available. Thus users could choose to import `CInt` only (i.e. without its constructor) and use it. We are not arguing against Manuel's point that it's sometimes useful to not hide representations where that is possible (like for CInt being an Int32 or 64). So we are not asking that the C FFI types be made abstract again, just that it be possible to use them (and our new type) as FFI types without user access to the constrctor. For GHC, my suggestion for a reasonable way to do this is with a pragma. The pragma would say that this single-constrcutor single-field newtype or data is an FFI type, and that GHC may perform the usual newtype unwrapping even when the constructor is not in scope at the FFI decl site. We would then use this pragma on Int, Int32 and other core GHC (and FFI) types, and also on the various C FFI types. And finally, we would also do this on our ByteArray type. Note that it would have to cover data as well as newtype to be able to work for Int and other boxed wrappers of unboxed types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 22:42:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 22:42:04 -0000 Subject: [GHC] #9197: FFI types should be usable in foreign import decls without revealing representations In-Reply-To: <045.1e66fe66ff436f9c3e1f990da91bd5b9@haskell.org> References: <045.1e66fe66ff436f9c3e1f990da91bd5b9@haskell.org> Message-ID: <060.c07c7049a1482a9d4febd274ad1c3a33@haskell.org> #9197: FFI types should be usable in foreign import decls without revealing representations -------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by duncan: Old description: > This is another go at #5529 but with, we hope, clearer and better > arguments. > > The original FFI spec defined a whole bunch of FFI types that are > acceptable in foreign import/export declarations, including lots of > things defined in Foreign.C.*. The original spec defined these as > abstract types. > > The original FFI spec also allowed for automatic newtype unwrapping in > foreign declarations. In 2009 Simon PJ [pointed out > http://www.haskell.org/pipermail/haskell-prime/2009-February/002726.html] > that automatic newtype unwrapping breaks abstraction for user-defined > types. In that same thread [I suggested http://www.haskell.org/pipermail > /haskell-prime/2009-February/002727.html] that the breaking of > abstraction for user types should be fixed, but that the intent of the > FFI spec to have the FFI types as abstract should be kept. Manuel [argued > http://www.haskell.org/pipermail/haskell-prime/2009-February/002729.html] > that the C FFI types should actually not be abstract, and thus no special > case for them was needed. > > On the basis of that thread the decision in #5529 was to only allow FFI > decls to look through newtypes when the constructor is available, plus > for a few types GHC uses to represent the C FFI types, like Int32 etc. > > Johan and I want to argue that it still makes sense as a user to not be > forced into knowing the representation of the C FFI types to be able to > use them. This is similar to but slightly weaker than the rationale of > the FFI spec originally making those types abstract. Manuels argument is > essentially that sometimes you need to know concrete types when those can > change, e.g. CInt might be Int32 or Int64 and you should be free to > depend on that difference. > > Manuel's argument is fine when the "concrete" representation exists as > yet another portable type, as is the case for Int32. Of course we don't > insist that the representation for Int or Int32 be exposed, in large part > because they cannot have a Haskell implementation independent > representation. The important point is > > Johan and I are defining/writing a portable low level ByteArray library > that could be considered alongside the FFI's definition of some of the > Foreign.* libraries: it defines and API for some low level types and > functions but different Haskell implementations will implement them > differently. > > For GHC we implement `data ByteArray = BA ByteArray#`. We want to make > this an FFI type, in the same sense as the FFI spec defines the C types > to be FFI types. (You could consider our library as a Haskell extension > and implementations following this extension will support this type for > FFI in a similar way to the FFI spec). Of course for this implementation > of `ByteArray` the representation crosses the boundary into > implementation dependent, unlike the case for `newtype CInt = CInt Int32` > where both are still portable types. > > So, we think the right thing to do is to again be able to declare certain > types (those defined in the FFI spec and its extensions) as being valid > types to use in FFI decls, without their constructors being available. > Thus users could choose to import `CInt` only (i.e. without its > constructor) and use it. We are not arguing against Manuel's point that > it's sometimes useful to not hide representations where that is possible > (like for CInt being an Int32 or 64). So we are not asking that the C FFI > types be made abstract again, just that it be possible to use them (and > our new type) as FFI types without user access to the constrctor. > > For GHC, my suggestion for a reasonable way to do this is with a pragma. > The pragma would say that this single-constrcutor single-field newtype or > data is an FFI type, and that GHC may perform the usual newtype > unwrapping even when the constructor is not in scope at the FFI decl > site. We would then use this pragma on Int, Int32 and other core GHC (and > FFI) types, and also on the various C FFI types. And finally, we would > also do this on our ByteArray type. > > Note that it would have to cover data as well as newtype to be able to > work for Int and other boxed wrappers of unboxed types. New description: This is another go at #5529 but with, we hope, clearer and better arguments. The original FFI spec defined a whole bunch of FFI types that are acceptable in foreign import/export declarations, including lots of things defined in Foreign.C.*. The original spec defined these as abstract types. The original FFI spec also allowed for automatic newtype unwrapping in foreign declarations. In 2009 Simon PJ [http://www.haskell.org/pipermail /haskell-prime/2009-February/002726.html pointed out] that automatic newtype unwrapping breaks abstraction for user-defined types. In that same thread [http://www.haskell.org/pipermail/haskell- prime/2009-February/002727.html I suggested] that the breaking of abstraction for user types should be fixed, but that the intent of the FFI spec to have the FFI types as abstract should be kept. Manuel [http://www.haskell.org/pipermail/haskell-prime/2009-February/002729.html argued] that the C FFI types should actually not be abstract, and thus no special case for them was needed. On the basis of that thread the decision in #5529 was to only allow FFI decls to look through newtypes when the constructor is available, plus for a few types GHC uses to represent the C FFI types, like Int32 etc. Johan and I want to argue that it still makes sense as a user to not be forced into knowing the representation of the C FFI types to be able to use them. This is similar to but slightly weaker than the rationale of the FFI spec originally making those types abstract. Manuels argument is essentially that sometimes you need to know concrete types when those can change, e.g. CInt might be Int32 or Int64 and you should be free to depend on that difference. Manuel's argument is fine when the "concrete" representation exists as yet another portable type, as is the case for Int32. Of course we don't insist that the representation for Int or Int32 be exposed, in large part because they cannot have a Haskell implementation independent representation. The important point is Johan and I are defining/writing a portable low level ByteArray library that could be considered alongside the FFI's definition of some of the Foreign.* libraries: it defines and API for some low level types and functions but different Haskell implementations will implement them differently. For GHC we implement `data ByteArray = BA ByteArray#`. We want to make this an FFI type, in the same sense as the FFI spec defines the C types to be FFI types. (You could consider our library as a Haskell extension and implementations following this extension will support this type for FFI in a similar way to the FFI spec). Of course for this implementation of `ByteArray` the representation crosses the boundary into implementation dependent, unlike the case for `newtype CInt = CInt Int32` where both are still portable types. So, we think the right thing to do is to again be able to declare certain types (those defined in the FFI spec and its extensions) as being valid types to use in FFI decls, without their constructors being available. Thus users could choose to import `CInt` only (i.e. without its constructor) and use it. We are not arguing against Manuel's point that it's sometimes useful to not hide representations where that is possible (like for CInt being an Int32 or 64). So we are not asking that the C FFI types be made abstract again, just that it be possible to use them (and our new type) as FFI types without user access to the constrctor. For GHC, my suggestion for a reasonable way to do this is with a pragma. The pragma would say that this single-constrcutor single-field newtype or data is an FFI type, and that GHC may perform the usual newtype unwrapping even when the constructor is not in scope at the FFI decl site. We would then use this pragma on Int, Int32 and other core GHC (and FFI) types, and also on the various C FFI types. And finally, we would also do this on our ByteArray type. Note that it would have to cover data as well as newtype to be able to work for Int and other boxed wrappers of unboxed types. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 11 22:45:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jun 2014 22:45:48 -0000 Subject: [GHC] #9197: FFI types should be usable in foreign import decls without revealing representations In-Reply-To: <045.1e66fe66ff436f9c3e1f990da91bd5b9@haskell.org> References: <045.1e66fe66ff436f9c3e1f990da91bd5b9@haskell.org> Message-ID: <060.0e44350801730e45956c3f1850db999d@haskell.org> #9197: FFI types should be usable in foreign import decls without revealing representations -------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by duncan: Old description: > This is another go at #5529 but with, we hope, clearer and better > arguments. > > The original FFI spec defined a whole bunch of FFI types that are > acceptable in foreign import/export declarations, including lots of > things defined in Foreign.C.*. The original spec defined these as > abstract types. > > The original FFI spec also allowed for automatic newtype unwrapping in > foreign declarations. In 2009 Simon PJ [http://www.haskell.org/pipermail > /haskell-prime/2009-February/002726.html pointed out] that automatic > newtype unwrapping breaks abstraction for user-defined types. In that > same thread [http://www.haskell.org/pipermail/haskell- > prime/2009-February/002727.html I suggested] that the breaking of > abstraction for user types should be fixed, but that the intent of the > FFI spec to have the FFI types as abstract should be kept. Manuel > [http://www.haskell.org/pipermail/haskell-prime/2009-February/002729.html > argued] that the C FFI types should actually not be abstract, and thus no > special case for them was needed. > > On the basis of that thread the decision in #5529 was to only allow FFI > decls to look through newtypes when the constructor is available, plus > for a few types GHC uses to represent the C FFI types, like Int32 etc. > > Johan and I want to argue that it still makes sense as a user to not be > forced into knowing the representation of the C FFI types to be able to > use them. This is similar to but slightly weaker than the rationale of > the FFI spec originally making those types abstract. Manuels argument is > essentially that sometimes you need to know concrete types when those can > change, e.g. CInt might be Int32 or Int64 and you should be free to > depend on that difference. > > Manuel's argument is fine when the "concrete" representation exists as > yet another portable type, as is the case for Int32. Of course we don't > insist that the representation for Int or Int32 be exposed, in large part > because they cannot have a Haskell implementation independent > representation. The important point is > > Johan and I are defining/writing a portable low level ByteArray library > that could be considered alongside the FFI's definition of some of the > Foreign.* libraries: it defines and API for some low level types and > functions but different Haskell implementations will implement them > differently. > > For GHC we implement `data ByteArray = BA ByteArray#`. We want to make > this an FFI type, in the same sense as the FFI spec defines the C types > to be FFI types. (You could consider our library as a Haskell extension > and implementations following this extension will support this type for > FFI in a similar way to the FFI spec). Of course for this implementation > of `ByteArray` the representation crosses the boundary into > implementation dependent, unlike the case for `newtype CInt = CInt Int32` > where both are still portable types. > > So, we think the right thing to do is to again be able to declare certain > types (those defined in the FFI spec and its extensions) as being valid > types to use in FFI decls, without their constructors being available. > Thus users could choose to import `CInt` only (i.e. without its > constructor) and use it. We are not arguing against Manuel's point that > it's sometimes useful to not hide representations where that is possible > (like for CInt being an Int32 or 64). So we are not asking that the C FFI > types be made abstract again, just that it be possible to use them (and > our new type) as FFI types without user access to the constrctor. > > For GHC, my suggestion for a reasonable way to do this is with a pragma. > The pragma would say that this single-constrcutor single-field newtype or > data is an FFI type, and that GHC may perform the usual newtype > unwrapping even when the constructor is not in scope at the FFI decl > site. We would then use this pragma on Int, Int32 and other core GHC (and > FFI) types, and also on the various C FFI types. And finally, we would > also do this on our ByteArray type. > > Note that it would have to cover data as well as newtype to be able to > work for Int and other boxed wrappers of unboxed types. New description: This is another go at #5529 but with, we hope, clearer and better arguments. The original FFI spec defined a whole bunch of FFI types that are acceptable in foreign import/export declarations, including lots of things defined in Foreign.C.*. The original spec defined these as abstract types. The original FFI spec also allowed for automatic newtype unwrapping in foreign declarations. In 2009 Simon PJ [http://www.haskell.org/pipermail /haskell-prime/2009-February/002726.html pointed out] that automatic newtype unwrapping breaks abstraction for user-defined types. In that same thread [http://www.haskell.org/pipermail/haskell- prime/2009-February/002727.html I suggested] that the breaking of abstraction for user types should be fixed, but that the intent of the FFI spec to have the FFI types as abstract should be kept. Manuel [http://www.haskell.org/pipermail/haskell-prime/2009-February/002729.html argued] that the C FFI types should actually not be abstract, and thus no special case for them was needed. On the basis of that thread the decision in #5529 was to only allow FFI decls to look through newtypes when the constructor is available, plus for a few types GHC uses to represent the C FFI types, like Int32 etc. Johan and I want to argue that it still makes sense as a user to not be forced into knowing the representation of the C FFI types to be able to use them. This is similar to but slightly weaker than the rationale of the FFI spec originally making those types abstract. Manuels argument is essentially that sometimes you need to know concrete types when those can change, e.g. CInt might be Int32 or Int64 and you should be free to depend on that difference. Manuel's argument is fine when the "concrete" representation exists as yet another portable type, as is the case for Int32. Of course we don't insist that the representation for Int or Int32 be exposed, in large part because they cannot have a Haskell implementation independent representation. Johan and I are defining/writing a portable low level ByteArray library that could be considered alongside the FFI's definition of some of the Foreign.* libraries: it defines and API for some low level types and functions but different Haskell implementations will implement them differently. For GHC we implement `data ByteArray = BA ByteArray#`. We want to make this an FFI type, in the same sense as the FFI spec defines the C types to be FFI types. (You could consider our library as a Haskell extension and implementations following this extension will support this type for FFI in a similar way to the FFI spec). Of course for this implementation of `ByteArray` the representation crosses the boundary into implementation dependent, unlike the case for `newtype CInt = CInt Int32` where both are still portable types. So, we think the right thing to do is to again be able to declare certain types (those defined in the FFI spec and its extensions) as being valid types to use in FFI decls, without their constructors being available. Thus users could choose to import `CInt` only (i.e. without its constructor) and use it. We are not arguing against Manuel's point that it's sometimes useful to not hide representations where that is possible (like for CInt being an Int32 or 64). So we are not asking that the C FFI types be made abstract again, just that it be possible to use them (and our new type) as FFI types without user access to the constrctor. For GHC, my suggestion for a reasonable way to do this is with a pragma. The pragma would say that this single-constrcutor single-field newtype or data is an FFI type, and that GHC may perform the usual newtype unwrapping even when the constructor is not in scope at the FFI decl site. We would then use this pragma on Int, Int32 and other core GHC (and FFI) types, and also on the various C FFI types. And finally, we would also do this on our ByteArray type. Note that it would have to cover data as well as newtype to be able to work for Int and other boxed wrappers of unboxed types. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 01:29:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 01:29:32 -0000 Subject: [GHC] #9198: large performance regression in type checker speed in 7.8 Message-ID: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> #9198: large performance regression in type checker speed in 7.8 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- it was recently demonstrated on the haskell-cafe mailing list that the following code takes measurably longer to type check in GHC 7.8.2 than in GHC 7.6. http://www.haskell.org/pipermail/haskell-cafe/2014-June/114562.html the program example is as follows {{{ begin cont = cont (return ()) a m =cont (m >> putstrn "a") end m = m main = begin a a a a a a a a a a a a a a a a a end }}} takes about a second to type check in ghc 7.8, and is "instant" in 7.6 () each additional a doubles the time to type check the program {{{ main = begin a a a a a a a a a a a a a a a a a a a a a a a a end }}} takes longer than I have the patience to wait :) (so more than 5 seconds) the author of the email notes that a related program {{{ main = id id id id id id id id id id id id id id id id id id id id id id (return ()) }}} has the exponential complexity in both 7.8.2 and 7.6.2 This It could very well be that some of the type checker changes between 7.8 and 7.6 enlarged the space of programs that trip up exponential worst case behavior, but one way or another understanding *why* this happened -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 02:24:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 02:24:54 -0000 Subject: [GHC] #9198: large performance regression in type checker speed in 7.8 In-Reply-To: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> References: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> Message-ID: <060.0f90cb4efb6a42ac487f545db76ed988@haskell.org> #9198: large performance regression in type checker speed in 7.8 -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): With typos removed and types added, this looks like {{{ begin :: Monad m => (m () -> t) -> t begin cont = cont (return ()) a :: IO a -> (IO () -> t) -> t a m cont = cont (m >> putStrLn "a") end :: t -> t end m = m main = begin a a a a a a a a a a a a a a a a a a a a end }}} Including the type signatures does not improve performance. Great example case -- this does indeed need to be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 07:55:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 07:55:20 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.9eb0699cb926216f0fa5a8578c3c1739@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by jstolarek): In my work on the prototype I've ran into a problem I can't solve. Since desugaring of `HsCmdTop` [https://github.com/ghc/ghc/blob/165ac4af4a1002eff5f5a474bc21bc443c8f8c63/compiler/deSugar/DsArrows.lhs#L292 requires calls to arr and >>>] I've added two `SyntaxExpr` to `HsCmdTop` datatype. These two `SyntaxExpr`s [https://github.com/ghc/ghc/blob/165ac4af4a1002eff5f5a474bc21bc443c8f8c63/compiler/typecheck/TcArrows.lhs#L128 need to be typechecked in tcCmdTop]. I've see earlier how [https://github.com/ghc/ghc/blob/165ac4af4a1002eff5f5a474bc21bc443c8f8c63/compiler/typecheck/TcMatches.lhs#L761 typechecking of the do-notation bind is implemented] and decided to adopt a similar aproach: {{{ tcCmdTop env (L loc (HsCmdTop cmd _ _ names compose_op arr_op)) cmd_ty@(cmd_stk, res_ty) = setSrcSpan loc $ do { cmd' <- tcCmd env cmd cmd_ty ; names' <- mapM (tcSyntaxName ProcOrigin (cmd_arr env)) names -- VOODOO CODING based on typechecking of >>= in TcMatches -- is it correct to use b and c variables for typechecking in both -- arr and compose? ; a <- newFlexiTyVarTy liftedTypeKind ; b <- newFlexiTyVarTy liftedTypeKind ; c <- newFlexiTyVarTy liftedTypeKind ; arr_op' <- tcSyntaxOp DoOrigin arr_op (mkFunTy (mkFunTy b c) (mkCmdArrTy env b c)) ; compose_op' <- tcSyntaxOp DoOrigin compose_op (mkFunTys [mkCmdArrTy env a b, mkCmdArrTy env b c] (mkCmdArrTy env a c)) ; return (L loc $ HsCmdTop cmd' cmd_stk res_ty names' compose_op' arr_op') } }}} This however ends with a panic. Using `-dcore-lint` gives me this: {{{ *** Core Lint errors : in result of Desugar (after optimization) *** : Warning: In the expression: T7828.>>> @ GHC.Prim.Any @ GHC.Prim.Any @ GHC.Prim.Any @ a_aEo @ (a_aEo, ()) @ a_aEo (T7828.arr @ GHC.Prim.Any @ GHC.Prim.Any @ a_aEo @ (a_aEo, ()) (\ (n_aus :: a_aEo) -> (n_aus, GHC.Tuple.()))) (T7828.>>> @ (a_aEo, ()) @ a_aEo @ a_aEo (T7828.arr @ (a_aEo, ()) @ a_aEo (\ (ds_dGU :: (a_aEo, ())) -> case ds_dGU of _ [Occ=Dead] { (ds_dGT, _ [Occ=Dead]) -> ds_dGT })) (T7828.returnA @ a_aEo)) Illegal type application: Exp type: T7828.R GHC.Prim.Any GHC.Prim.Any -> T7828.R GHC.Prim.Any GHC.Prim.Any -> T7828.R GHC.Prim.Any GHC.Prim.Any :: * Arg type: a_aEo :: * }}} These `GHC.Prim.Any` look wrong. Notice that there are two calls of `>>>` and `arr` but only one of each has these extra `GHC.Prim.Any` parameters. The incorrect `>>>` and `arr` are generated by my modified `HsCmdTop`. The other pair of `>>>` and `arr` is generated by `HsCmdArrApp` constructor, which has not been modified yet. Simon, help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 08:00:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 08:00:25 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.588b0e2ff015a36b02c3e200218dda3c@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Changes (by jstolarek): * related: => #1537, #3613 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 10:19:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 10:19:46 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.2dd101c0256c27d78894d74cc7f52134@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------------------+-------------------------- Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: typecheck/should_fail/T8883 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by jstolarek): * owner: jstolarek => * status: closed => new * resolution: fixed => Comment: Re-opening this as a reminder to mention this in the release notes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 10:19:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 10:19:54 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.86fed9b5a7a26690196f7bbbece492a7@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------------------+-------------------------- Reporter: Blaisorblade | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: typecheck/should_fail/T8883 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by jstolarek): * owner: => jstolarek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 11:04:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 11:04:13 -0000 Subject: [GHC] #9168: reading/writing blocking FDs over FD_SETSIZE is broken In-Reply-To: <047.7e804364d376ec9b9bd7772943568384@haskell.org> References: <047.7e804364d376ec9b9bd7772943568384@haskell.org> Message-ID: <062.b08095d3f127cea41fb6dc31d0721f0e@haskell.org> #9168: reading/writing blocking FDs over FD_SETSIZE is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by slyfox): Replying to [comment:3 nicolast]: > Can't the changes from #4934 (9fd507e5758f4141ac2619f0db57136bcab035c6) trigger this as well? You mean regression introduction? I think not, as fd sanity is checked right before main select() call. As it's a single-threaded runtime case no haskell tasks should be able to be pushed to blocked queue (with very big FD). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 13:22:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 13:22:56 -0000 Subject: [GHC] #9196: Higher-rank constraint treated as type instead In-Reply-To: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> References: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> Message-ID: <062.d14eafbbbe22c392167092161a52bbca@haskell.org> #9196: Higher-rank constraint treated as type instead -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by archblob): I simplified this a little bit, you just need an explicit `forall` and parentheses. This works: {{{ foo :: forall a. P a => a -> a }}} This does not: {{{ foo :: (forall a. P a) => a -> a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 13:49:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 13:49:37 -0000 Subject: [GHC] #9168: reading/writing blocking FDs over FD_SETSIZE is broken In-Reply-To: <047.7e804364d376ec9b9bd7772943568384@haskell.org> References: <047.7e804364d376ec9b9bd7772943568384@haskell.org> Message-ID: <062.09736db307e3c627e9adfde3eb18c2b8@haskell.org> #9168: reading/writing blocking FDs over FD_SETSIZE is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by slyfox): Simplest "fix" (as done in non-threaded IOmanager): {{{ --- a/libraries/base/cbits/inputReady.c +++ b/libraries/base/cbits/inputReady.c @@ -25,7 +25,9 @@ fdReady(int fd, int write, int msecs, int isSock) int maxfd, ready; fd_set rfd, wfd; struct timeval tv; - + if ((fd >= (int)FD_SETSIZE) || (fd < 0)) { + return -1; + } FD_ZERO(&rfd); FD_ZERO(&wfd); if (write) { }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 14:54:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 14:54:33 -0000 Subject: [GHC] #9199: Wrong Template Haskell desugaring Message-ID: <046.13d98ebb5f95442f706ab8481ad8b12c@haskell.org> #9199: Wrong Template Haskell desugaring ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This code {{{ {-# LANGUAGE TemplateHaskell, PolyKinds, TypeFamilies #-} module T9160 where $( [d| class C (a :: k) where type F (a :: k) :: * |] ) }}} yields {{{ T9160.hs:5:4: Kind variable also used as type variable: ?k_a2cl? In the declaration for class C_a2cj }}} which is utterly bogus. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 16:23:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 16:23:41 -0000 Subject: [GHC] #9199: Wrong Template Haskell desugaring In-Reply-To: <046.13d98ebb5f95442f706ab8481ad8b12c@haskell.org> References: <046.13d98ebb5f95442f706ab8481ad8b12c@haskell.org> Message-ID: <061.e7b1c69be5ae2e961d14bf23dfbd5f8f@haskell.org> #9199: Wrong Template Haskell desugaring -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"571f0adccda687098d59f63524357f4ac98e72fb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="571f0adccda687098d59f63524357f4ac98e72fb" Line up kind and type variables correctly when desugaring TH brackets This bug was causing Trac #9199 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 16:23:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 16:23:41 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.dc8db0cb4179a408084af088e88acdf9@haskell.org> #9160: Panic: Template variable unbound in rewrite rule ---------------------------------------+---------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4524 ---------------------------------------+---------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b637585dcbfc1ba53aa49bcb9b730cd08fea4b59/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b637585dcbfc1ba53aa49bcb9b730cd08fea4b59" Fix elemLocalRdrEnv (Trac #9160) This was pretty obscure. elemLocalRdrEnv was utterly wrong (replied False when it should reply True) when given an Exact Name. That doesn't happen often, but it does happen in the result of a TH splice. The result was that an associated type didn't get a type variable that lined up with its parent class (elemLocalRdrEnv is used in RnTypes.bindHsTyVars), and that messed up the singletons package. I've made a completely different test case to show up the bug: indexed_types/should_fail/T9160 I also refactored RdrName.LocalRdrEnv to be a record with named fields, which makes the code more robust and easy to understand. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 16:24:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 16:24:54 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.e734ad1e414cd8b68bb95a26ec2f8e43@haskell.org> #9160: Panic: Template variable unbound in rewrite rule -------------------------------------------------+------------------------- Reporter: mietek | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | x86_64 (amd64) Test Case: | Difficulty: indexed_types/should_fail/T9160 | Unknown Blocking: | Blocked By: | Related Tickets: #4524 -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => merge * testcase: => indexed_types/should_fail/T9160 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 16:25:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 16:25:47 -0000 Subject: [GHC] #9199: Wrong Template Haskell desugaring In-Reply-To: <046.13d98ebb5f95442f706ab8481ad8b12c@haskell.org> References: <046.13d98ebb5f95442f706ab8481ad8b12c@haskell.org> Message-ID: <061.88054903ae4d5acdc6bb037ad447f0d7@haskell.org> #9199: Wrong Template Haskell desugaring -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T9199 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => merge * testcase: => th/T9199 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 17:32:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 17:32:06 -0000 Subject: [GHC] #9195: ImpredicativeTypes and ConstraintKinds don't interact as expected In-Reply-To: <050.891dda4540243320d80c0b42f302fbb5@haskell.org> References: <050.891dda4540243320d80c0b42f302fbb5@haskell.org> Message-ID: <065.f5506e65f035921208778766a573594b@haskell.org> #9195: ImpredicativeTypes and ConstraintKinds don't interact as expected ----------------------------------------------+---------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by monoidal): AFAIK polymorphic constraints are not supported. See comment at #7019. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 17:58:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 17:58:20 -0000 Subject: [GHC] #9196: Higher-rank constraint treated as type instead In-Reply-To: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> References: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> Message-ID: <062.1793d858e626c9c3ff09dfe9217f511d@haskell.org> #9196: Higher-rank constraint treated as type instead -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by archblob): Experimenting with this I found that ghc will go along with `foo :: a -> ((forall b. P b) => b) -> a` and transform it in `foo :: a -> ((forall b. P b) -> b) -> a`. I may have a simple fix for this, just a check for foralls when typechecking a context. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 18:25:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 18:25:52 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.64dcd72072a040aa9eb1764b1ea50334@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by kini): * cc: kini (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 19:39:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 19:39:52 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level Message-ID: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> #9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- This is a reduction of a problem that occurs in real code. {{{ {-# LANGUAGE PolyKinds #-} class D a => C (f :: k) a class C () a => D a }}} Typechecking complains: {{{ The first argument of ?C? should have kind ?k?, but ?()? has kind ?*? In the class declaration for ?D? }}} This program should be accepted, but we're not generalizing enough. A slightly less reduced version of the problem arises in practice in: {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE PolyKinds #-} import Control.Category class (Category c, Category d, Category e) => Profunctor (p :: x -> y -> z) (c :: x -> x -> *) (d :: y -> y -> *) (e :: z -> z -> *) | p -> c d e -- lens-style isomorphism families in an arbitrary category type Iso (c :: i -> i -> *) (s :: i) (a :: i) = forall (p :: i -> i -> *). Profunctor p c c (->) => p a a -> p s s class Category e => Cartesian (e :: z -> z -> *) where type P e :: z -> z -> z associate :: Iso e (P e (P e a b) c) (P e a (P e b c)) }}} This typechecks, but if I replace the line {{{ class (Category c, Category d, Category e) => Profunctor }}} with {{{ class (Category c, Category d, Cartesian e) => Profunctor }}} to say that you can only enrich a category over a monoidal category (using `Cartesian` in the approximation here), then it fails because a more baroque version of the same kind of cycle as the minimal example above as Profunctor references Cartesian which references an Iso which mentions a Profunctor. I'm supplying explicit kind variables in the signature of the class, so we should be able to use those like we do with function signatures a universe down. =/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 19:44:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 19:44:59 -0000 Subject: [GHC] #9201: GHC unexpectedly refines explicit kind signatures Message-ID: <045.58b3385e1edd9977dfe0a46c17d9ab9b@haskell.org> #9201: GHC unexpectedly refines explicit kind signatures -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts Architecture: Unknown/Multiple | invalid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The following program should be rejected by the type checker: {{{ {-# LANGUAGE PolyKinds, FunctionalDependencies, MultiParamTypeClasses #-} class MonoidalCCC (f :: x -> y) (d :: y -> y -> *) | f -> d where ret :: d a (f a) }}} Instead it is accepted, but the kind variables specified above are 'corrected' during typechecking to: {{{ >>> :browse class MonoidalCCC (f :: x -> x) (d :: x -> x -> *) | f -> d where ret :: d a (f a) }}} This may be similar in root cause to issue #9200, but there a valid program is rejected, and here an invalid program is accepted, so the fixes may be quite different. It seems these kind variables are just being allowed to unify rather than being checked for subsumption. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 19:59:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 19:59:29 -0000 Subject: [GHC] #7259: Eta expansion of products in System FC In-Reply-To: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> References: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> Message-ID: <061.876ca042b5ffdf734668a5fc20ff1255@haskell.org> #7259: Eta expansion of products in System FC -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ekmett): * cc: ekmett@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 20:19:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 20:19:09 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.b6e8482834b56a366652094042903319@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by ekmett): * cc: ekmett (removed) * cc: ekmett@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 20:19:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 20:19:32 -0000 Subject: [GHC] #9201: GHC unexpectedly refines explicit kind signatures In-Reply-To: <045.58b3385e1edd9977dfe0a46c17d9ab9b@haskell.org> References: <045.58b3385e1edd9977dfe0a46c17d9ab9b@haskell.org> Message-ID: <060.1075b0c78b44316f9e3ad91ba2c5fd9d@haskell.org> #9201: GHC unexpectedly refines explicit kind signatures ------------------------------------------------+-------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by ekmett): * cc: ekmett (removed) * cc: ekmett@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 12 22:45:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jun 2014 22:45:21 -0000 Subject: [GHC] #6135: Unboxed Booleans In-Reply-To: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> References: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> Message-ID: <058.f3ddbfb8cd6ab61a8d5ed03fab171f13@haskell.org> #6135: Unboxed Booleans ---------------------------------------------+----------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: primops/should_run/T6135 | Difficulty: Unknown Blocking: | Blocked By: 8103, | 8103 | Related Tickets: #605 ---------------------------------------------+----------------------------- Comment (by altaic): Replying to [comment:91 Lemming]: > Replying to [comment:90 carter]: > > @lemming, Bool# is now Int# afaik, could you explain what you mean? even if we used a i1 rep, it still needs a full register! So theres no lost for the in register rep to be Int#, afaik > > `Int#` represents a large range of integers, whereas `i1` in LLVM has only values 0 and 1. That is, LLVM can optimize based on the knowledge of the restricted value set of `i1`, but it certainly fails to do so on `i32` or `i64`. Two of the advantages in representing Bool# as an i1 is that llvm can vectorize them, and arrays of i1 can fit in an i32 or i64. Off the top of my head, I don't know of any software that makes use of large arrays of booleans, but in that case this sort of optimization would likely be very effective. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 01:02:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 01:02:59 -0000 Subject: [GHC] #9202: Strange Closure Type Message-ID: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> #9202: Strange Closure Type -------------------------------------+------------------------------------- Reporter: athanclark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: strange-closure- | Operating System: Linux type | Type of failure: Compile-time Architecture: x86_64 (amd64) | crash Difficulty: Project (more | Test Case: than a week) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Hello masters of the universe, I am here with a plea. I have recently installed GHC 7.8.2 and cabal-install 1.20.0.0 (following [https://gist.github.com/wting/8498731 this] guide), and have ran into a fun road block on the way to installing yesod-platform. I have had a few incidents of the 'strange closure type ###' error on this machine before, on the 7.6.x version available in Ubuntu's repository. I believe this failure is occuring when installing text, because that was the error that I got when installing attoparsec alone, but without a sandbox. I know (barely) better now, so when I went to install yesod-platform, I did a {{{cabal unpack $1 && cd $1* && cabal sandbox init && cabal install --only-dependencies && cabal build}}}, but I failed at preventing the error, still :( I've attached the output as output.txt, and I've also included my `lspci` and `lshw` outputs just for giggles :) I hope someone can direct me in the right direction, I would appreciate it tremendously. Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 01:07:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 01:07:14 -0000 Subject: [GHC] #9202: Strange Closure Type In-Reply-To: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> References: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> Message-ID: <064.9e5826acabd031c5e94bfddfa96d4b72@haskell.org> #9202: Strange Closure Type -------------------------------------+------------------------------------- Reporter: athanclark | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: worksforme | Keywords: strange-closure- Operating System: Linux | type Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Project (more Test Case: | than a week) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Changes (by athanclark): * status: new => closed * resolution: => worksforme Comment: Wow, somehow I can't find the file I output the logs to. Sorry!! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 03:11:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 03:11:14 -0000 Subject: [GHC] #9202: Strange Closure Type In-Reply-To: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> References: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> Message-ID: <064.567f63e96d0f8b3514fc0b5c8cf91d1c@haskell.org> #9202: Strange Closure Type -------------------------------------+------------------------------------- Reporter: athanclark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strange-closure- Operating System: Linux | type Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Project (more Test Case: | than a week) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Changes (by athanclark): * status: closed => new * resolution: worksforme => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 03:11:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 03:11:18 -0000 Subject: [GHC] #9196: Higher-rank constraint treated as type instead In-Reply-To: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> References: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> Message-ID: <062.31305f925912cdd8b85b716b79631bce@haskell.org> #9196: Higher-rank constraint treated as type instead -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by archblob): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 03:14:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 03:14:12 -0000 Subject: [GHC] #9202: Strange Closure Type In-Reply-To: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> References: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> Message-ID: <064.9e919db17400760a027be00435da55a3@haskell.org> #9202: Strange Closure Type -------------------------------------+------------------------------------- Reporter: athanclark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strange-closure- Operating System: Linux | type Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Project (more Test Case: | than a week) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Comment (by athanclark): I'm sorry to reopen this nuisance case, but I have come across the failure again and can reproduce it. I have a sandbox open for yesod-platform, and have been running into an ExitFailure (-11) when I try to install it normally, with attoparsec-0.12.0.0 being the culprit of failure. So, I install attoparsec-0.12.0.0 in the sandbox without failures, then try to `cabal install` the whole package, and that's when I ran into the failure. What other information should I be getting? Thank you in advance for all your help :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 03:55:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 03:55:37 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.1385553bcf607408ce05fb5ff9bd2b91@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): Yes, this absolutely should be able to work but it currently doesn't, perhaps by design. Happily, I believe this one is actually quite easy to solve. See [https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcHsType.lhs#L917 this comment]. I believe if we changed the kind-checking strategy for classes from `ParametricKinds` to `NonParametricKinds`, this problem would be solved. I also believe that this change would allow only ''more'' programs to type-check, and would thus be fully backward compatible. Indeed, in my branch where I'm implementing a merged type/kind language, I've gotten rid of `ParametricKinds`. Tracing this design through history, I think it came from work on the patch described in #6093. There, Simon proposed (and heard no complaints about) allowing polymorphic recursion if and only if a "complete user- supplied kind signature" ("cusk") is given. See [http://www.haskell.org/ghc/docs/latest/html/users_guide/kind- polymorphism.html section 7.8.3] of the manual. However, a cusk is ''not possible'' for classes, giving Edward no way to proceed here. At the end of the comment trail of #6093, Simon asks for a better design. Here goes: allow recursive instantiations of a kind variable to vary if and only if that kind variable is ''mentioned'' in a type. I'm being quite literal here in my meaning of ''mentioned'' -- the kind variable must simply appear syntactically in the code. By appearing in the source, GHC can know to generalize over the kind variable "early on" and then can deal with the polymorphic recursion. With this design, the need for cusks goes away. I think the initial reason that cusks came about in the first place is from a perceived need to either allow polymorphic recursion or to disallow it. In terms, this is straightforward: there is either a type signature or there isn't. In types, however, Haskell syntax allows for various forms of partial kind signatures. But, we had the desire for a simple "yes" or "no" answer about polymorphic recursion, and so the cusk was born. What I'm proposing here is to embrace the gray area between "yes" and "no" and permit ''some'' polymorphic recursion -- specifically, over those kind variables that are mentioned in the source. Is this history accurate, from those involved (that is, mostly, Simon)? Do we see code that would be accepted under my proposal that would be surprising to users? Happily, implementing my proposal is dead easy -- just twiddle kind-inference strategies, as my proposal is called `NonParametricKinds` there. As some context, here is an example from closed type families (the one place where `NonParametricKinds` is used) that ''is'' confusing: {{{ type family LooksLikeId (x :: k) :: k where LooksLikeId x = Bool LooksLikeId x = Maybe }}} The kind of `LooksLikeId` surely looks like that of an identity function: `k -> k`. But, because type families are ''not'' parametric (hence the name `NonParametricKinds`), we can inspect the kind and branch on it. Note that the equations above ''do not'' overlap, as they are distinguished by their kind parameters. The definition above would fail to type-check without the `k` annotation, as that is necessary for GHC to know to generalize over the kind instead of just solve for it. Thoughts on any of this? Am I deeply misunderstanding some properties of type inference here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 04:08:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 04:08:13 -0000 Subject: [GHC] #9201: GHC unexpectedly refines explicit kind signatures In-Reply-To: <045.58b3385e1edd9977dfe0a46c17d9ab9b@haskell.org> References: <045.58b3385e1edd9977dfe0a46c17d9ab9b@haskell.org> Message-ID: <060.4d4ae31a65665d0f8ebfc3d6bcaa9827@haskell.org> #9201: GHC unexpectedly refines explicit kind signatures ------------------------------------------------+-------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by goldfire): The underlying cause of this is directly related to what's causing #9200. The `ParametricKinds` strategy makes kind variables into `SigTv`s, which are allowed to unify with other `SigTv`s. The intent is that the `SigTv`s are in ''different'' signatures, like this: {{{ class C (a :: k1) where foo :: D a => a -> a class C a => D (a :: k2) where ... }}} Here, `C` and `D` are mutually recursive, and we would want these to type- check. However, according to the `ParametricKinds` strategy, we ''do not'' want to generalize over `k` while kind-checking the group. The only way to get this to work, then, is to unify `k1` and `k2`. This is sensible enough, but it fails utterly in Edward's example, where the `SigTv`s are in the ''same'' signature. The fix here is the same as the fix for #9200: change classes to use `NonParametricKinds`, which does not have this behavior. I should note why `ParametricKinds` does what it does: when I added closed type families last summer, I needed to dig somewhat deep into all of this, to get kind inference for closed families to work. At that point, there were two strategies: the "normal" one and the one used in the presence of a "complete user-supplied kind signature" ("cusk"). See [http://www.haskell.org/ghc/docs/latest/html/users_guide/kind- polymorphism.html section 7.8.3] of the manual. Closed type families didn't fit into either of these categories cleanly. Instead of just adding a few ad-hoc conditionals, I invented the idea of [https://github.com/ghc/ghc/blob/c8295c0bd58485db5572d3c35427d321bdf1b7d0/compiler/typecheck/TcHsType.lhs#L902 "kind-checking strategies" ] where each of the (now, 3) approaches could be tracked a little more transparently. `ParametricKinds` was intended to behave exactly as kind inference did without a cusk. In retrospect, I had the opportunity to perhaps clean this all up a bit, but I didn't want to challenge the status quo without a concrete reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 05:14:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 05:14:00 -0000 Subject: [GHC] #9115: The kind of (=>) In-Reply-To: <047.79a80bb2b897dcc6ec2d89a1e91dba60@haskell.org> References: <047.79a80bb2b897dcc6ec2d89a1e91dba60@haskell.org> Message-ID: <062.d3bb9a6a29625788a0d10037712f888c@haskell.org> #9115: The kind of (=>) -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Fuuzetsu): It Haddocks in whichever way you wrote it. Whether this is desirable or not is arguable but that's how it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 08:18:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 08:18:18 -0000 Subject: [GHC] #9202: Strange Closure Type In-Reply-To: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> References: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> Message-ID: <064.72092ad8f75542a35ecdf8875c9b018d@haskell.org> #9202: Strange Closure Type -------------------------------------+------------------------------------- Reporter: athanclark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strange-closure- Operating System: Linux | type Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Project (more Test Case: | than a week) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Comment (by athanclark): Here is another log of the same kind of error: {{{ Configuring cereal-0.4.0.1... Building cereal-0.4.0.1... Preprocessing library cereal-0.4.0.1... [1 of 5] Compiling Data.Serialize.Builder ( src/Data/Serialize/Builder.hs, dist$ [2 of 5] Compiling Data.Serialize.Put ( src/Data/Serialize/Put.hs, dist /dist-sa$ [3 of 5] Compiling Data.Serialize.Get ( src/Data/Serialize/Get.hs, dist /dist-sa$ [4 of 5] Compiling Data.Serialize.IEEE754 ( src/Data/Serialize/IEEE754.hs, dist$ [5 of 5] Compiling Data.Serialize ( src/Data/Serialize.hs, dist/dist- sandbox-$ In-place registering cereal-0.4.0.1... setup-Simple-Cabal-1.20.0.0-x86_64-linux-ghc-7.8.2: ghc: internal error: scavenge: unimplemented/strange closure type 1133201408 @ 0x7f9b7c1a1858 (GHC version 7.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 11:06:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 11:06:00 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.044416834b7befcde355e7fadc63f5f3@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): That's very interesting Richard. I had not followed this particular aspect of your implementation of closed type families. == The new proposed strategy == I would explain the strategies rather differently to you. '''Baseline strategy''' (BASELINE), originally due to Mark Jones. Here is the strategy that we currently follow for ordinary, recursive term-level functions, and for recursive data types. I'll describe it for data types, with this example: {{{ data S f a b = MkS (T a f) (S f a b) data T (a::k) (f::k -> *) :: * where MkT :: f a -> S f a Maybe -> S f a Int -> T a f }}} 1. Identify which type constructors have Complete User Type Signatures (CUSK). Extend the environment with these, fixed, kinds: {{{ T :: forall k. k -> (k->*) -> * }}} 2. Perform strongly-connected component analysis on the non-CUSK decls, *ignoring* dependencies on a type constructor with a CUSK. That gives us a single recursive component, containing S. 3. For each s-c component in turn: * Bind the type constructor to a fresh meta-kind variable: {{{ S :: kappa0 }}} * Kind-check all the declarations of the component in this environment. This will generate some unifications, so in the end we get {{{ kappa0 ~ (kappa1 -> *) -> kappa1 -> kappa2 -> * }}} The `kappa1` arises from instantiating `T` at its call site in `S` * Generalise. So we get {{{ S :: forall k1 k2. (k1->*) -> k1 -> k2 -> * }}} 4. Extend the environment with these generalised kind bindings, and kind- check the CUSK declarations. The Key Point is that we can kind-check S ''without looking at T's definition at all'', because we completely know T's kind. That in turn means that we can exploit ''inferred'' polymorphism for S when kind- checking T. As we do here: T uses S in two different ways `(S f a Maybe)` and `(S f a Int)`. '''Richard's strategy''' (RICHARD). The key idea is that ''all polymorphism is declared'', so nothing gets to be kind-polymorphic unless you say so. But the payoff is that you can give partial kind signatures. I'm not going to call it !NonParametric becuase I think that's a terrible name. Here's the strategy. 1. Sort the declarations into strongly-connected components. No special treatment for CUSKs. 2. For each declaration, extend the environment with a kind binding that has a forall for each *explicit* kind variable, but meta-kind variables otherwise. For example {{{ data Foo (a :: k1 -> k1) b c }}} would get a kind binding {{{ Foo :: forall k1. (k1->k1) -> kappa1 -> kappa2 -> * }}} Our earlier example would give {{{ T :: forall k. k -> (k->*) -> * S :: kappa3 -> kappa4 -> kappa5 -> * }}} 3. Kind-check the declartions in this environment. At a call of `Foo`, say, we'd instantiate the `forall k1` with a fresh meta-kind variable, but would share `kappa1`, `kappa2` among all calls to `Foo`. 4. Default any unconstrained meta kind variables to `*` That's it! No generalisation step. The *only* polymorphism is that declared by the user. So our earlier S/T example would be rejected because it relies on S being polymorphic in its third parameter. If you want the S/T example to work you could write {{{ data S f (a::k1) (b::k2) = MkS (T a f) (S f a b) data T (a::k) f where MkT :: f a -> S f a Maybe -> S f a Int -> T a f }}} That's enough to ensure that S and T's kinds start with {{{ S :: forall k1 k2. ...blah... T :: forall k. ...blah... }}} == Type signatures == Another place that we currently (i.e. using (BASELINE)) do kind generalisation is in ''type signatures''. If you write {{{ f :: m a -> m a f = ... }}} then the type signature is kind-generalised thus: {{{ This user-written signature f :: m a -> m a means this (BASELINE) f :: forall k (a:k) (m:k->*). m a -> m a }}} And f's RHS had better ''be'' that polymorphic. Under (RICHARD) it would be consistent to say this: {{{ This user-written signature f :: m a -> m a means this (RICHARD) f :: forall (a:*) (m:k->*). m a -> m a }}} If you want the kind-polymorphic one, you'd have to write thus {{{ This user-written signature f :: forall k (a:k) (m:k->*). m a -> m a means this (RICHARD) f :: forall k (a:k) (m:k->*). m a -> m a }}} == Declarative typing rules == Happily (RICHARD) has a nice declarative typing rule. Here is what the conventional declarative typing rule, ''in the absence of polymorphism'' for a single self-recursive function looks like: {{{ G, f:t |- e:t G, f:t |- b:t' --------------------------- G |- letrec f = e in b : t' }}} Here the "t" is a monotype (no foralls) that the declarative typing rules clairvoyantly conjures up out of thin air. Once you add Hindley-Milner style polymorphism, the rule gets a bit more complicated {{{ G, f:t |- e:t G, f:gen(G,t) |- b:t' --------------------------- G |- letrec f = e in b : t' }}} where 'gen' is generalising. The (RICHARD) rule might look like this: {{{ t = forall vs. sig[t1..tn/_] G, f : t |- e : forall vs.t G, f : t |- b:t' --------------------------- G |- letrec f :: forall vs. sig; f = e in b : t' }}} Here I'm expressing the user-specified knowledge as a signature `forall vs.sig`, with '_' for bits you don't want to specify. {{{ f :: forall a. _ -> a -> _ }}} Then the rule intantiates each '_' with a clairvoyantly guessed monotype (which might mention the 'vs', or 'a' in this example), and off you go. == Reflection == I think we could reasonably switch to (RICHARD) throughout. As Richard's comments in `TcHsType` point out, we don't want maximal polymorphism. His example is: {{{ type family F a where F Int = Bool F Bool = Char }}} We could generate {{{ F :: forall k1 k2. k1 -> k2 }}} so that `(F Maybe)` is well-kinded, but stuck. But that's probably not what we want. It would be better to get `F :: * -> *` But what about {{{ type family G a f b where G Int f b = f b G Bool f b = Char -> f b }}} You could just about argue that the programmer intends {{{ F :: forall k. * -> (k->*) -> k -> * }}} It's quite similar to this: {{{ data PT f a = MkPT (f a) }}} which today, using (BASELINE), we infer to have kind {{{ PT :: forall k. (k->*) -> k -> * }}} But I'd be perfectly happy if PT got a ''monomorphic'' inferred kind, which is what (RICHARD) would do: {{{ PT :: (*->*) -> * -> * }}} If you want the poly-kinded PT, use a signature: {{{ -- Any of these would do data PT f (a :: k) = MkPT (f a) data PT (f :: k -> *) a = MkPT (f a) data PT (f :: k -> *) (a :: k) = MkPT (f a) }}} One oddity is that we'd do (BASELINE) for terms and (RICHARD) for types. But perhaps that's ok. They are different. * Terms ought to be as polymorphic as possible but arguably not types. Examples above. Also, since kind polymorphism is still in its infancy, maybe it's no bad thing if all kind polymorphism is explicitly signalled every time a kind-polymorphic binder is introduced. * Terms have well-established separate type signatures, but we don't have a syntax for separate kind signatures of types and classes. If we moved from (BASELINE) to (RICHARD), some programs that work now would fail: * the original S/T example above * a data type like `PT` where the user did actually want the kind- polymorphic version. But that might be a price worth paying for the simplicity, uniformity, and predictability you'd get in exchange. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 11:13:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 11:13:11 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.f0f1ecb6d5437c10777fe96a83faefe0@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * priority: normal => highest Comment: Did this happen with 7.8.2? It might be a regression with the linker changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 11:56:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 11:56:14 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.074cff519758fde0f4a6644f2be2b508@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): That's right, I asked Michael to file this, I just haven't had time to get to it yet (I've been in merge limbo for the past two days with some of the latest patches, so I may drop some of them at this point). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 13:21:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 13:21:44 -0000 Subject: [GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to Typeable Message-ID: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to Typeable ------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- {{{ $ git clone http://github.com/facebook/Haxl.git Cloning into 'Haxl'... remote: Counting objects: 77, done. remote: Compressing objects: 100% (65/65), done. remote: Total 77 (delta 17), reused 69 (delta 9) Unpacking objects: 100% (77/77), done. $ cd Haxl $ ghc-7.6.3 -O2 tests/Bench.hs -main-is Bench -o tests/Bench-76 [1 of 6] Compiling Haxl.Core.StateStore ( Haxl/Core/StateStore.hs, Haxl/Core/StateStore.o ) [2 of 6] Compiling Haxl.Core.Show1 ( Haxl/Core/Show1.hs, Haxl/Core/Show1.o ) [3 of 6] Compiling Haxl.Core.Util ( Haxl/Core/Util.hs, Haxl/Core/Util.o ) [4 of 6] Compiling Haxl.Core.Types ( Haxl/Core/Types.hs, Haxl/Core/Types.o ) [5 of 6] Compiling Haxl.Core.DataCache ( Haxl/Core/DataCache.hs, Haxl/Core/DataCache.o ) [6 of 6] Compiling Bench ( tests/Bench.hs, tests/Bench.o ) Linking tests/Bench-76 ... $ ./tests/Bench-76 500000 Just (Right 0) insert: 0.87s 500000 lookup: 0.24s $ ./tests/Bench-76 500000 Just (Right 0) insert: 0.87s 500000 lookup: 0.26s $ ghc-7.8.2 -O2 tests/Bench.hs -main-is Bench -o tests/Bench-78 [1 of 5] Compiling Haxl.Core.StateStore ( Haxl/Core/StateStore.hs, Haxl/Core/StateStore.o ) [2 of 5] Compiling Haxl.Core.Show1 ( Haxl/Core/Show1.hs, Haxl/Core/Show1.o ) [3 of 5] Compiling Haxl.Core.Types ( Haxl/Core/Types.hs, Haxl/Core/Types.o ) [4 of 5] Compiling Haxl.Core.DataCache ( Haxl/Core/DataCache.hs, Haxl/Core/DataCache.o ) [5 of 5] Compiling Bench ( tests/Bench.hs, tests/Bench.o ) Linking tests/Bench-78 ... $ ./tests/Bench-78 500000 Just (Right 0) insert: 1.09s 500000 lookup: 0.44s $ ./tests/Bench-78 500000 Just (Right 0) insert: 1.08s 500000 lookup: 0.44s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 14:40:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 14:40:34 -0000 Subject: [GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to Typeable In-Reply-To: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> References: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> Message-ID: <062.f6e503a9a1b68d690e6046ba031f4551@haskell.org> #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to Typeable --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonmar): * cc: tibbe (added) Comment: I've narrowed this down further. It seems to be something to do with `HashMap`. With the following source file: {{{ {-# LANGUAGE RankNTypes, GADTs, BangPatterns, DeriveDataTypeable, StandaloneDeriving #-} {-# OPTIONS_GHC -fno-warn-unused-do-bind -fno-warn-type-defaults #-} module Bench where import Prelude hiding (mapM) import Control.Concurrent import Data.Hashable import Data.Time.Clock import Data.Traversable import Data.Typeable import System.Environment import Text.Printf import qualified Data.HashMap.Strict as HashMap import Data.HashMap.Strict (HashMap) import Unsafe.Coerce data TestReq a where ReqInt :: {-# UNPACK #-} !Int -> TestReq Int deriving Typeable deriving instance Eq (TestReq a) deriving instance Show (TestReq a) instance Hashable (TestReq a) where hashWithSalt salt (ReqInt i) = hashWithSalt salt (0::Int, i) main = do [n] <- fmap (fmap read) getArgs t0 <- getCurrentTime let f 0 !cache = cache f !n !cache = f (n-1) (dcinsert (ReqInt n) 0 cache) -- let !cache = f n dcempty let m = dclookup (ReqInt (n `div` 2)) cache print m t1 <- getCurrentTime printf "insert: %.2fs\n" (realToFrac (t1 `diffUTCTime` t0) :: Double) t0 <- getCurrentTime let f 0 !m = m f !n !m = case dclookup (ReqInt n) cache of Nothing -> f (n-1) m Just _ -> f (n-1) (m+1) print (f n 0) t1 <- getCurrentTime printf "lookup: %.2fs\n" (realToFrac (t1 `diffUTCTime` t0) :: Double) newtype DataCache = DataCache (HashMap TypeRep SubCache) -- | The implementation is a two-level map: the outer level maps the -- types of requests to 'SubCache', which maps actual requests to their -- results. So each 'SubCache' contains requests of the same type. -- This works well because we only have to store the dictionaries for -- 'Hashable' and 'Eq' once per request type. data SubCache = forall req a . (Hashable (req a), Eq (req a)) => SubCache ! (HashMap (req a) a) -- NB. the inner HashMap is strict, to avoid building up -- a chain of thunks during repeated insertions. -- | A new, empty 'DataCache'. dcempty :: DataCache dcempty = DataCache HashMap.empty -- | Inserts a request-result pair into the 'DataCache'. dcinsert :: (Hashable (r a), Typeable (r a), Eq (r a)) => r a -- ^ Request -> a -- ^ Result -> DataCache -> DataCache dcinsert req result (DataCache m) = DataCache $ HashMap.insertWith fn (typeOf req) (SubCache (HashMap.singleton req result)) m where fn (SubCache new) (SubCache old) = SubCache (unsafeCoerce new `HashMap.union` old) -- | Looks up the cached result of a request. dclookup :: Typeable (r a) => r a -- ^ Request -> DataCache -> Maybe a dclookup req (DataCache m) = case HashMap.lookup (typeOf req) m of Nothing -> Nothing Just (SubCache sc) -> unsafeCoerce (HashMap.lookup (unsafeCoerce req) sc) }}} GHC 7.6.3: {{{ Just 0 insert: 0.73s 500000 lookup: 0.23s }}} GHC 7.8.2: {{{ Just 0 insert: 1.01s 500000 lookup: 0.53s }}} `insert` is a bit slower, but `lookup` is more than twice as slow with 7.8.2. Looking at the Core, at lookup in particular, the code in 7.8.2 looks reasonable. But in both cases we end up calling `Data.HashMap.Base.lookup` for the inner lookup, and I'm guessing that is where the inefficiency lies. @tibbe, want to take a look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 14:42:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 14:42:10 -0000 Subject: [GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap (was: Perf regression in 7.8.2 relative to 7.6.3, possibly related to Typeable) In-Reply-To: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> References: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> Message-ID: <062.efbf5c1cf47045780f864814141a29e3@haskell.org> #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 15:00:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 15:00:11 -0000 Subject: [GHC] #95: GHCi :edit command should jump to the the last error In-Reply-To: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> References: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> Message-ID: <067.da1d17aa1370f43e6e8484dd7f532d8f@haskell.org> #95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: lortabac martijnislief | Status: patch Type: feature | Milestone: ? request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: None | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by nomeata): Don?t worry about test names, `prog013` is fine; `T95` would have been another possibility. Ideally, the test case is never looked at again, because nobody breaks this feature. The patch is, IMHO, good to go. I?m validating this right now and will push if validation succeeds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 15:06:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 15:06:48 -0000 Subject: [GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap In-Reply-To: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> References: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> Message-ID: <062.c0712ddd0ebdea5a949924cb1612226f@haskell.org> #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): Hang on, I'm just doing some more investigation in `TypeRep`, I think it might be in there after all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 15:08:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 15:08:59 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.cd7d9d07dcd3ee475e94ab4f938ff530@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by ekmett): Just a thought, in our compiler for Ermine we use a strategy very close to Mark P Jones' strategy with CUSKs. However when we have a type that is not fully what you'd call a CUSK because at least one of the type variables are unannotated we actually allow it to participate in a binding group SCC like any other type. We instantiate '''just''' those unannotated positions in the type with fresh kind variables not all. Then we run through the binding group checking subsumption for each, letting those checks accrete constraints on the unannotated types before we generalize over the whole SCC. A universe level down the code looks like: https://github.com/ermine- language/ermine/blob/master/src/Ermine/Inference/Type.hs#L150 At the kind level the code is in a local branch and I'll push it out to github soon. This lets us fit somewhere in the middle between Mark P Jones' strategy and Richard's. Unannotated variables participate in cycles and unify out to whatever they must, while kind variables supplied explicitly annotated types can't be forced to unify with them without yielding skolem escapes. The rule then becomes that if you annotate some types with a kind involving explicit kind variable in a class declaration all kinds that unify with that kind variable will need to be annotated, but other kinds can be left untouched. In exchange you don't get more specific kinds than you ask for #9201, we can handle partially annotated polymorphic recursion like occurs here, and existing code so long as it doesn't rely on #9201 would still typecheck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 15:39:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 15:39:16 -0000 Subject: [GHC] #95: GHCi :edit command should jump to the the last error In-Reply-To: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> References: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> Message-ID: <067.2339afe74794e5d71192f02a5bd98063@haskell.org> #95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: lortabac martijnislief | Status: patch Type: feature | Milestone: ? request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: None | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Joachim Breitner ): In [changeset:"ce19d5079ea85d3190e837a1fc60000fbd82134d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ce19d5079ea85d3190e837a1fc60000fbd82134d" Fixes #95 :edit command should jump to the last error }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 15:40:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 15:40:05 -0000 Subject: [GHC] #95: GHCi :edit command should jump to the the last error In-Reply-To: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> References: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> Message-ID: <067.474c1656d4197342ab91487487e18ed4@haskell.org> #95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: lortabac martijnislief | Status: closed Type: feature | Milestone: ? request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: None => fixed Comment: Thanks, Lorenzo, for your first contribution to GHC! I hope more will follow :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 16:00:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 16:00:00 -0000 Subject: [GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap In-Reply-To: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> References: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> Message-ID: <062.20d278e3ee318a23cefb76dc1f81405b@haskell.org> #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonmar): * priority: normal => high Comment: Fix: https://phabricator.haskell.org/D19 It would be nice to get this into 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 16:23:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 16:23:53 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.35e56eac62711dc48c2b729a9ce1b5f9@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------+------------------------------------------- Reporter: guest | Owner: archblob Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 6.6.1 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by archblob): * milestone: ? => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 16:28:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 16:28:42 -0000 Subject: [GHC] #9140: Unboxed tuples fails in GHCi (7.8.2) In-Reply-To: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> References: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> Message-ID: <058.bafc33d76aaeb957dff86f95842ba179@haskell.org> #9140: Unboxed tuples fails in GHCi (7.8.2) -------------------------------------+------------------------------------ Reporter: osa1 | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by archblob): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 16:30:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 16:30:20 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.ec3d17301a1d813c408d620d3a9c074e@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): I think Simon got one key detail in (RICHARD) wrong: I ''do'' propose to generalize after kind-checking all the declarations, not defaulting to `*`. The way I see it is this: there is "good" polymorphism and "bad" polymorphism. Here is "good": {{{ type family IsJust x where IsJust Nothing = False IsJust (Just x) = True }}} Without any annotation, I would want to infer `forall k. Maybe k -> *` as the kind for `IsJust`. This goes against Simon's conclusion that all kind polymorphism should be annotated. I actually would argue that the genie about this sort of polymorphism is out of the bottle, and that Simon's proposal would be too big a breaking change. Here is "bad" polymorphism: {{{ type family F x where F Bool = True F Maybe = False }}} It is perfectly reasonable to infer `forall k. k -> *` for the kind of `F`. Indeed, this could even be implemented without too much trouble. (I think I ''did'' implement this behavior along the way to the current behavior for closed type families!) But, I think most users would prefer to get a kind error in this case. If they want this polymorphism, use an annotation. What's the difference between "good" and "bad" polymorphism? "Good" is parametric and "bad" is non-parametric. Hence the name `NonParametricKinds`. The examples above come from type families. Extending these ideas to datatypes is awkward because datatypes don't (currently) support kind- indexing (essentially, being GADT-like in kind parameters) in the right way. The closest we can really get is to think about polymorphic recursion, which is where this all started. Thus, in the context of datatypes and classes, I agree that the name `NonParametricKinds` is bogus. What this all leads to is this: we want to allow "good" polymorphism without an annotation but to allow "bad" polymorphism only if specifically requested. This is exactly the story with closed type families today. And, if I'm understanding all the details correctly, in the datatype/class world, this means that we get non-polymorphic recursion to work all the time, but polymorphic recursion only when requested. After all, if you cross your eyes, polymorphic recursion can look a little like non- parametric polymorphism: both are cases when a type parameter is used inconsistently in a definition. I think the strategy I'm outlining is not unlike the behavior Edward describes in Ermine. The only difference I can spot is that my strategy allows unification variables to unify with skolems, where Ermine's seems to avoid this. For example: {{{ type family G x (y :: k) :: Constraint where G x y = (x ~ y) }}} Here, the kind of `x` must be `k`, but that's acceptable. Would that fail in Ermine? I could certainly see that failure here could be reasonable. As a small aside, I wonder how any of this interacts with the coming partial type signatures at the term level. How do those interact with polymorphic recursion? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 16:48:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 16:48:36 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.45e6376b040affe994b4c8fdc6287ae1@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): Hmm, I was unable to reproduce this with the latest 7.8 commit 32b4bf33989bdda4dffed1866f7a61a7da4ca275. Strange since I assume that's very similar if not identical to your GHC version 7.8.2.20140609. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 16:56:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 16:56:25 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.6ed86638588a987625eb46e72ce128f0@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by ekmett): Currently we'd reject that, but if you can come up with a story that allows it I'd happily switch. We can (and do) use it for partial type signatures by combining it with HMF style "some" annotations, but since we disallow the partial types from referencing the quantified ones (since some can only occur in an Annot, outside of the type) it is perhaps less useful than a design that can do what you want could be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 16:59:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 16:59:56 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.d850e605db284da69a1e90ce75985e9f@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): What's insufficient about the algorithm I've described here? The `G` above is accepted by today's GHC. I don't see where a skolem escape would fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 17:47:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 17:47:48 -0000 Subject: [GHC] #9196: Higher-rank constraint treated as type instead In-Reply-To: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> References: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> Message-ID: <062.19c022cd55bc71cc8d50002e252e8689@haskell.org> #9196: Higher-rank constraint treated as type instead -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by archblob): The patch passes validation and I hope I understood the problem, even if that's not the case, at least I got to learn something new. Even though the pathological type construction can be detected and stopped earlier when checking the type and transforming from HsType to Type, doing so would yeild very bad error message, so the patch checks for a bad type in `check_valid_type` where the check for the same illegal types happens for classes. Even so, the type is not printed as the user wrote it, and this could be a source of confusion. This could be fixed by considering `ForAllTy` in `isPredTy`, but this will brake code because even though in the comments about `isPredTy` it is said that it is only used for printing, I found it used in places not concerning pretty printing. Even used it in tis patch :-P. Maybe there should really be a variation of this function that is only used for pretty printing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 17:49:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 17:49:12 -0000 Subject: [GHC] #9196: Higher-rank constraint treated as type instead In-Reply-To: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> References: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> Message-ID: <062.b8b14eb50a7b23fd67bb22ea96026c8a@haskell.org> #9196: Higher-rank constraint treated as type instead -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by archblob): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 19:07:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 19:07:17 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.f0999fb7498d5fa52d36ebee8e2e1967@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by dolio): Ermine's algorithm for this effectively has an additional quantifier, some. Your `G` definition is effectively equivalent to: {{{ u : a -> a -> T g : some a. forall b. a -> b -> T g x y = u x y }}} 'some' is effectively a quantifier for unification variables. So for instance, if I wrote: {{{ h : some a b. a -> b -> T h x y = u x y }}} checking would succeed, with `h : a -> a -> T`. Also, some cannot occur arbitrarily in a type. It can only occur outer-most in a type ascription. The reason ermine rejects `g` right now is that the metavariable `a` is at an outer level of binding. They cannot be generalized over until the entire SCC is done being checked, while `g` is expecting to be polymorphic in `b`. This is the kind of check that would fail for an example like: {{{ g : some a. forall b. a -> b -> T g x y = h x y h y x = g x y }}} We could try to be more intelligent, and do additional generalization as long as skolems wouldn't flow into other types in the binding group, or something, but we haven't gotten that fancy yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 21:32:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 21:32:41 -0000 Subject: [GHC] #9195: ImpredicativeTypes and ConstraintKinds don't interact as expected In-Reply-To: <050.891dda4540243320d80c0b42f302fbb5@haskell.org> References: <050.891dda4540243320d80c0b42f302fbb5@haskell.org> Message-ID: <065.ef041eb6dce9622379a68808a4a9c649@haskell.org> #9195: ImpredicativeTypes and ConstraintKinds don't interact as expected ----------------------------------------------+---------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: Indeed. See also the feature request #2893. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 23:09:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 23:09:56 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.ea31d99bcf95aa34ea7306cedd425e0b@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------+------------------------------------------- Reporter: aspidites | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by monoidal): There's one more tuple unpacking in your patch: `lambda b, d, n`. I'm afraid there are more things to change for full compatibility. It seems we run the testsuite using python2 if it is detected (see defn of `PYTHON` in `testsuite/mk/boilerplate.mk`). If I change it to `PYTHON = python3`, I get several errors with `sh validate --testsuite-only`: `execfile` is no longer available (should become something like `with open(..., 'r') as f: exec(f.read())`), `from string import join` should become string's `join` method, `reduce` is no longer builtin (needs import from functools), `import thread` should become `import _thread` for 3, `sys.stdout = os.fdopen(sys.__stdout__.fileno(), "w", 0)` fails (I stopped at that one). Would you be willing to take a look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 13 23:19:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jun 2014 23:19:48 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.38a5251be594e503dd1d9a161fee0a8f@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------+------------------------------------------- Reporter: aspidites | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by aspidites): Wow. I thought this was more trivial then it apparently is. I'll run the full test suite this weekend under both python 2 and 3 and submit another patch. I might actually just start fresh and see if I can come up with a solution that honors python 2.5 as well (though there are at least two places that are python 2.5 incompatible already). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 14 00:42:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jun 2014 00:42:37 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.1d0761382200a032b117c19f5d0f2168@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by dolio): Having thought about this some, I realized that there's no reason to fail due to skolems 'escaping' into other types of the binding group, since we're about to generalize all the types anyway. So I've tweaked our algorithm to not care about that. Now the equivalent of your G example checks, and so does my example above: {{{ g : some a. forall b. a -> b -> T g x y = h x y h y x = g x y }}} yields: {{{ g : forall b. b -> b -> T h : forall b. b -> b -> T }}} This seems sensible to me, and sounds like your proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 14 01:12:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jun 2014 01:12:28 -0000 Subject: [GHC] #9202: Strange Closure Type In-Reply-To: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> References: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> Message-ID: <064.8f8987201185ef1e7b97cd2ad8c8e544@haskell.org> #9202: Strange Closure Type -------------------------------------+------------------------------------- Reporter: athanclark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strange-closure- Operating System: Linux | type Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Project (more Test Case: | than a week) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Comment (by carter): could you upload whats in your ~/.cabal/config -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 14 08:27:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jun 2014 08:27:20 -0000 Subject: [GHC] #9204: Conflicting definition in hs-boot file Message-ID: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> #9204: Conflicting definition in hs-boot file ------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Foo.hs: {{{ module Foo where import Bar data Foo a }}} Foo.hs-boot: {{{ module Foo where data Foo a }}} Bar.hs: {{{ module Bar where import {-# SOURCE #-} Foo }}} With GHC 7.8.2 I'm getting the error {{{ Foo.hs-boot:3:1: Type constructor ?Foo? has conflicting definitions in the module and its hs-boot file Main module: type role Foo phantom data Foo a Boot file: data Foo a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 14 08:35:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jun 2014 08:35:41 -0000 Subject: [GHC] #9204: Conflicting definition in hs-boot file In-Reply-To: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> References: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> Message-ID: <063.a82e0ada214f117193567df166be833c@haskell.org> #9204: Conflicting definition in hs-boot file -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Feuerbach): If I add a role annotation to the hs-boot file, this works. My guess is that since the hs-boot doesn't have the complete information about the type, it cannot infer the phantom role of the parameter. Still, I wish I didn't have to deal with this. But if this isn't possible, at least the error message should suggest adding the role annotation to the hs-boot file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 14 08:36:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jun 2014 08:36:16 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.c06a31c5598d2f25f0426d44c601f39c@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Fwiw, I can confirm this with the current `ghc-7.8.3` PPA `.deb` which is supposed to correspond to 32b4bf33989bdda4dffed1866f7a61a7da4ca275 Fwiw, `ghc-7.8.3-7.8.2.20140609-1` reports the wrong version (`7.8.2.20140603`) due to a stale `VERSION` file in the tharball, that's supposed to be fixed by `ghc-7.8.3-7.8.2.20140609-2` which is building right now -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 14 08:37:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jun 2014 08:37:55 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.a817a68d84165a795c2e7a44703c636f@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): moreover, Simon suggested on `#ghc` that > if #9186 is a regression, it is almost certainly caused by 2f8b4c9330b455d4cb31c186c747a7db12a69251, but it's probably best to just back that out if it's the last thing holding up the release -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 14 12:06:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jun 2014 12:06:03 -0000 Subject: [GHC] #9204: Conflicting definition in hs-boot file In-Reply-To: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> References: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> Message-ID: <063.5e11e3eda4230876250775daeb1e0d98@haskell.org> #9204: Conflicting definition in hs-boot file -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * owner: => goldfire * component: Compiler => Documentation Comment: Replying to [comment:1 Feuerbach]: > If I add a role annotation to the hs-boot file, this works Yes, that's the solution. . > My guess is that since the hs-boot doesn't have the information about the data constructors, it cannot infer the phantom role of the parameter. Yes. As documented [http://www.haskell.org/ghc/docs/latest/html/users_guide/separate- compilation.html#mutual-recursion here], in the last bullet point before 4.7.10, role inference in hs-boot files defaults to representational, the most common case. > Still, I wish I didn't have to deal with this. But if this isn't possible, at least the error message should suggest adding the role annotation to the hs-boot file. Yes, absolutely. I will fix in due course, and clarify some of this in the manual as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 14 14:02:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jun 2014 14:02:21 -0000 Subject: [GHC] #9202: Strange Closure Type In-Reply-To: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> References: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> Message-ID: <064.40a444b7aa46e33e3364a4b5e0b964fc@haskell.org> #9202: Strange Closure Type -------------------------------------+------------------------------------- Reporter: athanclark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strange-closure- Operating System: Linux | type Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Project (more Test Case: | than a week) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Comment (by athanclark): Yes, here is the whole file: http://lpaste.net/105592 Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 14 15:49:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jun 2014 15:49:43 -0000 Subject: [GHC] #9046: Panic in GHCi when using :print In-Reply-To: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> References: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> Message-ID: <060.4ef4eaf2aa7a770e6190f6ab817371a0@haskell.org> #9046: Panic in GHCi when using :print -------------------------------------+------------------------------------ Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bravit): Another strange result made visible using `-fprint-explicit-foralls`: {{{ $ ghci -fprint-explicit-foralls GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > let a = [1] > :print a a = (_t1::Num t => [t]) > :show bindings a :: forall t. Num t => [t] = _ _t1 :: Num t => [t] = _ }}} It looks like free type variable `t` in the signature of `_t1` causes GHC panic while typechecking it. But I can't figure out whether it is a bug of rtti type reconstruction in `:print` or incorrect behaviour during typechecking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 14 20:05:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jun 2014 20:05:10 -0000 Subject: [GHC] #9205: Deriving Typeable for poly-kinded data family gives confusing error message Message-ID: <046.527ed5076d77c49d2494e387d691216d@haskell.org> #9205: Deriving Typeable for poly-kinded data family gives confusing error message ------------------------------------+------------------------------------- Reporter: dfranke | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The following works fine: {{{ {-# LANGUAGE TypeFamilies, DeriveDataTypeable, StandaloneDeriving #-} module Test where import Data.Typeable class Foo a where data family Bar a deriving instance (Typeable Bar) }}} However, if I add `-XPolyKinds`, I get a horribly confusing error: {{{ Test.hs:9:1: Can't make a derived instance of ?Typeable Bar?: Deriving Typeable is not allowed for family instances; derive Typeable for ?Bar? alone In the stand-alone deriving instance for ?Typeable Bar? }}} The correct way to resolve the error is to add a monomorphic kind signature to Bar, e.g. `data family Bar (a :: *)`. Perhaps the error message could suggest this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 14 21:51:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jun 2014 21:51:41 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.8d84ea3be1d2cf97a4bcca458a2e52ba@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Comment (by Iavor S. Diatchki ): In [changeset:"0354fb3676e5b0044601c8e0a5f8039f0cac0c8d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0354fb3676e5b0044601c8e0a5f8039f0cac0c8d" Implement `Typeable` support for type-level literals (#8778). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 14 23:32:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jun 2014 23:32:15 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.2df659bd6b4d8ceeb37bca63f6d3a3d8@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Comment (by sjoerd_visscher): Should the performance fix from #9203 be applied here too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 00:49:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 00:49:58 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.94946d9cd52b73eee855f0b9b8d27a77@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Comment (by diatchki): I'd be happy to make whatever changes are needed, but could you summarize what I should do? The #9203 ticket just talks about HashMaps, and there is a link to Phabricator, but I don't have an account for that... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 04:36:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 04:36:44 -0000 Subject: [GHC] #9046: Panic in GHCi when using :print In-Reply-To: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> References: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> Message-ID: <060.5a58009dac4fa8e76f32d60066c5862b@haskell.org> #9046: Panic in GHCi when using :print -------------------------------------+------------------------------------ Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bravit): No problem for unbounded polymorphic type variable: {{{ $ ghci -fprint-explicit-foralls GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > :t length length :: forall a. [a] -> Int > :print length length = (_t1::[a] -> Int) > :t _t1 _t1 :: [a] -> Int }}} But: {{{ > :t read read :: forall a. Read a => String -> a > :print read read = (_t2::Read a1 => String -> a1) > :t _t2 ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcTyVarDetails a1{tv asM} [tv] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 05:31:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 05:31:09 -0000 Subject: [GHC] #9046: Panic in GHCi when using :print In-Reply-To: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> References: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> Message-ID: <060.1d9db3be1d27635b66391d539158f83b@haskell.org> #9046: Panic in GHCi when using :print -------------------------------------+------------------------------------ Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bravit): We had different behaviour for `:print` back in 7.6.3: {{{ $ ghci -fprint-explicit-foralls GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help > :print read read = (_t1::forall a. Read a => String -> a) > :t _t1 _t1 :: forall a. Read a => String -> a > :print length length = (_t2::forall a. [a] -> Int) > :t _t2 _t2 :: forall a. [a] -> Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 08:21:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 08:21:35 -0000 Subject: [GHC] #9046: Panic in GHCi when using :print In-Reply-To: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> References: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> Message-ID: <060.aa8ea9cca95fde1ffa008d6f0c076dce@haskell.org> #9046: Panic in GHCi when using :print -------------------------------------+------------------------------------ Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bravit): All right, removing of enclosing foralls during `:print` was intentional according to this commit: > In a8ac471d435214dbdc1fa70f938c63128993a1db/ghc: > Fix the deugger (fixing Trac #8557) > > The runtime debugger (which has not received any love from anyone > for many years) looks wrong to me; it was failing to instantiate the > outer foralls of a variable when called from :force, which calls > cvObtainTermFromId, which calls cvObtainTerm > > I simplified the code too. But I'm flaky on how this debugger stuff > is really supposed to work, so I'm partly guessing. Tests pass though. SPJ particularly wrote in `compiler/ghci/RtClosureInspect.hs`: {{{ +-- Generalize the type: find all free and forall'd tyvars +-- and return them, together with the type inside, which +-- should not be a forall type. }}} So now it looks like typechecking issue with free bounded polymorphic tyvars: free type variable is built by `TyVar` constructor of `Var` and it stays the same during typechecking. In the presence of constraints (if tyvar is bounded) we try to solve them and then get this GHC panic: we need `TcTyVar` constructor there. I suppose solution could be to replace free tyvar with `TcTyVar` before solving constraints though I need some guidance to implement it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 12:35:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 12:35:37 -0000 Subject: [GHC] #9206: OverloadedString breaks show? Message-ID: <054.f2651fc0f70b38fc1158c5aef9677e6d@haskell.org> #9206: OverloadedString breaks show? ------------------------------------+------------------------------------- Reporter: j80JjBjVNRMajmA | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The file `test.hs` contains {{{ import GHC.Exts main = putStrLn $ show (fromString "01") }}} and results in: `ghc -XNoOverloadedStrings test.hs` {{{ overloadedString.hs:4:20: No instance for (Show a0) arising from a use of ?show? The type variable ?a0? is ambiguous Note: there are several potential instances: instance Show Double -- Defined in ?GHC.Float? instance Show Float -- Defined in ?GHC.Float? instance (Integral a, Show a) => Show (GHC.Real.Ratio a) -- Defined in ?GHC.Real? ...plus 44 others In the second argument of ?($)?, namely ?show (fromString "01")? In the expression: putStrLn $ show (fromString "01") In an equation for ?main?: main = putStrLn $ show (fromString "01") overloadedString.hs:4:26: No instance for (IsString a0) arising from a use of ?fromString? The type variable ?a0? is ambiguous Note: there is a potential instance available: instance IsString [Char] -- Defined in ?Data.String? In the first argument of ?show?, namely ?(fromString "01")? In the second argument of ?($)?, namely ?show (fromString "01")? In the expression: putStrLn $ show (fromString "01") }}} OverloadedStrings breaks things (by making them magically work, which is probably why nobody complained?) `ghc -XOverloadedStrings -e main test.hs` {{{ "01" }}} and another `test2.hs`: {{{ import GHC.Exts instance IsString Double where fromString = read main = putStrLn $ show (fromString "01") }}} `ghc -XOverloadedStrings -e main test2.hs` {{{ "1.0" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 12:45:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 12:45:56 -0000 Subject: [GHC] #9206: OverloadedStrings breaks show? (was: OverloadedString breaks show?) In-Reply-To: <054.f2651fc0f70b38fc1158c5aef9677e6d@haskell.org> References: <054.f2651fc0f70b38fc1158c5aef9677e6d@haskell.org> Message-ID: <069.f62a8bbb8e8f30e0f430693b2c75ae8e@haskell.org> #9206: OverloadedStrings breaks show? -------------------------------------+------------------------------------ Reporter: j80JjBjVNRMajmA | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 16:11:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 16:11:44 -0000 Subject: [GHC] #9207: Detect obvious cases of infinite recursion. Message-ID: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> #9207: Detect obvious cases of infinite recursion. --------------------------------------+------------------------------------ Reporter: mrugiero | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: infinite recursion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: --------------------------------------+------------------------------------ Pure functions are guaranteed to return the same value if the same arguments are used. Because of that, a compiler could be able to detect infinite recursion in the form of a function calling itself with the same arguments (case, some distracted programmer forgot to apply the function tail to a list). The way I see it, one of Haskell's main selling points is that it helps the programmer to avoid sources of bugs as much as it can, and infinite recursion is one of the few that stand unchecked. I specifically point to this example because both, I'm a newbie and made that newbie mistake, and think it shouldn't be hard to implement to the parsing stage of the compiler/interpreter. It probably should throw an error when this happens in pure functions, and maybe an opt-in warning if it happens in monads. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 16:39:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 16:39:32 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) Message-ID: <044.558797842cec9427e028f9e25a777548@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) ------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- tested with GHC 7.8 branch commit 32b4bf33989bdda4dffed1866f7a61a7da4ca275 and GHC 7.8.2 compile with -O or -O2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 19:15:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 19:15:49 -0000 Subject: [GHC] #9207: Detect obvious cases of infinite recursion. In-Reply-To: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> References: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> Message-ID: <062.8b6596fca5e184b754bb0c2243e73a61@haskell.org> #9207: Detect obvious cases of infinite recursion. ------------------------------------+-------------------------------------- Reporter: mrugiero | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: infinite recursion Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | ------------------------------------+-------------------------------------- Comment (by j80JjBjVNRMajmA): In a lazy language, writing and using infinite recursions is a feature! There is no way, unintentional infinite recursion could be captured by the compiler. Take a look at the perfectly good and useful function `repeat`: {{{ repeat :: a -> [a] repeat x = x : repeat x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 19:33:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 19:33:32 -0000 Subject: [GHC] #9207: Detect obvious cases of infinite recursion. In-Reply-To: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> References: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> Message-ID: <062.abdd40ce65a1253e124fb383ba91949b@haskell.org> #9207: Detect obvious cases of infinite recursion. ------------------------------------+-------------------------------------- Reporter: mrugiero | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: infinite recursion Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | ------------------------------------+-------------------------------------- Comment (by mrugiero): Can you put an example of use of that function? Because I don't really see right now (and as I said, I'm just learning the language) creating an infinite list is good or useful. It just sounds like a blown up stack to me, whenever the list actually gets created. I guess this moment will be, thankfully, whenever a tail recursion starts using the generated values, am I right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 19:43:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 19:43:37 -0000 Subject: [GHC] #9207: Detect obvious cases of infinite recursion. In-Reply-To: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> References: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> Message-ID: <062.b526ef0a15d506f72ca6164fef1ecbec@haskell.org> #9207: Detect obvious cases of infinite recursion. ------------------------------------+-------------------------------------- Reporter: mrugiero | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: infinite recursion Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | ------------------------------------+-------------------------------------- Comment (by j80JjBjVNRMajmA): You will get used to infinite lists in Haskell. Do you know this one `[1..]`? `repeat` is defined in Data.List (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data- List.html) and also used there to define `replicate`. One importat use case is to define the `ZipList` Applicative instance: {{{ pure = ZipList . repeat }}} in https://hackage.haskell.org/package/base-4.7.0.0/docs/Control- Applicative.html#t:ZipList. It is hard to motivate all the greatness the Haskell-way brings in a Bug- comment. Another note on topic: Merely checking, that the recursive function call has different arguments does not protect you from infinite recusion: {{{ f x = f $ x + 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 19:51:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 19:51:58 -0000 Subject: [GHC] #9207: Detect obvious cases of infinite recursion. In-Reply-To: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> References: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> Message-ID: <062.2e22dbbf04204bdb65111592f827928f@haskell.org> #9207: Detect obvious cases of infinite recursion. ------------------------------------+-------------------------------------- Reporter: mrugiero | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: infinite recursion Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | ------------------------------------+-------------------------------------- Comment (by mrugiero): I'll look into those in a minute (I'm trying to finish another chapter of real world Haskell right now :) ), but in the meantime I want to clarify on your last comment that it's exactly why I put the "obvious" part in the title of the FR. When it's the same function calling itself with the same arguments it's really obvious, as long as it's pure, that it will end up in infinite recursion. I left implicit that non-obvious causes of infinite recursion wouldn't be intercepted by this. I didn't mention those because those would be harder for the compiler to catch, and the harder it gets the more it becomes proper of a static analysis tool to avoid wasting time at every compilation cycle. The obvious ones are the one that might belong to the compiler. But if you say it's part of the power of the language, I guess you must be right, I hope I'll understand why soon :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 23:49:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 23:49:47 -0000 Subject: [GHC] #9209: Template haskell panic Message-ID: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> #9209: Template haskell panic ------------------------------------+------------------------------------- Reporter: tulcod | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I was trying to get some template haskell thing to work and was messing around and ran into this bug. Prelude> let $([d||]) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): cvBindsAndSigs $[splice{v}]([d| |]) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude> The following file: {-# LANGUAGE TemplateHaskell #-} let $([d||]) main = do return () gives the following error message: test.hs:3:1: parse error (possibly incorrect indentation or mismatched brackets) but doesn't crash. So it seems to be ghci-specific...? the other oxford brackets work fine (or don't suffer from exactly the same bug, anyway) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 23:50:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 23:50:50 -0000 Subject: [GHC] #9209: Template haskell panic In-Reply-To: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> References: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> Message-ID: <060.6ab91cabf5bbce9cdefa2ce7079c0ba4@haskell.org> #9209: Template haskell panic -------------------------------------+------------------------------------ Reporter: tulcod | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by tulcod: Old description: > I was trying to get some template haskell thing to work and was messing > around and ran into this bug. > > Prelude> let $([d||]) > ghc: panic! (the 'impossible' happened) > (GHC version 7.8.2 for x86_64-unknown-linux): > cvBindsAndSigs $[splice{v}]([d| |]) > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > Prelude> > > The following file: > {-# LANGUAGE TemplateHaskell #-} > let $([d||]) > main = do > return () > > gives the following error message: > > test.hs:3:1: > parse error (possibly incorrect indentation or mismatched brackets) > > but doesn't crash. So it seems to be ghci-specific...? > > > the other oxford brackets work fine (or don't suffer from exactly the > same bug, anyway) New description: I was trying to get some template haskell thing to work and was messing around and ran into this bug. {{{ Prelude> let $([d||]) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): cvBindsAndSigs $[splice{v}]([d| |]) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude> }}} The following file: {{{ {-# LANGUAGE TemplateHaskell #-} let $([d||]) main = do return () }}} gives the following error message: {{{ test.hs:3:1: parse error (possibly incorrect indentation or mismatched brackets) }}} but doesn't crash. So it seems to be ghci-specific...? the other oxford brackets work fine (or don't suffer from exactly the same bug, anyway) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 15 23:51:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jun 2014 23:51:12 -0000 Subject: [GHC] #9207: Detect obvious cases of infinite recursion. In-Reply-To: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> References: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> Message-ID: <062.7e2db742ffbf3f53f567c9d8ea78b1c3@haskell.org> #9207: Detect obvious cases of infinite recursion. ------------------------------------+-------------------------------------- Reporter: mrugiero | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: infinite recursion Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | ------------------------------------+-------------------------------------- Changes (by Fuuzetsu): * status: new => closed * resolution: => invalid Comment: As pointed out, there are no ?obvious? cases of infinite recursion that the programmer doesn't actually want that GHC could catch, at least not in the way you stated. I'll close the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 00:51:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 00:51:06 -0000 Subject: [GHC] #9207: Detect obvious cases of infinite recursion. In-Reply-To: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> References: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> Message-ID: <062.a67e34451382e9e338a335478413087b@haskell.org> #9207: Detect obvious cases of infinite recursion. ------------------------------------+-------------------------------------- Reporter: mrugiero | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: infinite recursion Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | ------------------------------------+-------------------------------------- Comment (by altaic): I don't think, in principal, this is a bad idea, but it is part of a very challenging problem: static complexity (time and space) analysis. There are quite a few papers on the topic, which I can post here if there's interest. In general it is undecidable, but there are many situations where it is not. I plan on opening a ticket for just that when I form a sensible plan of attack (though it might be awhile, since I'm currently focusing on more pragmatic issues). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 01:08:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 01:08:32 -0000 Subject: [GHC] #9207: Detect obvious cases of infinite recursion. In-Reply-To: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> References: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> Message-ID: <062.658e82adb54dee81fafef66092917071@haskell.org> #9207: Detect obvious cases of infinite recursion. ------------------------------------+-------------------------------------- Reporter: mrugiero | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: infinite recursion Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | ------------------------------------+-------------------------------------- Comment (by mrugiero): Those papers certainly sound interesting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 07:03:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 07:03:25 -0000 Subject: [GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap In-Reply-To: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> References: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> Message-ID: <062.ce23b2f525dfe2c7f8640a896af4c8ec@haskell.org> #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Yes, great fix, let's get it in as soon as poss. I've added Phab comment thought. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 07:04:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 07:04:06 -0000 Subject: [GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap In-Reply-To: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> References: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> Message-ID: <062.d0cd0ecf27a39faffdabec1acfd7788d@haskell.org> #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * status: new => merge Comment: I'm going to change the status to 'merge' even though it's not in HEAD, so that Austin doesn't miss it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 07:12:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 07:12:45 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.6d89164bdb9c7110254f5d6481076f87@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by simonpj: Old description: > When testing ghc-7.8.2.20140609 with Stackage, I came across the > following ghc panic: > > [51 of 62] Compiling Data.Comp.Ordering ( src/Data/Comp/Ordering.hs, > dist/build/Data/Comp/Ordering.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.8.2.20140609 for x86_64-unknown-linux): > Loading temp shared object failed: /tmp/ghc4836_0/ghc4836_257.so: > undefined symbol: > compdatazm0zi8zi1zi0_DataziCompziDeriveziUtils_zdwabstractConType_info > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > Failed to install compdata-0.8.1.0 New description: When testing ghc-7.8.2.20140609 with Stackage, I came across the following ghc panic: {{{ [51 of 62] Compiling Data.Comp.Ordering ( src/Data/Comp/Ordering.hs, dist/build/Data/Comp/Ordering.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2.20140609 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc4836_0/ghc4836_257.so: undefined symbol: compdatazm0zi8zi1zi0_DataziCompziDeriveziUtils_zdwabstractConType_info Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Failed to install compdata-0.8.1.0 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 07:54:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 07:54:33 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.d77bb1e76f1d8cee972b2dbb54aabb1c@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * cc: dimitris@?, sweirich@? (added) Comment: * I have started a [wiki:GhcKinds/KindInference wiki page to record these alternative designs]. * I'm afraid that I do not understand how you distinguish "good" from "bad" polymorphism. Examples are not enough! * I'm afraid I do understand Ermine's algorithm. Could I ask you to write a section on the wiki page that describes as clearly, as you possibly can, the designs you have in mind? That would make sure we are all talking about the same thing. By the same token, if you don't understand anything in the designs I have described there, please say so and I'll clarify. I'm adding Stephanie and Dimitrios in cc Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 08:10:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 08:10:15 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.a97a054c2799806d124c497618bf7269@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Comment (by simonpj): The issue in #9203 is that a `Typeable` instance should look like {{{ instance Typeable ... where typeRep# = \_ -> rep where rep = ...blah... }}} and NOT like {{{ instance Typeable ... where typeRep# p = ...blah... }}} to ensure that the computation of `rep` is shared among all invocations of `typeRep#`. So Sjoerd is quite right, I think. (I'm a bit confused because I thought we only allowed machine-generated instances of `Typeable`.) BTW if you have a Github account you automatically have a Phabricator account. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 08:38:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 08:38:46 -0000 Subject: [GHC] #9190: Iface type variable out of scope: s In-Reply-To: <046.ae688232714aa8206efce4424bf2e376@haskell.org> References: <046.ae688232714aa8206efce4424bf2e376@haskell.org> Message-ID: <061.48d2665d65ccc04c42fb2bf1f7bb4892@haskell.org> #9190: Iface type variable out of scope: s -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): PS: this doesn't affect the GHC 7.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 12:39:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 12:39:12 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.ea8be9f4b7fd153eafb9b5665137e4c1@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dreixel): I've had a look at this, and all seems fine to me. One caveat however: {{{ instance (Data p, Data (f p), Typeable c, Typeable i, Typeable f) => Data (M1 i c f p) where }}} This `Typeable c` constraint will require changing the generation of `Generic` instances in GHC, because these `c`s are compiler-generated empty datatypes, which currently do not derive `Typeable`. Simon: what's the best way to do this? We need `Typeable` instances for the stuff generated by `mkBindsMetaD` in `TcGenGenerics`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 12:52:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 12:52:56 -0000 Subject: [GHC] #9210: "overlapping instances" through FunctionalDependencies Message-ID: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> #9210: "overlapping instances" through FunctionalDependencies -------------------------------------------+------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- This program prints `("1",2)`, but if you reverse the order of the two instances, it prints `(1,"2")`. {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} -- extracted from http://lpaste.net/105656 import Control.Applicative import Data.Functor.Identity modify :: ((a -> Identity b) -> s -> Identity t) -> (a -> b) -> (s -> t) modify l f s = runIdentity (l (Identity . f) s) class Foo s t a b | a b s -> t where foo :: Applicative f => (a -> f b) -> s -> f t instance Foo (x, a) (y, a) x y where foo f (a,b) = (\fa -> (fa,b)) <$> f a instance Foo (a, x) (a, y) x y where foo f (a,b) = (\fb -> (a,fb)) <$> f b main = print $ modify foo (show :: Int -> String) (1 :: Int, 2 :: Int) }}} Note that the two instances involved `Foo (Int, Int) (String, Int) Int String` and `Foo (Int, Int) (Int, String) Int String` are not actually overlapping. But, they have the same `a`, `b`, and `s` fields and it seems that this makes GHC think that either one is equally valid, thanks to the fundep. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 12:56:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 12:56:27 -0000 Subject: [GHC] #9210: "overlapping instances" through FunctionalDependencies In-Reply-To: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> References: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> Message-ID: <062.4f1c58dc094d617791b75fda2fe7556f@haskell.org> #9210: "overlapping instances" through FunctionalDependencies --------------------------------------------+------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by ekmett): * cc: ekmett@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 12:57:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 12:57:01 -0000 Subject: [GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap In-Reply-To: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> References: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> Message-ID: <062.42007a95c8dc1a8004bcb83b6180db8f@haskell.org> #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Marlow ): In [changeset:"5ffc68bb75d34414987b5d1e5aa4f9061a7a7383/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5ffc68bb75d34414987b5d1e5aa4f9061a7a7383" Fix recomputation of TypeRep in the instance for Typeable (s a) (#9203) Summary: Every time we called typeRep on a type application, we were recomputing the TypeRep. This showed up in a benchmark I had: #9203. Test Plan: Benchmark from #9203. Reviewers: simonpj, austin Subscribers: simonmar, relrod Differential Revision: https://phabricator.haskell.org/D19 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 12:57:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 12:57:02 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.3c4a9d85574ef3ebfd6ce77a28222211@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Well I suppose you'd need to derive `Typeable` for these generated data types. Mind you, IIRC now that we have `DataKinds` I think the Generics stuff could be done much more neatly, dramatically reducing the number of generated data types. This is all code you wrote, Pedro, isn't it? So you are definitely free to improve it! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 13:01:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 13:01:45 -0000 Subject: [GHC] #9211: Untouchable type variable (regression from 7.6) Message-ID: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> #9211: Untouchable type variable (regression from 7.6) ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Oleg says: what used to type check in GHC 7.4.1 (and I think in 7.6.2, although I no longer have access to that version) fails in GHC 7.8.2. The following program type-checks with GHC 7.4.1 and GHC 7.8.2: {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module T where foo :: (forall f g. (Functor f) => f a -> f b) -> [a] -> [b] -- foo :: (forall f g. (Functor f, g ~ f) => g a -> g b) -> [a] -> [b] foo tr x = tr x t = foo (fmap not) [True] }}} The following code (which differs only in the signature of foo) {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module T where -- foo :: (forall f g. (Functor f) => f a -> f b) -> [a] -> [b] foo :: (forall f g. (Functor f, g ~ f) => g a -> g b) -> [a] -> [b] foo tr x = tr x t = foo (fmap not) [True] }}} type-checks with 7.4.1 but not with 7.8.2. The latter reports the error {{{ Couldn't match type `b' with `Bool' `b' is untouchable inside the constraints (Functor f, g ~ f) bound by a type expected by the context: (Functor f, g ~ f) => g Bool -> g b at /tmp/t.hs:12:5-25 `b' is a rigid type variable bound by the inferred type of t :: [b] at /tmp/t.hs:12:1 Expected type: Bool -> b Actual type: Bool -> Bool Relevant bindings include t :: [b] (bound at /tmp/t.hs:12:1) In the first argument of `fmap', namely `not' In the first argument of `foo', namely `(fmap not)' }}} Giving `t` the type signature `[Bool]` fixes the problem. Alas, I come across the similar untouchable error in situations where giving the type signature is quite difficult (in local bindings, with quite large types). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 13:02:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 13:02:00 -0000 Subject: [GHC] #9211: Untouchable type variable (regression from 7.6) In-Reply-To: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> References: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> Message-ID: <061.518a70dc55b9d50478c2365cfc3e46a4@haskell.org> #9211: Untouchable type variable (regression from 7.6) -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * cc: oleg@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 13:05:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 13:05:53 -0000 Subject: [GHC] #9211: Untouchable type variable (regression from 7.6) In-Reply-To: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> References: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> Message-ID: <061.beeb85cddefed4865a45e7e76452f70f@haskell.org> #9211: Untouchable type variable (regression from 7.6) -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): This looks right to me, and 7.4 looks wrong. There really is an equality `(f ~ g)` in the context, and so it's in general unsafe to fix `b` to `Bool`. That's what the !OutsideIn paper is all about. In this case the equality is trivial but presumably it's not trivial in your real example. For a trivial equality like this, perhaps GHC is over-conservative, but lifting that would require yet more special-case pleading. And I'm not sure it'd fix your real example anyway. In short, I don't know how to help. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 13:10:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 13:10:57 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.90773ea07316b4f289f020a99e8a54b6@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dreixel): Replying to [comment:14 simonpj]: > Well I suppose you'd need to derive Typeable for these generated data types. Ok, I'll do that; I hope it doesn't require much plumbing. Replying to [comment:14 simonpj]: > Mind you, IIRC now that we have `DataKinds` I think the Generics stuff could be done much more neatly, dramatically reducing the number of generated data types. > > This is all code you wrote, Pedro, isn't it? So you are definitely free to improve it! Sure. All I'm worried about is backwards-compatibility, and the lack of #6024 doesn't help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 13:15:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 13:15:12 -0000 Subject: [GHC] #9210: "overlapping instances" through FunctionalDependencies In-Reply-To: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> References: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> Message-ID: <062.2f171416157867f6341f62afe39e6f3e@haskell.org> #9210: "overlapping instances" through FunctionalDependencies --------------------------------------------+------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by rwbarton): * version: 7.8.1 => 7.8.2 Comment: Oh, since I minimized the example now I can test more easily with other GHC versions. This is a regression from GHC 7.6.3, in that that version rejected `main` with the following error (that I don't really understand): {{{ some.hs:22:23: Couldn't match type `Int' with `String' When using functional dependencies to combine Foo (a, x) (a, y) x y, arising from the dependency `a b s -> t' in the instance declaration at some.hs:19:10 Foo (Int, Int) (String, Int) Int String, arising from a use of `foo' at some.hs:22:23-25 In the first argument of `modify', namely `foo' In the second argument of `($)', namely `modify foo (show :: Int -> String) (1 :: Int, 2 :: Int)' Failed, modules loaded: none. }}} If I remove `main` then GHC 7.6.3 does accept the instances, though. That seems wrong to me also (though certainly "less wrong"). I have a GHC 7.8.2.20140609 lying around and it displays the same behavior as GHC 7.8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 13:17:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 13:17:21 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.1acfaaf0a5bc0304b0c065b3e551d9b5@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by simonpj): The VOODOO CODING is of course wrong. Take a look at the version for `BindStmt` in (for example) `tcMcStmt`, in `TcMatches` line 511. We are typechecking `pat <- rhs; body` as if it was `(>>=) rhs (\x -> body)`. So we instantiate `(>>=)`, expecting its type to have the shape {{{ rhs_ty -> (pat_ty -> body_ty) }}} That's what `tcSyntaxOp` does. Then we check that `pat` really does have type `pat_ty` and `rhs` really does have type `rhs_ty`. Presumably you need to do similar things for arrows, but I'm not deep enough into it to know how. Doing the instantiation once, at `CmdTop` will almost certainly not work. I'm sorry not to be more helpful. Why not follow Ross's suggestions in comment 17? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 13:18:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 13:18:09 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.0118a4801f842e2caecf70a5c326c9dd@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I'm all for #6024 if you want to tackle that :-)! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 13:20:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 13:20:34 -0000 Subject: [GHC] #6024: Allow defining kinds alone, without a datatype In-Reply-To: <046.e44bc03833a60dff474759358b4e4e3f@haskell.org> References: <046.e44bc03833a60dff474759358b4e4e3f@haskell.org> Message-ID: <061.fd28246d2471e578c61c6297e3e9120f@haskell.org> #6024: Allow defining kinds alone, without a datatype --------------------------------------------+------------------------------ Reporter: dreixel | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by dreixel): * cc: diatchki@? (added) Comment: Iavor, you worked on this for a while, didn't you? What's the status? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 13:23:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 13:23:53 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.e2b5b8d7656261002485bede625a0e80@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): Added some comments (delineated with '''Richard:''' ... '''End Richard''') to the [GhcKinds/KindInference wiki page]. I believe the (PARGEN) option you describe there agrees with my proposal. I also believe that my proposed algorithm now (with dolio's changes to Ermine) matches Ermine's. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 13:38:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 13:38:07 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.9e4879cc5cdb6371a95fb6fa4c1feecc@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ocharles): I'd be interested in helping tidy up the stuff in GHC.Generics to use data kinds, btw. So dreixel, if that's something that you think is somewhat obvious and wouldn't mind me doing it - just let me know! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 14:01:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 14:01:39 -0000 Subject: [GHC] #9205: Deriving Typeable for poly-kinded data family gives confusing error message In-Reply-To: <046.527ed5076d77c49d2494e387d691216d@haskell.org> References: <046.527ed5076d77c49d2494e387d691216d@haskell.org> Message-ID: <061.c36956e1b6f21085a1a0f4efe66edfee@haskell.org> #9205: Deriving Typeable for poly-kinded data family gives confusing error message -------------------------------------+------------------------------------ Reporter: dfranke | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by dreixel): * status: new => closed * resolution: => fixed Comment: This is fixed in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 14:06:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 14:06:38 -0000 Subject: [GHC] #9211: Untouchable type variable (regression from 7.6) In-Reply-To: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> References: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> Message-ID: <061.7ac074a5321b95cf593d2c9c4b4485ed@haskell.org> #9211: Untouchable type variable (regression from 7.6) -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Upcoming partial type signatures and/or explicit type application will help, but these are both some distance away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 14:12:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 14:12:10 -0000 Subject: [GHC] #9205: Deriving Typeable for poly-kinded data family gives confusing error message In-Reply-To: <046.527ed5076d77c49d2494e387d691216d@haskell.org> References: <046.527ed5076d77c49d2494e387d691216d@haskell.org> Message-ID: <061.dc9944d3b87eb6cb037c9fb0bfbe3e12@haskell.org> #9205: Deriving Typeable for poly-kinded data family gives confusing error message -------------------------------------+------------------------------------ Reporter: dfranke | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Fixed, as in: it compiles with or without `PolyKinds`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 14:13:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 14:13:24 -0000 Subject: [GHC] #9205: Deriving Typeable for poly-kinded data family gives confusing error message In-Reply-To: <046.527ed5076d77c49d2494e387d691216d@haskell.org> References: <046.527ed5076d77c49d2494e387d691216d@haskell.org> Message-ID: <061.3f32a5b935f28d8778354a4b11e471c4@haskell.org> #9205: Deriving Typeable for poly-kinded data family gives confusing error message -------------------------------------+------------------------------------ Reporter: dfranke | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dreixel): Replying to [comment:2 simonpj]: > Fixed, as in: it compiles with or without `PolyKinds`. Which is what we want, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 14:23:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 14:23:24 -0000 Subject: [GHC] #9205: Deriving Typeable for poly-kinded data family gives confusing error message In-Reply-To: <046.527ed5076d77c49d2494e387d691216d@haskell.org> References: <046.527ed5076d77c49d2494e387d691216d@haskell.org> Message-ID: <061.940e8b8aa05a8b3e3060966df13c046b@haskell.org> #9205: Deriving Typeable for poly-kinded data family gives confusing error message -------------------------------------+------------------------------------ Reporter: dfranke | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Yes, that's what we want. I was just clarifying what "fixed" meant; you could have meant "rejected with a better error message". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 14:32:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 14:32:08 -0000 Subject: [GHC] #9205: Deriving Typeable for poly-kinded data family gives confusing error message In-Reply-To: <046.527ed5076d77c49d2494e387d691216d@haskell.org> References: <046.527ed5076d77c49d2494e387d691216d@haskell.org> Message-ID: <061.319e4cf96886d56f8a1fd7352872d4f4@haskell.org> #9205: Deriving Typeable for poly-kinded data family gives confusing error message -------------------------------------+------------------------------------ Reporter: dfranke | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dreixel): Right, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 15:55:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 15:55:46 -0000 Subject: [GHC] #9210: "overlapping instances" through FunctionalDependencies In-Reply-To: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> References: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> Message-ID: <062.ec2c385545beff747c61d02bede32471@haskell.org> #9210: "overlapping instances" through FunctionalDependencies --------------------------------------------+------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * cc: dimitris@?, diatchki (added) Comment: I can at least explain what is going on. I defer to Iavor (the Functional Dependency Expert) on what the right thing to do might be. == Problem 1: Should these instance declarations be accepted at all? == After all, unifying the a,b,s components of the instances shows that the constraint `Foo (x,x) ?? x y` would match both instances, and hence (via the fundep) force `??` to be both `(y,x)` and `(x,y)` respectively. GHC doesn't currently complain about this, I think because there are some yet-more-specific constraints that would not give rise to a conflict. For example, suppose I was trying to solve `(Foo (Int,Int) ?? Int Int)`. Then both fundeps would compatibly force `??` to be `(Int,Int)`. Mind you, then the overlap checker would say that it couldn't pick which of the two instances to use. So my instinct is that this check for "yet-more-specific" constraints is wrong. If the things on the LHS of the fundep arrow unify, then the things on the RHS should be equal. That would reject these two instance declarations. Iavor? For completeness, the offending bit of code is this, in `FunDeps.lhs` line 318 {{{ Just subst | isJust (tcUnifyTys bind_fn rtys1' rtys2') -- Don't include any equations that already hold. -- Reason: then we know if any actual improvement has happened, -- in which case we need to iterate the solver -- In making this check we must taking account of the fact that any -- qtvs that aren't already instantiated can be instantiated to anything -- at all }}} == Problem 2: why does type checking succeed? == The second mystery is this: why is the constraint `(Foo (Int,Int) alpha Int String)`, which is what arises from `main`, solved without error? `alpha` is a unification variable. What happens is this. * The constraint gives rise to two derived constraints, one from each fundep `[D] alpha ~ (Int,String)` and `[D] alpha ~ (String,Int)`. * The first is solved by `alpha := (Int,String)`. * Having made that choice, the constraint `Foo (Int,Int) (Int,String) Int String` uniquely matches the second instance declaration, and so can be solved. * The second derived constraint becomes `[D] (Int,String) ~ (String,Int)` and therefore leads to two isoluble derived constraints `[D] Int ~ String` and `[D] String ~ Int`. * But if we manage to solve everything else, we discard insoluble derived constraints; see `Note [Dropping derived constraints]` in `TcRnTypes`. As a result of all this, we (totally bogusly) pick one instance declaration, ignoring the fact that the other matches too. Ugh! I'm not quite sure what to do, but let's sort out (1) before thinking about (2). Iavor? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 16:16:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 16:16:06 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.fa3a26b9eaf3f746f6a47ac4140401d1@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by dolio): Having thought some more, I feel like there is potential weirdness with the changes I mentioned earlier, even if it works nicely for some simple examples. For instance, consider: {{{ u : a -> a -> a f : some a b. a -> a -> b f x y = u (g x y) (h x y) g : some c b. forall a. c -> a -> b g x y = f x y h : some c b. forall a. c -> a -> b h x y = f x y }}} Now, since `f` takes two arguments of the same type, this requires each of `g` and `h` to do the same. But, to ensure `g` and `h` are sufficiently polymorphic, we need to skolemize. These skolems then flow into the `c` unification variables, which in turn are unified due to `f`. So this will cause a skolem mismatch. So, I'm not sure it's a good idea for these sorts of examples to work, even if they could in some cases. It seems like it could easily be confusing when similar examples happen to work or not work depending on where skolems flow. So I guess I'm back to thinking that it's better for your G example to not check: {{{ u : a -> a -> T g : some c. forall k. c -> k -> T g x y = u x y }}} simply because it's due to a less confusing rule. Ermine has, of course, always generalized ''unification variables'' that are still free after this process; that is what is expected for types. I think it's handy for kinds as well (probably excepting the 'bad polymorophism' examples). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 16:48:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 16:48:08 -0000 Subject: [GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap In-Reply-To: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> References: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> Message-ID: <062.92c14ea43626e4efce2cb7068f1cb9e6@haskell.org> #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): Simon: I don't think you added a comment on Phabricator (you probably need to click the big button at the bottom of the page). I've been digging a bit more into this: it turns out we had fixed this once before, see #3245, and there was even a big Note in the code that was *removed* by Pedro in 3d53407f9c6e87bcff30d51f0a048e92b2745a32. There's also a perf test (`testsuite/tests/perf/should_run/T3245.hs`), but that didn't trigger because (a) there are no bounds defined for it in all.T, and (b) that test doesn't trigger the bug any more anyway. I'm going to add a new perf test, and some comments to `Internal.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 19:22:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 19:22:18 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.82afa1fae355f2022d98eb9d6a7de0cd@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by jstolarek): > Why not follow Ross's suggestions in comment 17? If I understand correctly Ross' proposal is actually independent of this ticket: we could implement it and still have broken RebindableSyntax. That's why I chose to fix the rebindable syntax first. Perhaps then we can think about alternative desugaring of arrow syntax. > The VOODOO CODING is of course wrong. Well, it is wrong, but I don't yet see why it is wrong. In my code I intended to check that `arr` has type `b -> c -> x b c` (where `x` is an arrow): {{{ arr_op' <- tcSyntaxOp DoOrigin arr_op (mkFunTy (mkFunTy b c) (mkCmdArrTy env b c)) }}} and that `>>>` has type `x a b -> x b c -> x a c`: {{{ compose_op' <- tcSyntaxOp DoOrigin compose_op (mkFunTys [mkCmdArrTy env a b, mkCmdArrTy env b c] (mkCmdArrTy env a c)) }}} I looked at the code you pointed me to and I don't yet see where I went wrong. Do you mean that I should not only check `arr` and `>>>` independently of everything else, but should also check that the type of the whole desugared expression - ie. `arr (\p -> ((xs),())) >>> c'` - is also correct? > Doing the instantiation once, at CmdTop will almost certainly not work. Not sure if I understand what instantiation you mean. You refer to `arr` and `compose`? They are instantiated separately for each data constructor that needs them. `HsCmdTop` was just an example. At the moment I implemented your proposal: every constructor stores operators required for its desugaring and the `CmdSyntaxTable` has been removed. Typechecking is the missing part. I'll be taking a stab at it sometime later this week. There are some examples of typechecking arrows in `TcArrows`, which will hopefully get me on the right track. Once this is done I expect to get tons of minor bugs resulting from my voodoo programming. Hopefully, these will be easy to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 20:14:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 20:14:15 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.17c12bad9a709b6da61a6d24f7722e03@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by dolio): Having conferred with Ed, I guess GHC uses a different strategy that doesn't involve (proper) skolem variables, so it might not be subject to my complaint. Using some kind of after-the-fact distinctness check instead of proper skolems seems not to arbitrarily rule out certain definitions in a confusing manner, which was my main concern. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 21:19:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 21:19:19 -0000 Subject: [GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap In-Reply-To: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> References: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> Message-ID: <062.32a004b877469175ed09559f3d610035@haskell.org> #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Ha ha! My attempt to use Phab fails at the first fence. I'm jolly glad I only wrote one short comment, not a whole lot!! Anyway you read my mind: I was suggesting a clear Note to explain the issue, but I see you are already on it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 21:59:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 21:59:41 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.9ae8699b80c81509f0a6791bd5d95529@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by ross): Replying to [comment:27 jstolarek]: > > Why not follow Ross's suggestions in comment 17? > > If I understand correctly Ross' proposal is actually independent of this ticket: we could implement it and still have broken RebindableSyntax. That's why I chose to fix the rebindable syntax first. Perhaps then we can think about alternative desugaring of arrow syntax. It's not so much an alternative desugaring as a different view of the existing desugaring in which `do` and `if` can be rebound in an analogous manner to the way they're rebound in the expression world. Or it's a re- interpretation of this ticket: instead of using private versions of `arr`, `>>>` and `first`, the idea is to use private versions of the control operators `bind`, `bind_` and `ifThenElseA`, the arrow counterparts of `>>=`, `>>` and `ifThenElse`. I don't see how the former can work, as each language construct is translated to several of those combinators. In addition, you have less control of the types of these things, because the translation re-arranges and trims the environment it passes through the arrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 22:27:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 22:27:12 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.7d5d0971d0e6d8b0ea31e1e7c053eb7d@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Richard, I have tried to address your questions on the wiki page. Better now? I still don't know what the difference between bad and good polymorphism is, but maybe it doesn't matter now, since you say that it is "tangential". You say "Because open type families do not have a body, they would still need their own kind inference story, where unconstrained meta-variables default to *." but I don't understand that. Add a subsection for it? (Open type families simply have their own, complete, kind signature, no? I'm happy with (PARGEN) if you are happy with the typing rule including the side condition. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 22:31:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 22:31:35 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.0a5b2c9b2177c01aed1a2653f08e76d3@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by simonpj): I wrote > We are typechecking `pat <- rhs; body` as if it was `(>>=) rhs (\x -> body)`. So we instantiate `(>>=)`, expecting its type to have the shape > {{{ > rhs_ty -> (pat_ty -> body_ty) > }}} > That's what `tcSyntaxOp` does. > > Then we check that `pat` really does have type `pat_ty` and `rhs` really does have type `rhs_ty`. The last sentence is terribly important! We are not just checking that `(>>=)` has a type of the right shape (which is, I gather from your question, what you think is going on), ''but also that it's type can be instantiated to match the particular pattern `pat` and the particular rhs `rhs`''. You aren't doing that with `(>>>)` which is why you have all those uninstantiated type variables. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 22:55:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 22:55:49 -0000 Subject: [GHC] #9197: FFI types should be usable in foreign import decls without revealing representations In-Reply-To: <045.1e66fe66ff436f9c3e1f990da91bd5b9@haskell.org> References: <045.1e66fe66ff436f9c3e1f990da91bd5b9@haskell.org> Message-ID: <060.b101b203ebfee6ac8fe49c1d18706866@haskell.org> #9197: FFI types should be usable in foreign import decls without revealing representations -------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I can't say I'm that keen on another FFI-related pragma. Does this have anything to do with the `CTYPE` pragma (which I have never really understood), [http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi.html#ffi-capi documented here]? Are others keen on this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 22:59:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 22:59:24 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.42d14c906bf20947f6b9445ad1567dc5@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Comment (by Iavor S. Diatchki ): In [changeset:"836981c7dec5c794ca94408468535cc018dc2e82/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="836981c7dec5c794ca94408468535cc018dc2e82" Redo instance to be more efficient (see #8778, #9203) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 22:59:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 22:59:24 -0000 Subject: [GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap In-Reply-To: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> References: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> Message-ID: <062.1907330be98c0e9a0c7791ed08585779@haskell.org> #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Iavor S. Diatchki ): In [changeset:"836981c7dec5c794ca94408468535cc018dc2e82/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="836981c7dec5c794ca94408468535cc018dc2e82" Redo instance to be more efficient (see #8778, #9203) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 22:59:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 22:59:47 -0000 Subject: [GHC] #9198: large performance regression in type checker speed in 7.8 In-Reply-To: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> References: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> Message-ID: <060.81732afc1cb4f75e729c4b1e5d945462@haskell.org> #9198: large performance regression in type checker speed in 7.8 -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): The types really do get twice as large each time you add an `a`, I think. Are you certain that 7.6 is really fast? It got slow for me, just as 7.8 does, and not surprisingly so. These "big type" examples are pretty rare in practice, but even basic old Hindley-Milner type inference is worst-case exponential in program size. That said, GHC makes it worse by dragging these large type right through the compiler pipeline; it's a price we pay for a properly typed intermediate language. See [http://research.microsoft.com/en- us/um/people/simonpj/papers/variant-f/index.htm Scrap your type applications] for a way to improve these bad cases -- at a cost in compiler code complexity. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 16 23:08:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jun 2014 23:08:57 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.594f926fc3e916a208c504f21213f01b@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Comment (by diatchki): Aha, thanks for the Phabricator tip! I redid the instances to be of the form `\_ -> blah`. About the `Typeable` instance: in normal modules we only allow machine- generated instances. The module `Data.Typeable.Internal` is an exception though---it allows manual instances to accommodate custom instances for some types. One note about the type-literal instances: they have a much higher chance of collision than a typical kind, as both `Nat` and `Symbol` have infinitely many type-constructors, which need to fit into the fingerprint. I am not sure how much of a realistic problem this is, but it is something to keep in mind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 00:04:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 00:04:18 -0000 Subject: [GHC] #5902: Cannot tell from an exception handler whether the exception was asynchronous In-Reply-To: <047.209fb2dee42076110a1739ebc55e4ab4@haskell.org> References: <047.209fb2dee42076110a1739ebc55e4ab4@haskell.org> Message-ID: <062.9a4765c579be67f4ad5e3b95734375dd@haskell.org> #5902: Cannot tell from an exception handler whether the exception was asynchronous -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by liyang): * cc: hackage.haskell.org@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 02:32:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 02:32:10 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.ee488b9b07b5b209207cadd7311142ee@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Changes (by aavogt): * cc: vogt.adam@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 06:46:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 06:46:41 -0000 Subject: [GHC] #8226: Remove the old style -- # Haddock comments. In-Reply-To: <047.96b6209768296ad11c174e077e349059@haskell.org> References: <047.96b6209768296ad11c174e077e349059@haskell.org> Message-ID: <062.3a5946edc409023c00c804adc1faa897@haskell.org> #8226: Remove the old style -- # Haddock comments. -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: adinapoli Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by adinapoli): Hi guys, I haven't forgot, is that I'm making basically no progress on it. After Fuuzetsu's suggestion of removing the old data structure which held the 0.x style comments, I stumbled upon a series of difficulties, which are, unordered, the result of different edits on the Lexer; * Removing the data structure caused immediately GHC to complain on old style comments which are actually leftovers, an example is inside libraries/ghc-prim/GHC/Classes.hs. I couldn't understand from the sole documentation what to do, but it seems to me that, as Fuuzetsu said, they can be removed because they are equivalent to a pragma (in the example -- #hide == {-# OPTIONS_HADDOCK hide #-}. Unfortunately the lexer chokes in trying to parse "-- #hide" once the data structure has been removed, even though, theoretically, should be possible to modify the Lexer to just treat them as a normal comment ; after all the only thing which prevents this to happen, I believe, is the "isNormalComment" function. Unfortunately I can't modify it as per my first patch (aka removing the "#") because this will cause GHC to interpret RULES as normal comments (I discovered this thanks to an insight from SPJ). Sorry for the noise, I thought it was worth documenting my efforts my myself in the future :) If someone has some insights, please shout :) Alfredo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 08:28:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 08:28:48 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.318d6b8b6b463ce02de970c44556e307@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Comment (by simonpj): Re your "note about type-literal instances": did you add a `Note` with the relevant code. it is 100x times more likely to come to someone's attention there than in this ticket! Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 08:50:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 08:50:30 -0000 Subject: [GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap In-Reply-To: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> References: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> Message-ID: <062.09cee589ef4c8e116c8bcd1762bb4804@haskell.org> #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): Simon - you didn't lose your comment, if you go back to Phabricator it will still be there ready to submit. Phabricator auto-saves comments (unlike Trac). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 09:25:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 09:25:21 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.188e9c2061710a85874bd53b6f941bcb@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by juhpetersen): I also can't reproduce with 32b4bf33989bdda4dffed1866f7a61a7da4ca275 on Fedora, with a snapshot I built last week: http://copr-be.cloud.fedoraproject.org/results/petersen/ghc-7.8/fedora- rawhide-x86_64/ghc-7.8.3-36.2.fc20/ Are you still seeing this, Michael? Is anyone running 32bit? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 13:40:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 13:40:03 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.61d6f3ce55f98317d9f91fa90449cb7e@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by jstolarek): Replying to [comment:28 ross]: > It's not so much an alternative desugaring as a different view of the existing desugaring in which `do` and `if` can be rebound in an analogous manner to the way they're rebound in the expression world. Or it's a re- interpretation of this ticket: instead of using private versions of `arr`, `>>>` and `first`, the idea is to use private versions of the control operators `bind`, `bind_` and `ifThenElseA`, the arrow counterparts of `>>=`, `>>` and `ifThenElse`. A few more questions to make sure that I understand: 1. If your solution was implemented then `bind`, `bind_` and `ifThenElseA` would be rebindable and `arr` & friends would not? 2. `bind`, `bind_` and `ifThenElseA` currently don't exist in the libraries. Implementing yor proposal would require adding their definitions to Control.Arrow. Desugared arrow notation would call these default definitions, unless `RebindableSyntax` is enabled, in which case we use the definitions of `bind` etc. that are currently in scope. Correct? 3. In comment:17 you wrote: {{{ do { p <- cmd; stmts } = cmd `bind` \ p -> do { stmts } }}} Is `\ p -> do { stmts }` a shorthand for "put `p` on the stack and desugar `do { stmts }`"? If not, then what does it mean (code as written does not typecheck because `bind` needs an arrow, not a lambda). 4. I assume that this desugaring still requires the stack to store bound parameters (`p` in this example)? Replying to [comment:28 ross]: > I don't see how the former can work, as each language construct is translated to several of those combinators. This seems technically simple to me: just store in a constructor as many copies of the required combinators as necessary for desugaring. Although simple it leads to a design I'm not happy with. For example `RecStmt` requires 11 (sic!) combinators to desugar: 5x `>>>`, 4x `arr`, `first` and `loop`. > you have less control of the types of these things, because the translation re-arranges and trims the environment it passes through the arrow. Yes, if I need to write down the exact types for typechecking this becomes a problem. Which brings me to another question related to Simon's answer: Replying to [comment:29 simonpj]: > The last sentence is terribly important! That's what I suspected. So in the typechecker we type check `pat <- rhs; stmt` as if it was `rhs >>= \pat -> stmt` and later in the desugarer we actually convert it to such form, right? So if I want to typecheck the arrow desugaring I need to typecheck *exactly* the form to which it will later be desugared, including all the explicit stacks, etc? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 14:36:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 14:36:00 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.5a6d572bf2915c91cc02c548677030e1@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by snoyberg): I just built GHC myself with the same commit (32b4bf33989bdda4dffed1866f7a61a7da4ca275) and experienced the same problem with compdata. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 14:38:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 14:38:59 -0000 Subject: [GHC] #9211: Untouchable type variable (regression from 7.6) In-Reply-To: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> References: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> Message-ID: <061.4aec6a0811a70fd8fe16f72ed6294f0f@haskell.org> #9211: Untouchable type variable (regression from 7.6) -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by oleg): My real examples are not that different from the one I posted. Here is one of the recent ones: {{{ unsafeLam :: (Applicative m, AppPermutable i, SSym repr, LamPure repr) => (forall j. (j ~ (->) (repr a))) => (i :. j) (repr a) -> (m :. (i :. j)) (repr b)) -> (m :. i) (repr (a->b)) }}} As you can see, I use the type equality constraint to give an abbreviation to a complex type that appears several times in a complex expression. In the above example, 'j' is used as an abbreviation for '(->) (repr a)' that occurs twice in a large type. OCaml has the convenient notation 'type as x -> x -> x' to give an abbreviation to a type. I was happy that I found something similar in Haskell. Alas, as this ticket shows, sometimes it doesn't work. I have fixed my problem by getting rid of the abbreviation. (Giving the local type annotation in the real case proved to be too messy. The compiler kept complaining and needing more and more annotations.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 14:55:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 14:55:10 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.4f52d52d607461a54b9d3a58821e0936@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): Happily, I think everyone here has converged on (PARGEN) with the critical side condition that we do not unify a meta-variable with a kind containing a skolem. I realized yesterday that the side condition was necessary but didn't have the chance to write it up. In any case, I think we can end the design phase here and move onto the implementation phase. Most of (PARGEN) should be easy, as (PARGEN) is exactly what is implemented by `NonParametricKinds`, except for the side condition. To implement the side condition, I propose a new disjunct for `MetaInfo` named `NonSkolemTv` which is like `TauTv` but cannot unify with a type containing a skolem. The unifier, in !TcUnify, would just check this condition at the appropriate point. Sound reasonable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 14:55:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 14:55:37 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.d54192fb1b4073ba6a4ad5c9ccdf3178@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): And, yes, open type families keep their complete kind signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 16:43:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 16:43:08 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.25297cf65ae9d6a219f9881a50512e55@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): Replying to [comment:8 snoyberg]: > I just built GHC myself with the same commit (32b4bf33989bdda4dffed1866f7a61a7da4ca275) and experienced the same problem with compdata. What steps exactly are you taking to encounter this error? Can you paste your relevant Cabal configuration? Are you using `-j` for either cabal- install or ghc? Also, I wonder if we could be seeing different behavior from the system linker. What distribution/version are you running? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 16:58:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 16:58:20 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.bdd071feb8f5e582094f3229510bbbd4@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by snoyberg): I've reproduced the same error whether I use `cabal install` or `cabal install -j`. I did the building in a fresh hsenv with a standard cabal config file: [http://lpaste.net/105744]. I got the same issues from: 1. The build I just made. 2. Herbert's Ubuntu PPA. 3. A binary that Austin sent me. I'm running Ubuntu 12.04, 64-bit. I got the same results on my Stackage server as well: [http://jenkins.stackage.org/job/Stackage/36/ghcversion=7.8.3/console]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 17:24:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 17:24:29 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.e542ddb3d5c97388d4d8189279a6f846@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by ross): Replying to [comment:30 jstolarek]: > A few more questions to make sure that I understand: > > 1. If your solution was implemented then `bind`, `bind_` and `ifThenElseA` would be rebindable and `arr` & friends would not? Yes. > 2. `bind`, `bind_` and `ifThenElseA` currently don't exist in the libraries. Implementing yor proposal would require adding their definitions to Control.Arrow. Desugared arrow notation would call these default definitions, unless `RebindableSyntax` is enabled, in which case we use the definitions of `bind` etc. that are currently in scope. Correct? It would probably be helpful to add them, but it wouldn't be necessary, just as the libraries don't currently have a definition of `ifThenElse`. The point is that the existing translation is equivalent to translating via these operators, so with `RebindableSyntax` turned on one could translate to those names instead. Then again, always translating via those names would mean less desugaring code, which Simon would approve of. (I've edited comment:17 to add the translation of `rec`, which I forgot before.) > 3. In comment:17 you wrote: > > {{{ > do { p <- cmd; stmts } = cmd `bind` \ p -> do { stmts } > }}} > Is `\ p -> do { stmts }` a shorthand for "put `p` on the stack and desugar `do { stmts }`"? If not, then what does it mean (code as written does not typecheck because `bind` needs an arrow, not a lambda). Remember that we're still in the command world here, so the infix operator `bind` is applied to two commands. A command can have the form `\ p -> cmd`, and that's what we have here. The meaning follows from the above implementation of `bind` and the existing translation rules for commands. The `bind`operator will leave the output of the first command on the stack, and the second command will take it off and match it against `p` to extend its local environment. > 4. I assume that this desugaring still requires the stack to store bound parameters (`p` in this example)? The rules for commands other than `do` and `if` would be as before. The lambda would take the argument off the stack, match it against `p`, and add to the local environment an entry for each variable in `p`. > Replying to [comment:28 ross]: > > I don't see how the former can work, as each language construct is translated to several of those combinators. > > This seems technically simple to me: just store in a constructor as many copies of the required combinators as necessary for desugaring. Although simple it leads to a design I'm not happy with. For example `RecStmt` requires 11 (sic!) combinators to desugar: 5x `>>>`, 4x `arr`, `first` and `loop`. > > > you have less control of the types of these things, because the translation re-arranges and trims the environment it passes through the arrow. > > Yes, if I need to write down the exact types for typechecking this becomes a problem. Which brings me to another question related to Simon's answer: > > Replying to [comment:29 simonpj]: > > The last sentence is terribly important! > > That's what I suspected. So in the typechecker we type check `pat <- rhs; stmt` as if it was `rhs >>= \pat -> stmt` and later in the desugarer we actually convert it to such form, right? So if I want to typecheck the arrow desugaring I need to typecheck *exactly* the form to which it will later be desugared, including all the explicit stacks, etc? Yes you do, and that will be harder in the arrow case, because the local environment is an explicit input to the resulting arrow, and the desugarer feels free to trim unused variables from that environment, which will change its type. It would probably be necessary to force the replacements for the arrow combinators to be polymorphic in the environment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 17:38:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 17:38:58 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.90d1ad24eaba901fb8844a0668f8eaaf@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Comment (by diatchki): It occurred to me that we could work around the collision problem as follows: in the current representation I am representing each type-level number as its own type-constructor, leading to the collision problem as we need more type constructors than the 128-bit that we have. An alternative would be to think of the numbers as non-empty lists of digits in some large base (e.g. 8192). In other words, we could generate the representation as if the numbers were defined like this: {{{ data Nat = Nil0 | Nil1 | Nil2 | ... | Nil8191 | Cons1 Nat | Cons2 Nat | ... | Cons8191 Nat }}} Pros: - Potentially avoids the chance of collisions as now we need to represent only ~16000 constructors, rather than infinitely many. - Reasonably sized numbers are represented just as efficiently, and very large numbers are only slightly less efficient. Cons: - A bit slower to compute representation? - Functions like `splitTyConApp` would allow users to observe this encoding, although I am not sure that this matters? In the "Pros" list I say "potentially" because even though the `TypeRep` is a tree of type applications, when we compare for equality we are just comparing the fingerprint, so I am not sure that we've actually gained anything by all this... Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 18:24:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 18:24:13 -0000 Subject: [GHC] #9212: Cleanup of sync-all Message-ID: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> #9212: Cleanup of sync-all ------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Some dead code removal and small bug fixes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 18:28:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 18:28:39 -0000 Subject: [GHC] #9212: Cleanup of sync-all In-Reply-To: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> References: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> Message-ID: <060.e92901a61e5253fe971f5a5be798b3fb@haskell.org> #9212: Cleanup of sync-all -------------------------------------+------------------------------------ Reporter: thomie | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 19:15:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 19:15:29 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.b126aa2f9d4a394bfae5497f0b7bfeb1@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by carter): Question: would it be possible as part of this refactoring to have a sort of generalized (weaker) arrow that doesn't have arr? having arr be baked into the Arrow machinery makes using Arrow for deep embeddings not tenable (such as circuit/frp models that you may wanna compile at runtime). bind has a similar issue, because it allows injecting any haskell function f :: a -> b It may be out of scope for this effort, but figure I should ask -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 19:52:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 19:52:33 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.7a95ed3b505e2d206a39a796e7a9992d@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): OK, I repeated my steps (as far as I can tell) on an Ubuntu 12.04 VM and now I do get the error. Curious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 19:54:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 19:54:02 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.e54a52c48cccfe3d65b57679cadfbfb2@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): Yes, this bug is particularly weird because on e.g. my Debian machine where I cook the release images, this does not happen. But it does on Ubuntu 12.04. I have a potential fix incoming with a binary build people should test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 19:55:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 19:55:53 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.c95bdc5a4ce6a4d4f7c916e9f0d2af04@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): OK, this is quite annoying, it consistently fails when I do `cabal install -v`, but consistently succeeds when I do `cabal install -v3`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 21:07:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 21:07:47 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.535efed42a272d962137700ad93cf1d9@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ocharles): Ok folks, I've squashed this down to just two commits now - one with instances and one with whitespace changes. I think we may be all ready to go, and we can derive typeable in a separate commit. It does mean that without that the Data instances are fairly useless. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 21:10:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 21:10:33 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.2f0a2c719bf8089306f7e67cc307bdbb@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Comment (by diatchki): I looked some more at the code, and realized that this more complex encoding is not worth the effort: we are always hashing the entire type- representation, so it does not matter how the types are encoded. Also, it looks like we are using a reasonable hashing function (MD5), and collisions for it are very unlikely so we should be OK. So, I guess we can close this ticket, unless there are any more issues? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 21:28:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 21:28:10 -0000 Subject: [GHC] #8226: Remove the old style -- # Haddock comments. In-Reply-To: <047.96b6209768296ad11c174e077e349059@haskell.org> References: <047.96b6209768296ad11c174e077e349059@haskell.org> Message-ID: <062.c1a9443932d8bc59e5ca3d62eaa34662@haskell.org> #8226: Remove the old style -- # Haddock comments. -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: adinapoli Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Fuuzetsu): Hm, I'm unsure why this is proving difficult to implement. Looking at the lexer, it seems that it should be enough to: * Remove {{{#}}} from any sections lexing Haddock comment so sections like {{{[$docSym \#]}}} become just {{{[$docSym]}}} or whatever the appropriate syntax is there. * in {{{}}} remove the lexing of {{{-- #}}} all together. * Remove {{{ITdocOptionsOld}}}. * inside {{{isNormalComment}}}, I'm unsure exactly how to proceed. You say removing {{{#}}} from {{{notFollowedByDocOrPragma}}} stops {{{RULES}}} from working. In that case I say keep it there as it is now, in the end it does not matter because we'll stop treating it as a Haddock thing anyway. It will now simply check whether a {{{#}}} comment is special for {{{RULES}}} instead of for both {{{RULES}}} and Haddock. This is an assumption however so this might be where I'm going wrong. * {{{withLexedDocType}}} remove the case for {{{'#'}}}: if we removed the case for {{{-- #}}} in {{{}}} then we should never enter {{{withLexedDocType}}} through {{{multiline_doc_comment}}} at least as far as I can see. * Remove the case in for {{{ITdocOptionsOld}}} in {{{getOptions'}}} in {{{HeaderInfo.hs}}}. I think this should be enough to allow us to not treat either {{{{- #}}} nor {{{-- #}}} as a Haddock thing while preserving the behaviour of everything else as it is now. Am I missing something? PS: It'd be great if you could create a wiki page (either on GHC wiki or NixOS wiki) on your workflow on GHC hacking with nix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 21:46:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 21:46:46 -0000 Subject: [GHC] #8226: Remove the old style -- # Haddock comments. In-Reply-To: <047.96b6209768296ad11c174e077e349059@haskell.org> References: <047.96b6209768296ad11c174e077e349059@haskell.org> Message-ID: <062.d257a79138dcc04e87ebc131e69914d4@haskell.org> #8226: Remove the old style -- # Haddock comments. -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Fuuzetsu): * owner: adinapoli => * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 21:46:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 21:46:56 -0000 Subject: [GHC] #8226: Remove the old style -- # Haddock comments. In-Reply-To: <047.96b6209768296ad11c174e077e349059@haskell.org> References: <047.96b6209768296ad11c174e077e349059@haskell.org> Message-ID: <062.c0ecc0d7e752e38dd4dbcfbf83df76f5@haskell.org> #8226: Remove the old style -- # Haddock comments. -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: adinapoli Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Fuuzetsu): * owner: => adinapoli -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 22:10:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 22:10:48 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.ce575c0eabd82d8877c2e4e630fdd891@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8935 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * related: => #8935 Comment: 2f8b4c9330b455d4cb31c186c747a7db12a69251 is definitely the culprit. It is now reverted on the 7.8 branch - if you update your GHC 7.8 and rebuild, this should go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 22:12:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 22:12:33 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.4b6edebdd256d430e8d16dd66a0de0fe@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: #9186 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * owner: simonmar => * status: closed => new * resolution: fixed => * related: => #9186 * milestone: 7.8.3 => 7.8.4 Comment: Re-opening, the patch to fix this (2f8b4c9330b455d4cb31c186c747a7db12a69251) caused the failure in #9186, which has been reverted on the GHC 7.8 branch. I'll be reverting it on HEAD as well soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 22:12:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 22:12:46 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.1c8513eb1bf3cb65209296946c498d33@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: #9186 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 23:37:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 23:37:31 -0000 Subject: [GHC] #9213: CPP warnings on ghcautoconf.h Message-ID: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> #9213: CPP warnings on ghcautoconf.h ------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The cpphs program yields the following warning: {{{ Warning: trailing characters after #if directive in file ... /ghcautoconf.h at line 383 col 1: AC_APPLE_UNIVERSAL_BUILD }}} I guess it is necessary to replace `#if defined` by `#ifdef` in the line {{{ #if defined AC_APPLE_UNIVERSAL_BUILD }}} from the mk/config.h.in file. Note the next line `# if defined __BIG_ENDIAN__` has the same issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 17 23:39:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jun 2014 23:39:44 -0000 Subject: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? In-Reply-To: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> References: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> Message-ID: <060.feacde1f8ee2235148580875a75246c9@haskell.org> #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ihameed): * cc: idhameed@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 03:53:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 03:53:10 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.2658b32d8ff0bfa8e718a18b2290a56e@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8935 -------------------------------------+------------------------------------ Comment (by snoyberg): I can confirm that reverting that commit solves the problem on my system. I'll proceed with trying a new Stackage build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 06:16:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 06:16:23 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.efa48195f9aedc6c23690a8962a4e1bd@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by jstolarek): > A command can have the form \ p -> cmd, and that's what we have here Ah, so you used `\` to denote the command abstraction (`proc`), not a lambda abstraction? That got me confused. > > So if I want to typecheck the arrow desugaring I need to typecheck *exactly* the form to which it will later be desugared, including all the explicit stacks, etc? > > Yes you do, and that will be harder in the arrow case, because the local environment is an explicit input to the resulting arrow, and the desugarer feels free to trim unused variables from that environment, which will change its type. And that means that at the typechecking stage I have to exactly follow the whole desugaring algorithm, right? Sounds non-trivial. > It would probably be necessary to force the replacements for the arrow combinators to be polymorphic in the environment. This brings me to another question. So let's say the user rebinds `arr` to some function with the type `(Arrow a, Foo b) => a b b`. Then, after desugaring, `arr` is made to operate on data + environment, like in your definition of `bind`: `arr (\ ((e,s),b) -> (e,(b,s)))`. So the type that `arr` operates on may no longer be an instance of `Foo`. What happens? I don't see a way out. > Question: would it be possible as part of this refactoring to have a sort of generalized (weaker) arrow that doesn't have arr? From the discussion on ghc-devs it looks that this is out of scope of this ticket - it probably deserves its own. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 08:04:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 08:04:49 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.d2c968a608d22b199b92935f8db3abce@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): I'm not quite ready to declare victory. Some technical questions: * See `T1a` and `T4` under (PARGEN). These are unexpected failures. The tricky side condition means that you must declare ''all'' the polymorphism involving `k`, or ''none'', but nothing in between. * What is the rule for non-recursive bindings? Specifically: {{{ data NR f (a::k) = MkNR (f a) }}} Is this accepted (as now), or rejected by the "tricky side condition". If the former that gives an uncomfortable difference between recursive and non-recursive bindings. * I'd like to see a rule written down for closed type families, and a sketch of the accompanying algorithm. And finally, at a non-technical level, I'm not convinced that (PARTIAL) is untenable. * Yes, people using kind polymorphism might need to add some kind signatures, but that would arguably improve their code. * We could issue a warning for one release cycle. * The tricky side condition becomes simple: all kind polymorphism must be declared. * And sometimes kind polymorphism might even trip you up: {{{ foo :: forall f a. f a -> f a foo = ... where g :: f Int -> Int }}} This will, I think, fail. Because `foo`'s signature actually means {{{ foo :: forall k. forall (f:k->*) (a:k). f a -> f a }}} so the `(f Int)` application is ill-kinded. Edward is an example of a high-end kind-polymorphism user. How bad would (PARTIAL) be? Implementation. Re `NonSkolemTv`, I'd hate to pollute `MetaInfo` for such a corner case. We can simply test the side condition at the end, just as the rule suggests. Generating a helpful error message is quite a challenge! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 08:10:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 08:10:41 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.6eb1b9316177b4531e1426fac60a68af@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Comment (by simonpj): I agree. But still worth a `Note`! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 08:21:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 08:21:09 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.d00234cc43aa5e53c7664cde43f9943b@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by simonpj): I'm not following all of this, but my instinct is this. The semantics of the program should not depend on the details of desugaring. So the various calls to `arr`, `(>>>)` in the desugarer should not dispatch to different instances depending on the size of the tuple. So the type checker should be able to construct functions `arr-at-T`, `(>>>)-at-T` (for the ambient arrow T) ''that are polymorphic in the environment argument''. The desugarer can then instantiate this polymorphic function at whatever types it needs (maybe several of them). I am having trouble getting to grips with this because I know of no document that gives: * The syntax of the arrow sub-language (including comprehensions) * The typing rules for that language * The desugaring for that language Having such a document would be extremely helpful in making sure we were all on staring from the same baseline. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 08:31:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 08:31:08 -0000 Subject: [GHC] #9211: Untouchable type variable (regression from 7.6) In-Reply-To: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> References: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> Message-ID: <061.3e197fa385b5e0c691a167d5cb95dc1c@haskell.org> #9211: Untouchable type variable (regression from 7.6) -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * cc: dimitris@? (added) Comment: Harumph. Suppose we have an implication constraint of this form: {{{ forall a b c. (b ~ ty, ...) => ...blah... }}} where the equality constraint in the "givens" is of form `b ~ ty`, where `b` is one of the variables quantified by the `forall`. Then, as far as I can see, no loss of principality arises if we float constraints from `...blah...`, outside the implication. (Obviously, only ones that do not mention `a,b,c`.) (NB: floating the constraint out is equivalent to allowing a unification of an untouchable underneath.) Reason: such an equality amounts to a let-binding; indeed that is exactly how Oleg wants to use it. This would amount to an ad-hoc but easily-specified extension of GHC's already-ad-hoc rule for floating constraints out of implications, and hence perhaps no big deal. Certainly it's easy to implement. I'm adding Dimitrios in cc. What do you think? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 08:41:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 08:41:03 -0000 Subject: [GHC] #9190: Iface type variable out of scope: s In-Reply-To: <046.ae688232714aa8206efce4424bf2e376@haskell.org> References: <046.ae688232714aa8206efce4424bf2e376@haskell.org> Message-ID: <061.cf348a370edd341b3610df24247ca30f@haskell.org> #9190: Iface type variable out of scope: s -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: It's quite awkward to reproduce this problem in a small test cases (the smaller cases from comment 8 onwards were actually red herrings), and the bug was an egregious one now fixed, so I'm just going to close this without a regression test. Thank you for reporting it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 09:03:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 09:03:15 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.563967ed5a968cf551dfd2026993e43c@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by ross): Replying to [comment:33 jstolarek]: > > A command can have the form \ p -> cmd, and that's what we have here > > Ah, so you used `\` to denote the command abstraction (`proc`), not a lambda abstraction? That got me confused. Not quite. There are three different grammar items here: {{{ exp ::= \ pat -> exp exp ::= proc pat -> cmd cmd ::= \ pat -> cmd }}} In the last one you're already in the command world, and you want to take a value off the stack and give names to its components for use in the subcommand. > > > So if I want to typecheck the arrow desugaring I need to typecheck *exactly* the form to which it will later be desugared, including all the explicit stacks, etc? > > > > Yes you do, and that will be harder in the arrow case, because the local environment is an explicit input to the resulting arrow, and the desugarer feels free to trim unused variables from that environment, which will change its type. > > And that means that at the typechecking stage I have to exactly follow the whole desugaring algorithm, right? Sounds non-trivial. If you want to rebind at the level of `arr`, etc, partly (as Simon says) and yes it is. Replying to [comment:34 simonpj]: > I'm not following all of this, but my instinct is this. The semantics of the program should not depend on the details of desugaring. So the various calls to `arr`, `(>>>)` in the desugarer should not dispatch to different instances depending on the size of the tuple. So the type checker should be able to construct functions `arr-at-T`, `(>>>)-at-T` (for the ambient arrow T) ''that are polymorphic in the environment argument''. Yes indeed. And because of the multiple occurrences of `arr` and `>>>` in the translations, this will severely constrain the types of any replacements, to the point that I wonder if the rebinding will solve the original users' issues. > I am having trouble getting to grips with this because I know of no document that gives: > * The syntax of the arrow sub-language (including comprehensions) > * The typing rules for that language > * The desugaring for that language > > Having such a document would be extremely helpful in making sure we were all on staring from the same baseline. Well there is http://www.haskell.org/ghc/docs/papers/arrow-rules.pdf, but it needs updating to the new stack representation. I'll do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 10:33:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 10:33:36 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.8f4874a67199b37457083db76634c824@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by simonpj): I didn't know about arrow-rules.pdf! Excellent. Could it have a figure with BNF syntax? (Mirroring the data types in GHC.) Thank you -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 10:52:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 10:52:18 -0000 Subject: [GHC] #9214: UNPACK support for sum types Message-ID: <047.5213ff1d75a2abd5ff04d6c7bb79813f@haskell.org> #9214: UNPACK support for sum types ------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently the pragma only supports single-constructor types. So in the following example it will simply be ignored: {{{ data A = A1 Char | A2 {-# UNPACK #-} !B data B = B1 Int | B2 Bool }}} However the problem seems to be easily solvable by denormalizing the type {{{A}}} to something like the following during unpacking: {{{ data A = A1 Char | A2_1 Int | -- from B1 A2_2 Bool -- from B2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 11:28:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 11:28:18 -0000 Subject: [GHC] #9209: Template haskell panic In-Reply-To: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> References: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> Message-ID: <060.a96b673042599d74a7d08d54e1cf08d9@haskell.org> #9209: Template haskell panic -------------------------------------+------------------------------------ Reporter: tulcod | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): The problem here is that declaration splices are not yet allowed in `let`/`where`, but we aren't even giving a decent error message if one does show up there. Until the split between typed and untyped splices we ''couldn't'' have declaration splices except at top level, but now we definitely can. It just needs implementing. (Not hard; all the heavey lifting is done already.) Any volunteers? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 11:30:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 11:30:22 -0000 Subject: [GHC] #9161: Pattern synonyms interact badly with data kinds In-Reply-To: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> References: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> Message-ID: <066.b9a7586df59c489783bb5a9de8277607@haskell.org> #9161: Pattern synonyms interact badly with data kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: renamer, pattern Resolution: | synonyms, data kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile-time | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by cactus): * failure: None/Unknown => Compile-time crash * component: Compiler => Compiler (Type checker) * os: Linux => Unknown/Multiple Comment: This one is tricky... One would expect in this scenario roughly the same code path as if you write {{{ {-# LANGUAGE DataKinds #-} data TYPE = CON wrongLift :: CON wrongLift = undefined }}} which BTW results in a reasonable error message: {{{ Expected a type, but ?CON? has kind ?TYPE? In the type signature for ?wrongLift?: wrongLift :: CON }}} However, since pattern synonyms are internally handled as binds, not `TyClDecl`s, they are not yet in scope during kind checking (which is done by `tcTyClsInstDecls`) - hence the crash. How do we even get to trying to kindcheck them? `OccName.demoteOccName` handles data constructor names and type constructor names the same way, since we don't differentiate between the two there. So I think our best bet would be to have a bespoke internal kind for pattern synonyms, inject pattern synonyms at that kind before doing kind checking, and then barf on types of that kind with a meaningful error message. Simon, does that sound like a good plan of action? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 11:30:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 11:30:25 -0000 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@haskell.org> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@haskell.org> Message-ID: <059.62d629798c7d5641df50623278958138@haskell.org> #1475: Adding imports and exports with Template Haskell -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): '''Warning''': allowing splicing of imports would make it much harder to track dependencies between modules, so things like `ghc --make` would become harder. I've only just realised this. So tread carefully here! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 11:43:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 11:43:27 -0000 Subject: [GHC] #9206: OverloadedStrings breaks show? In-Reply-To: <054.f2651fc0f70b38fc1158c5aef9677e6d@haskell.org> References: <054.f2651fc0f70b38fc1158c5aef9677e6d@haskell.org> Message-ID: <069.12d2a37c3c56944f801c299b09b43285@haskell.org> #9206: OverloadedStrings breaks show? -------------------------------------+------------------------------------ Reporter: j80JjBjVNRMajmA | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): This behaviour is mostly documented in the [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#overloaded-strings overloaded strings section of the user manual], although there is an important omission: with `-XOverloadedStrings`, the default types (if none are specified by the user) are `Integer, Double, String`, not just `Integer, Double`. Reminder: `fromString :: IsString a => String -> a`, exported by `GHC.Exts`. So * Without `-XOverloadedStrings`, `test.hs` is rightly rejected. * With `-XOverloadedStrings`, defaulting kicks into play and chooses the first type from `Integer, Double, String` that satisfies `(Show a0, IsString a0)`. The only satisfying type is `String` so that is chosen. * In `test2.hs`, `Double` is made an instance of `IsString`, so that is picked first, before `String`. So it all looks right except that the user manual is deficient. I'll fix that. Of course, you could argue that the specification is wrong. If you want to do that, we should go back to the original discussion threads on overloaded strings. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 12:08:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 12:08:45 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.f0f234796e3bb45629301f8d4838c471@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by jstolarek): Replying to [comment:34 simonpj]: > So the type checker should be able to construct functions `arr-at-T`, `(>>>)-at-T` (for the ambient arrow T) ''that are polymorphic in the environment argument''. My concern was what if the `arr` defined by the user cannot be made polymorphic in the environment argument? According to my understanding of this bug report the problem is that during desugaring all calls to user-defined `arr` are instantiated to be the same and thus typechecking fails, because different types are required at different call sites. Why the same thing doesn't happen without rebinding? Replying to [comment:35 ross]: > Not quite. There are three different grammar items here: > {{{ > exp ::= \ pat -> exp > exp ::= proc pat -> cmd > cmd ::= \ pat -> cmd > }}} > In the last one you're already in the command world, and you want to take a value off the stack and give names to its components for use in the subcommand. Now I see this was even mentioned in "A New Notation for Arrows" paper. Again there's something I don't understand here. So far I though that stack is an implicit mechanism that is used to pass around values bound using `<-`. But here it seems that the user is allowed to explicitly access the stack. Isn't that a bit risky? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 12:32:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 12:32:34 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.8cefed1815773fb3ac119ee61660c704@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by ross): Replying to [comment:37 jstolarek]: > Now I see this was even mentioned in "A New Notation for Arrows" paper. Again there's something I don't understand here. So far I though that stack is an implicit mechanism that is used to pass around values bound using `<-`. But here it seems that the user is allowed to explicitly access the stack. Isn't that a bit risky? The local environment is used to pass around values bound inside the `proc` expression. The stack is used to pass around anonymous values. They can be pushed using application, popped and named in the environment by command lambda, and also manipulated by control operators. The type constraints on operators keep them well behaved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 13:54:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 13:54:26 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.b96a9265ea1a9ab071b30addeb3f7bb3@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): * I agree that (PARGEN) is a breaking change. But, I'll quote Simon's comment from the wiki page, which I fully agree with: > So moving from (BASELINE) to (PARGEN) would be a breaking change, but only in rather obscure circumstances. I am intensely relaxed about that particular backward-compatibility problem! * Non-recursive bindings should behave the same as recursive ones. This means that `NR` would be rejected due to the side condition. == Closed type families == (PARGEN) (including the side condition) should work out just fine. Here would be the declarative typing rule: {{{ k2 = forall fkv(k1). k1[k'1 .. k'n/_] fkv(k1) \not\in k'j forall i: G, F:k2 |- (F ps_i = t_i) ok k3 = gen(G, k2) --------------------------------------------------- G |- type family F :: k1 where { F ps_i = t_i } : k3 }}} This is very similar to the declarative typing rule for `letrec` given on the [GhcKinds/KindInference wiki page]. Here, I am ignoring issues with arity/saturation and using a syntax where the kind signature of a type family is given as `k1` with blanks, instead of the tyvarbndr syntax used in source code. This is in fact an improvement over the current state of affairs, which is essentially this rule ''without'' the side condition. Because of the omitted side condition, we don't have principal types! For example, {{{ type family X (a :: k) where X True = False }}} `X` could be `X :: k -> k` or `X :: k -> Bool`. Neither is more general than the other. GHC chooses `X :: k -> Bool`, but it's not principled. This is what I get for implementing kind inference for closed type families without writing out declarative rules! In any case, the solution to this problem (closed type families) seems to be the same as the solution for datatypes and classes, quite happily: add the side condition. == Using (PARTIAL) == I'm still quite strongly against (PARTIAL). Let's ignore the backward compatibility problem, for now. With (PARTIAL), we have a very different story about kind polymorphism than we do about type polymorphism. GHC tries to be as polymorphic as possible with types: writing `foo x = x` gives `foo :: forall a. a -> a`, ''not'' `foo : () -> ()`. It seems very odd to me to not do the same in kinds. Yet, (PARTIAL) would say that `data Foo x = MkFoo (Foo x)` would get `Foo :: * -> *` instead of `Foo :: forall k. k -> k`. Especially as we're inching toward dependent types, this seems like a step backward. And, though I defer to Edward's experience, I tend to think the backward compatibility problem would be annoying for what may seem like a dubious benefit (polymorphic recursion in the presence of partial kind signatures). == Conclusion == I ''am'' worried that (PARGEN) has a strange surface area, and I think that any error messages that the side condition produces should include a URL for further reading. (I actually think that links to further reading would helpful in several error messages!) But, if this surface area is deemed too bumpy, I personally would prefer to go back to (BASELINE) than to go to (PARTIAL). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 14:06:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 14:06:19 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.7c9491aa43a86f5d876e2da628b984c7@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dreixel): Sounds good to me. Please leave the ticket open; it might still take me a few weeks to implementing the changes in GHC, but I think that's not a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 14:37:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 14:37:08 -0000 Subject: [GHC] #8881: No way to unsubscribe a bug In-Reply-To: <046.3e20bef03cc312ed086d6bf0a5bf092e@haskell.org> References: <046.3e20bef03cc312ed086d6bf0a5bf092e@haskell.org> Message-ID: <061.8d08448dbffe7632e39b6c0b699d2cc8@haskell.org> #8881: No way to unsubscribe a bug -------------------------------------+------------------------------------ Reporter: nomeata | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 9138 -------------------------------------+------------------------------------ Changes (by thomie): * related: => 9138 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 14:39:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 14:39:59 -0000 Subject: [GHC] #9209: Template haskell panic In-Reply-To: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> References: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> Message-ID: <060.3a28cea25f99fe9f2df137b002eac1f3@haskell.org> #9209: Template haskell panic -------------------------------------+------------------------------------ Reporter: tulcod | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by archblob): * owner: => archblob Comment: I'll do it, I'll take a look at the code and write back if I have any questions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 14:40:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 14:40:18 -0000 Subject: [GHC] #7673: Windows: run "git config --global core.autocrlf false" before cloning the repo In-Reply-To: <047.12821fb51193c8ec9bb34376058ac256@haskell.org> References: <047.12821fb51193c8ec9bb34376058ac256@haskell.org> Message-ID: <062.9daf9800567c3e06cb6a2b78c125b13e@haskell.org> #7673: Windows: run "git config --global core.autocrlf false" before cloning the repo -------------------------------+------------------------------------ Reporter: morabbin | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------ Changes (by thomie): * cc: hvr (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 14:42:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 14:42:08 -0000 Subject: [GHC] #9138: Allow users to edit their own tickets In-Reply-To: <046.b3e5925750fb7dd4ccafa83e8bdf4ab9@haskell.org> References: <046.b3e5925750fb7dd4ccafa83e8bdf4ab9@haskell.org> Message-ID: <061.d5d5d250305de76d84ff58174b65126a@haskell.org> #9138: Allow users to edit their own tickets -------------------------------------+------------------------------------ Reporter: nomeata | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Modifying a ticket works, including changing CC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 14:43:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 14:43:06 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.ab797c609d8b6cc9c2a6d323b325332f@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Comment (by dmcclean): Thanks, Iavor! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 16:57:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 16:57:53 -0000 Subject: [GHC] #9206: OverloadedStrings breaks show? In-Reply-To: <054.f2651fc0f70b38fc1158c5aef9677e6d@haskell.org> References: <054.f2651fc0f70b38fc1158c5aef9677e6d@haskell.org> Message-ID: <069.03c7a35b2c327e1e41d65a0daf5864ee@haskell.org> #9206: OverloadedStrings breaks show? -------------------------------------+------------------------------------ Reporter: j80JjBjVNRMajmA | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by j80JjBjVNRMajmA): * status: new => closed * resolution: => invalid Comment: Now everything makes sense. I never heard about the `defaulting` stuff (seems to be an easily overlooked detail?), and thus am in no position to argue about its interplay with OverloadedString ... (for now). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 17:05:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 17:05:49 -0000 Subject: [GHC] #9215: GHC 7.8.2 mingw-w64: symbol not found in link Message-ID: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> #9215: GHC 7.8.2 mingw-w64: symbol not found in link ------------------------------------+------------------------------------- Reporter: stuartallenmills | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This includes calls such as strdup, stat, , and snprintf. These calls are not available in the 64 bit libraries (though 64 bit versions are such as _strdup, _snprintf) These problems have occurred in building yaml and unix-compat. They also occurred in system-fileio but jmilikin generated a patch for that library -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 17:27:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 17:27:50 -0000 Subject: [GHC] #9215: GHC 7.8.2 mingw-w64: symbol not found in link In-Reply-To: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> References: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> Message-ID: <070.695a894c20f12e5cc5111204fcf6a713@haskell.org> #9215: GHC 7.8.2 mingw-w64: symbol not found in link -------------------------------------+---------------------------------- Reporter: stuartallenmills | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by stuartallenmills): * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 17:30:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 17:30:01 -0000 Subject: [GHC] #9215: GHC 7.8.2 mingw-w64: symbol not found in link In-Reply-To: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> References: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> Message-ID: <070.8ad7ad32578ed77b6e0dcf3319349f14@haskell.org> #9215: GHC 7.8.2 mingw-w64: symbol not found in link -------------------------------------+---------------------------------- Reporter: stuartallenmills | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by stuartallenmills): * failure: None/Unknown => Other * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 17:31:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 17:31:34 -0000 Subject: [GHC] #9216: hiding imports doesn't seem to check if an import exists Message-ID: <044.4af8f0db5847c0548c250c2f9c798063@haskell.org> #9216: hiding imports doesn't seem to check if an import exists --------------------------+------------------------------------------------ Reporter: flazz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Compiler | Operating System: Unknown/Multiple Keywords: import | Type of failure: GHC accepts invalid program hiding | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ {{{ module Main where import Prelude hiding (thisDoesNotExist0x1234) -- should it fail here? main = putStrLn "hiya" }}} This seems to interpret just fine in ghci and compile fine in ghc ? it seems that it shouldn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 17:35:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 17:35:38 -0000 Subject: [GHC] #9215: GHC 7.8.2 mingw-w64: symbol not found in link In-Reply-To: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> References: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> Message-ID: <070.bc6d44f5b7e649caf107a2315d9abe65@haskell.org> #9215: GHC 7.8.2 mingw-w64: symbol not found in link -------------------------------------+---------------------------------- Reporter: stuartallenmills | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 18:21:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 18:21:17 -0000 Subject: [GHC] #9217: GHCi accepts any operator as a value constructor when enclosed in parens Message-ID: <045.ae8ab6cdf76cf52d2a61573909b20094@haskell.org> #9217: GHCi accepts any operator as a value constructor when enclosed in parens ------------------------------------+------------------------------------- Reporter: wz1000 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Eg:- 'data P = (+) Char Char' is accepted by GHCi However 'data P = (-) Char Char' is accepted by GHCi 7.8.2, but is reported to be rejected by GHC 7.6.3 GHCi 7.4 is reported to reject these inputs. GHC 7.8.2 also rejects these inputs. Operators defined this way are inaccessible and do not shadow existing operators. Legal operators(those prefixed by a colon) act normally -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 18:22:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 18:22:22 -0000 Subject: [GHC] #9217: GHCi accepts any operator as a value constructor when enclosed in parens In-Reply-To: <045.ae8ab6cdf76cf52d2a61573909b20094@haskell.org> References: <045.ae8ab6cdf76cf52d2a61573909b20094@haskell.org> Message-ID: <060.befb4ef65f678c8903df1f12073850d4@haskell.org> #9217: GHCi accepts any operator as a value constructor when enclosed in parens -------------------------------------+------------------------------------ Reporter: wz1000 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by wz1000: Old description: > Eg:- 'data P = (+) Char Char' is accepted by GHCi > However 'data P = (-) Char Char' is accepted by GHCi 7.8.2, but is > reported to be rejected by GHC 7.6.3 > GHCi 7.4 is reported to reject these inputs. > GHC 7.8.2 also rejects these inputs. > Operators defined this way are inaccessible and do not shadow existing > operators. > Legal operators(those prefixed by a colon) act normally New description: Eg:- 'data P = (+) Char Char' is accepted by GHCi However 'data P = (-) Char Char' is accepted by GHCi 7.8.2, but is reported to be rejected by GHC 7.6.3 GHCi 7.4 is reported to reject these inputs. GHC 7.8.2 also rejects these inputs. Operators defined this way are inaccessible and do not shadow existing operators. Legal operators(those prefixed by a colon) act normally when surrounded by parens -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 18:40:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 18:40:21 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.62ce0ac968b8bce31e9fbef292646bb5@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): Hold the phone! This is all wrong! == Interaction with partial type signatures == I just ended a great discussion with Iavor and with David Darais about this whole issue, and we came to the conclusion that (PARGEN) is a bad idea. The problem isn't that (PARGEN) doesn't work (I still think it ''does'' work) but that it paints us into a corner. We looked at PartialTypeSignatures, which describes an upcoming feature to allow wildcards in type signatures of terms, in case the programmer does not want to write down an entire type. With partial type signatures, wildcards ''can'' unify with lexically-quantified variables, contrary to the side condition debated in this ticket. And, the feature looks useful, as types get more complicated and the burden of writing out a full signature increases. There is no discussion (that I saw) of polymorphic recursion w.r.t. partial type signatures, so I don't know what the term-level plan is on that issue. == A change of heart == Looking at all of this (now back at the type level), I see that we have two, mutually exclusive options: 1) Allow polymorphic recursion in the presence of a partial kind signature via (PARGEN) + side condition. 2) Allow more flexible partial kind signatures. I think (2) is of greater benefit to users than is (1). As a further bonus, (2) is '''much''' simpler than (1) -- indeed, it is what we have today. == A new proposal == Thus, I propose a radically different solution to the original problem: come up with a syntax for a CUSK for classes. Call this proposal (NEWCUSK). Specifically: '''A class or datatype is said to have a CUSK if and only if all of its type variables are annotated.''' Otherwise, like (BASELINE). As with (BASELINE), polymorphic recursion is possible only in the presence of a CUSK. Under (NEWCUSK), Edward's original example will not work, but adding an annotation to `a` (presumably, `(a :: k2)`) would make it work. (NEWCUSK) means that a declaration like `data Foo a b :: *` will '''not''' have a CUSK. This would be a breaking change if a programmer used `:: *` to force other variables to have kind `*` and/or used polymorphic recursion. Note that in the case where a user puts the `::` right after the datatype name, there are no type variables, so every one is vacuously annotated -- no breakage here. If we are opposed to making this breaking change, the (NEWCUSK) proposal still works while also having a top-level `::` indicate a CUSK. I just think that the top-level `::` syntax is a strange bump in the language design. (Though, to be fair, I couldn't think of something better at the time.) == Relationship to GADT pattern-matching == In continuing to think about all this, I have come to realize that (PARGEN) is quite strange, indeed. Let's consider some more familiar territory: {{{ data G a where GBool :: G Bool foo GBool = True }}} GHC rightly rejects the code above saying, essentially, that `foo` does not have a principal type. `foo :: G a -> a` and `foo :: G a -> Bool` are both very reasonable candidates and are not comparable. (The error message, of course, discusses untouchables... but it's really talking about principal types.) But, if we apply the (PARGEN) philosophy to type-checking GADT pattern- matches, we would decide that `foo :: G a -> Bool` ''is'' the principal type. This is because the (PARGEN) philosophy would say to prevent the inferred result type from mentioning any type variables refined in the pattern match. I am playing a little fast and loose here talking about the un-articulated "(PARGEN) philosophy", but I'm hoping readers can understand my concern. A perhaps tighter way of saying this is: I conjecture that the over-permissiveness of the type system in Fig. 10 (p. 25) of [http://msr-waypoint.com/en-us/um/people/simonpj/papers/constraints /jfp-outsidein.pdf OutsideIn] (as discussed in Sec. 4.4) might be fixed by adding a side condition to the `Case` rule, essentially saying that any type variables refined in a local equality assumption cannot then appear in other types discovered by using constraints generated by the `case`. To make this meaningful, the type system would have to be re-written in a bidirectional manner, so we can know which types come "from" the `case` vs. which types go "to" the `case`. I leave the exact formulation as future work, but I'd be very curious to read a response to this conjecture. == Conclusion == What do others think of (NEWCUSK) and the points I've brought up here? It seems to solve the original problem (no polymorphic recursion available in classes) while not upsetting too much else. And, it seems to have nicer theoretical properties and is easier to explain to users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 18:48:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 18:48:19 -0000 Subject: [GHC] #9216: hiding imports doesn't seem to check if an import exists In-Reply-To: <044.4af8f0db5847c0548c250c2f9c798063@haskell.org> References: <044.4af8f0db5847c0548c250c2f9c798063@haskell.org> Message-ID: <059.fc2057525ce69530b0bd525e580b234e@haskell.org> #9216: hiding imports doesn't seem to check if an import exists ------------------------------------------------+-------------------------- Reporter: flazz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: import Operating System: Unknown/Multiple | hiding Type of failure: GHC accepts invalid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: This warning is reported by `-fwarn-dodgy-imports`. This is not considered an error, to aid in backward compatibility. In your example, one assumes that some past Prelude ''did'' export that symbol. Now that Prelude no longer does, it seems a little silly to stop your whole module from compiling. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 21:31:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 21:31:51 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.b3dfd2639fe559156874d2db5c00ac4d@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by dolio): This example: {{{ foo :: forall f a. f a -> f a foo = ... where g :: f Int -> Int }}} just seems like bad policy to me. The top signature is a partial signature, the missing pieces (the kinds) should be solved, and it is not sufficient to only look at the signature of `foo` to do that solving. I can construct similar examples in Ermine, although it is a bit convoluted due to our currently meager tooling: {{{ :type let { f : forall f a. f a -> f a ; f x = x } in f forall {k} (f : k -> *) (a : k). f a -> f a }}} {{{ :type let { f : forall f a. f a -> f a ; f x = x where { z = g x ; g : some f a b. f a -> f b -> b ; g _ _ = "" } } in f forall (f : * -> *) (a : *). f a -> f a }}} Effectively, this signature is the same as (for us) {{{ some k1 k2. forall (f : k1) (a : k2). f a -> f a }}} although we don't currently handle some-bound kinds; unspecified kinds act similarly, though. The problem with this example seems to be deciding on things too early, not generalizing. For instance, doesn't PARTIAL error if you apply the same kind of policy to: {{{ foo :: forall f a. f a -> f a foo = ... where g :: f Maybe -> f Maybe }}} `f` will be defaulted to `* -> *`, but that is wrong for application to `Maybe`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 21:39:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 21:39:08 -0000 Subject: [GHC] #9217: GHCi accepts any operator as a value constructor when enclosed in parens In-Reply-To: <045.ae8ab6cdf76cf52d2a61573909b20094@haskell.org> References: <045.ae8ab6cdf76cf52d2a61573909b20094@haskell.org> Message-ID: <060.916923c5e78a1509e62d9720d8482e25@haskell.org> #9217: GHCi accepts any operator as a value constructor when enclosed in parens -------------------------------------+------------------------------------ Reporter: wz1000 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. It looks to be a duplicate of #8556. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 23:03:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 23:03:12 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.4d33347816b49cfd2319f3ffe41548c3@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): OK, so (NEWCUSK) is precisely (BASELINE) with a slightly expanded definition of CUSK (c.f. the [http://www.haskell.org/ghc/docs/latest/html/users_guide/kind- polymorphism.html#complete-kind-signatures current definition in the user manual]). I'm all for that; I quite liked (BASELINE): it's pretty simple and lines up precisely with the term-level story (a la Mark Jones). Just to check, though, let's be sure we agree: {{{ data T1 f a = MkT1 (f a) -- No CUSK -- Gets T1 :: forall k. (k->*) -> k -> * -- The generalisation takes place in the third bullet of step 3 of (BASELINE) data T2 a b :: * -- Presumably a nullary data type -- No CUSK -- Gets T2 :: forall k1 k2. k1 -> k2 -> * -- Very similar to T1 }}} I have no idea what you mean by "2) Allow more flexible partial kind signatures" in comment:19. Could you update the wiki page with: * (NEWCUSK) (= (BASELINE) + revised defn of CUSK) * the typing rules for closed type families Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 23:11:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 23:11:20 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC Message-ID: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC ------------------------------------+--------------------------------- Reporter: komadori | Owner: komadori Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3390 | ------------------------------------+--------------------------------- The Windows binary distribution of GHC incorporates a version of MinGW which has not been updated for several releases and is now out-of-date. It should be upgraded. The previous time this was done appears to correlate with ticket #3390. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 18 23:17:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jun 2014 23:17:34 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.367e4c883fb3fae0851c2946383b2685@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC ---------------------------------+------------------------------------ Reporter: komadori | Owner: komadori Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #3390 ---------------------------------+------------------------------------ Comment (by komadori): The MinGW binaries used by the GHC build are stored in a git repository (http://git.haskell.org/ghc-tarballs.git/tree). Note that the ia32 binaries use the original MinGW and the amd64 binaries use the MinGW-w64 fork. kyra suggests (http://www.haskell.org/pipermail/ghc- devs/2014-June/005172.html) switching to use MinGW-w64 for both platforms, but this apparently requires some patches to GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 02:32:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 02:32:33 -0000 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@haskell.org> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@haskell.org> Message-ID: <059.9df015a63d8bee60f983a5ca41fb19da@haskell.org> #1475: Adding imports and exports with Template Haskell -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by SimonHengel): Just because I've been pushing for this in the past, I solved my use case in a different way. For me closing this as won't fix would be ok. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 06:29:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 06:29:33 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.8375b3ce43f2794b068231015393feb2@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC ---------------------------------+------------------------------------ Reporter: komadori | Owner: komadori Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #3390 ---------------------------------+------------------------------------ Comment (by simonpj): Robin, as [http://www.haskell.org/pipermail/ghc-devs/2014-June/005174.html my email to you] (who I is komadori, comment 1) says, we'd be thrilled if felt like leading or partnering with eg. Kyra to do this. Thank you! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 07:01:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 07:01:40 -0000 Subject: [GHC] #8226: Remove the old style -- # Haddock comments. In-Reply-To: <047.96b6209768296ad11c174e077e349059@haskell.org> References: <047.96b6209768296ad11c174e077e349059@haskell.org> Message-ID: <062.3141e3795ffa9d66bbed6dce4678e143@haskell.org> #8226: Remove the old style -- # Haddock comments. -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: adinapoli Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by adinapoli): Replying to [comment:8 Fuuzetsu]: > Hm, I'm unsure why this is proving difficult to implement. Oh, it's easy, that's because it's my first foray into GHC and its Lexer hacking ever :) > > * Remove {{{#}}} from any sections lexing Haddock comment so sections like {{{[$docSym \#]}}} become just {{{[$docSym]}}} or whatever the appropriate syntax is there. > > * in {{{}}} remove the lexing of {{{-- #}}} all together. > > * Remove {{{ITdocOptionsOld}}}. > > * inside {{{isNormalComment}}}, I'm unsure exactly how to proceed. You say removing {{{#}}} from {{{notFollowedByDocOrPragma}}} stops {{{RULES}}} from working. In that case I say keep it there as it is now, in the end it does not matter because we'll stop treating it as a Haddock thing anyway. It will now simply check whether a {{{#}}} comment is special for {{{RULES}}} instead of for both {{{RULES}}} and Haddock. This is an assumption however so this might be where I'm going wrong. > > * {{{withLexedDocType}}} remove the case for {{{'#'}}}: if we removed the case for {{{-- #}}} in {{{}}} then we should never enter {{{withLexedDocType}}} through {{{multiline_doc_comment}}} at least as far as I can see. > > * Remove the case in for {{{ITdocOptionsOld}}} in {{{getOptions'}}} in {{{HeaderInfo.hs}}}. > Apart from the docSym section I already tried was you said, with no luck. This is a gist to a patch which follows your guidelines; unless I have tweaked the wrong things, it should roughly do what you listed: https://gist.github.com/adinapoli/a08683a32412c8fddb43 This validates fine but it doesn't fix the problem! If I try the "Fail.hs" example attached in the ticket, the Lexer still chokes on that comment which "looks like a pragma". But originally my fix on "isNormalComment" fixed that, but amusingly if I tweak that function, as part of this patch, it triggers the problem I've reported, aka the RULES gets interpreted as comments and validate fails due to warnings for unutilized functions. Where's the flaw in my reasoning? :) > PS: It'd be great if you could create a wiki page (either on GHC wiki or NixOS wiki) on your workflow on GHC hacking with nix. More than happy to do so, didn't think was something people would have been interested in :) Alfredo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 07:56:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 07:56:20 -0000 Subject: [GHC] #9210: "overlapping instances" through FunctionalDependencies In-Reply-To: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> References: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> Message-ID: <062.eb481a36c730fa6ca1c57c56003b2497@haskell.org> #9210: "overlapping instances" through FunctionalDependencies --------------------------------------------+------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * cc: dreixel (added) Comment: OK, well I tried the effect of solving problem 1 by making the two instance declarations illegal. The changes in FunDeps are simple: * Remove altogether the alternative guarded by `| isJust (tcUnifyTys bind_fn rtys1' rtys2')`, mentioned above * Change the definition of `fdeqs` thus {{{ - fdeqs = zipAndComputeFDEqs (\_ _ -> False) rtys1' irs2' + fdeqs = zipAndComputeFDEqs eqType rtys1' irs2' }}} This resulted in four test-suite failures {{{ Unexpected failures: ghci/scripts ghci047 [bad stderr] (ghci) polykinds T9106 [stderr mismatch] (normal) typecheck/should_compile FD4 [exit code non-0] (normal) typecheck/should_compile T7875 [exit code non-0] (normal) }}} All were for the same reason: instance declarations that were previously accepted are now rejected. I looked a bit more at `T7875`. It is described by `Note [Weird fundeps]` in `TcInteract`, which reads as follows: {{{ Note [Weird fundeps] ~~~~~~~~~~~~~~~~~~~~ Consider class Het a b | a -> b where het :: m (f c) -> a -> m b class GHet (a :: * -> *) (b :: * -> *) | a -> b instance GHet (K a) (K [a]) instance Het a b => GHet (K a) (K b) The two instances don't actually conflict on their fundeps, although it's pretty strange. So they are both accepted. Now try [W] GHet (K Int) (K Bool) This triggers fudeps from both instance decls; but it also matches a *unique* instance decl, and we should go ahead and pick that one right now. Otherwise, if we don't, it ends up unsolved in the inert set and is reported as an error. Trac #7875 is a case in point. }}} This does indeed look weird to me. And it's incredibly fragile. If the wanted constraint doesn't '''yet''' match a unique instance decl (perhaps because some other constraint has not yet done a unification) then we won't pick the instance, so we will generate both (conflicting) fundeps, and we will get an error (from the fundep) even though the constraint is ultimately solved. This seems terrible to me. So I think I'd argue that #7875 should be rejected (hence adding Pedro, its author, in cc). `FD4` actually comes from #1797, and involves a combination of functional dependencies and overlapping instances. I'm not sure we've ever fully thought through this conbination, but rejecting this would indeed make people unhappy. I have not looked at #9106 or `ghci047`. I feel strongly disinclined to dive once more into the functional dependency swamp. If someone (Iavor? Pedro?) would like to help that would be great. Until then, I totally agree that the behaviour of this ticket is bizarre and wrong. But without help I don't know how to fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 10:35:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 10:35:34 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.5f33070d1572c4f822b014c78a5d4e7c@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------ Reporter: nh2 | Owner: 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 | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 10:50:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 10:50:45 -0000 Subject: [GHC] #9161: Pattern synonyms interact badly with data kinds In-Reply-To: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> References: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> Message-ID: <066.798320939048ccda6e9dabe211ba5f53@haskell.org> #9161: Pattern synonyms interact badly with data kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: renamer, pattern Resolution: | synonyms, data kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile-time | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by simonpj): Basically yes. I suggest one of two things: * Add pattern synonyms as `AGlobal (AConLike (PatSynCon (panic "...")))`. Apart from the panic, this is exactly how ''imported'' pattern synonyms will appear, and `TcHsType.tcTyVar` will call `wrongThingErr` on it. It would make sense for ''local'' pattern synonmys to behave the same way. The panic won't be looked at because `TcEnv.wrongThingErr` doesn't look at the payload. * Short cut: don't extend the environment. Instead, in the "no in scope during type checking" error, test for `DataName` and instead complain about using a pattern synonym in a type. Better: do this only in the context of `tcTyVar`, by replicating a certain amount of the `tcLookup` code. This is bit of a hack; I'd rather not do it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 11:35:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 11:35:17 -0000 Subject: [GHC] #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> In-Reply-To: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> References: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> Message-ID: <062.5059261e9e0c99ae95eb612951192fe2@haskell.org> #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> -------------------------------------------------+------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by rezb1t): I'd like to note that this problem occurs when compiling darcs 2.8.4, happy, alex, network 2.5.0.0, and quite a few other libraries. Something is very wrong here, GHC either uses a tiny amount of RAM or it uses gigabytes. When compiling darcs, GHC used 4GB of RAM on one source file! Weirder yet, I've noticed that when used in tandem with cabal-install, the RAM isn't freed in between source files.. whether this is intended or not, I couldn't tell, but running ghc in make mode doesn't do this. The behavior is the same whether it be GHC 7.8.2 or HEAD of ghc-7.8 currently -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 12:16:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 12:16:32 -0000 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@haskell.org> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@haskell.org> Message-ID: <059.2998ded59b82bd44207fe2e59de0ce49@haskell.org> #1475: Adding imports and exports with Template Haskell -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I still want it. `singletons` generates gobs of boilerplate, some of which it is important to export. It's not terribly hard for users to write the export lists manually, but it's just more boilerplate that would be nice to automate. However, for my use case, I care only about TH writing to ''export'' lists, not ''import'' lists. TH-controlled export lists wouldn't hit the problem SPJ points out in comment:18. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 13:42:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 13:42:43 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.ca4c28731e88f5cf742a0b8b1ed8d48b@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: stranal/should_compile/T9208 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * testcase: => stranal/should_compile/T9208 Comment: Good point, thank you. In the test program you use `unsafeCoerce`, and in fact you end up doing something like {{{ (coerce ()) arg }}} that is, you take `()` (produced by `loadTHData`) and apply it to something (in `runTH`). So you are going to get some bizarre runtime crash. Maybe your real example was not as perverse as this one. But regardless, it shouldn't crash the compiler, I agree. I've fixed that; patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 13:59:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 13:59:34 -0000 Subject: [GHC] #9219: Parallel build proceeds despite errors Message-ID: <048.2de32bbd0472065d8e68806efc98b66c@haskell.org> #9219: Parallel build proceeds despite errors -------------------------+------------------------------------------------- Reporter: | Owner: jstolarek | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Driver | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- A few weeks back during my work on singletons I got the following build log: {{{ Building singletons-1.0... Preprocessing library singletons-1.0... [ 6 of 45] Compiling Data.Singletons.Util ( src/Data/Singletons/Util.hs, dist/build/Data/Singletons/Util.o ) [ 7 of 45] Compiling Data.Singletons.Syntax ( src/Data/Singletons/Syntax.hs, dist/build/Data/Singletons/Syntax.o ) [Data.Singletons.Util changed] [ 8 of 45] Compiling Data.Singletons.Names ( src/Data/Singletons/Names.hs, dist/build/Data/Singletons/Names.o ) [Data.Singletons.Util changed] [ 9 of 45] Compiling Data.Singletons.Promote.Monad ( src/Data/Singletons/Promote/Monad.hs, dist/build/Data/Singletons/Promote/Monad.o ) [Data.Singletons.Util changed] [10 of 45] Compiling Data.Singletons.Single.Monad ( src/Data/Singletons/Single/Monad.hs, dist/build/Data/Singletons/Single/Monad.o ) [Data.Singletons.Promote.Monad changed] [11 of 45] Compiling Data.Singletons.Promote.Eq ( src/Data/Singletons/Promote/Eq.hs, dist/build/Data/Singletons/Promote/Eq.o ) [Data.Singletons.Util changed] [12 of 45] Compiling Data.Singletons.Promote.Ord ( src/Data/Singletons/Promote/Ord.hs, dist/build/Data/Singletons/Promote/Ord.o ) [Data.Singletons.Util changed] [13 of 45] Compiling Data.Singletons.Promote.Bounded ( src/Data/Singletons/Promote/Bounded.hs, dist/build/Data/Singletons/Promote/Bounded.o ) [Data.Singletons.Util changed] [14 of 45] Compiling Data.Singletons.Promote.Type ( src/Data/Singletons/Promote/Type.hs, dist/build/Data/Singletons/Promote/Type.o ) [Data.Singletons.Util changed] [15 of 45] Compiling Data.Singletons.Promote.Defun ( src/Data/Singletons/Promote/Defun.hs, dist/build/Data/Singletons/Promote/Defun.o ) [Data.Singletons.Promote.Monad changed] [16 of 45] Compiling Data.Singletons.Promote ( src/Data/Singletons/Promote.hs, dist/build/Data/Singletons/Promote.o ) [Data.Singletons.Promote.Defun changed] [17 of 45] Compiling Data.Promotion.Prelude.Bounded ( src/Data/Promotion/Prelude/Bounded.hs, dist/build/Data/Promotion/Prelude/Bounded.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package syb-0.4.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package th-desugar-1.4.0 ... linking ... done. src/Data/Promotion/Prelude/Bounded.hs:34:27: Not in scope: ?boundedTypes? src/Data/Promotion/Prelude/Bounded.hs:34:27: GHC stage restriction: ?boundedTypes? is used in a top-level splice or annotation, and must be imported, not defined locally In the first argument of ?promoteBoundedInstances?, namely ?boundedTypes? In the expression: promoteBoundedInstances boundedTypes [18 of 45] Compiling Data.Singletons.Single.Type ( src/Data/Singletons/Single/Type.hs, dist/build/Data/Singletons/Single/Type.o ) [Data.Singletons.Single.Monad changed] [19 of 45] Compiling Data.Singletons.Single.Eq ( src/Data/Singletons/Single/Eq.hs, dist/build/Data/Singletons/Single/Eq.o ) [Data.Singletons.Util changed] [20 of 45] Compiling Data.Singletons.Single.Data ( src/Data/Singletons/Single/Data.hs, dist/build/Data/Singletons/Single/Data.o ) [Data.Singletons.Single.Monad changed] [21 of 45] Compiling Data.Singletons.Single ( src/Data/Singletons/Single.hs, dist/build/Data/Singletons/Single.o ) [Data.Singletons.Promote changed] [22 of 45] Compiling Data.Singletons.Prelude.Instances ( src/Data/Singletons/Prelude/Instances.hs, dist/build/Data/Singletons/Prelude/Instances.o ) [Data.Singletons.Single changed] [23 of 45] Compiling Data.Singletons.Prelude.Bool ( src/Data/Singletons/Prelude/Bool.hs, dist/build/Data/Singletons/Prelude/Bool.o ) [Data.Singletons.Prelude.Instances changed] [24 of 45] Compiling Data.Singletons.Prelude.Eq ( src/Data/Singletons/Prelude/Eq.hs, dist/build/Data/Singletons/Prelude/Eq.o ) [Data.Singletons.Prelude.Bool changed] [25 of 45] Compiling Data.Singletons.CustomStar ( src/Data/Singletons/CustomStar.hs, dist/build/Data/Singletons/CustomStar.o ) [Data.Singletons.Prelude.Bool changed] [26 of 45] Compiling Data.Promotion.Prelude.Eq ( src/Data/Promotion/Prelude/Eq.hs, dist/build/Data/Promotion/Prelude/Eq.o ) [Data.Singletons.Prelude.Eq changed] [27 of 45] Compiling Data.Promotion.Prelude.Bool ( src/Data/Promotion/Prelude/Bool.hs, dist/build/Data/Promotion/Prelude/Bool.o ) [Data.Singletons.Prelude.Bool changed] [28 of 45] Compiling Data.Singletons.TypeRepStar ( src/Data/Singletons/TypeRepStar.hs, dist/build/Data/Singletons/TypeRepStar.o ) [Data.Singletons.Prelude.Eq changed] [29 of 45] Compiling Data.Singletons.Prelude.Ord ( src/Data/Singletons/Prelude/Ord.hs, dist/build/Data/Singletons/Prelude/Ord.o ) [Data.Singletons.Prelude.Bool changed] [30 of 45] Compiling Data.Promotion.Prelude.Ord ( src/Data/Promotion/Prelude/Ord.hs, dist/build/Data/Promotion/Prelude/Ord.o ) [Data.Singletons.Prelude.Ord changed] [31 of 45] Compiling Data.Singletons.TypeLits ( src/Data/Singletons/TypeLits.hs, dist/build/Data/Singletons/TypeLits.o ) [Data.Singletons.Prelude.Bool changed] [32 of 45] Compiling Data.Singletons.TH ( src/Data/Singletons/TH.hs, dist/build/Data/Singletons/TH.o ) [Data.Singletons.Prelude.Bool changed] [33 of 45] Compiling Data.Singletons.Prelude.Base ( src/Data/Singletons/Prelude/Base.hs, dist/build/Data/Singletons/Prelude/Base.o ) [Data.Singletons.Prelude.Bool changed] [34 of 45] Compiling Data.Singletons.Prelude.Either ( src/Data/Singletons/Prelude/Either.hs, dist/build/Data/Singletons/Prelude/Either.o ) [Data.Singletons.Prelude.Base changed] [35 of 45] Compiling Data.Promotion.Prelude.Either ( src/Data/Promotion/Prelude/Either.hs, dist/build/Data/Promotion/Prelude/Either.o ) [Data.Singletons.Prelude.Either changed] [36 of 45] Compiling Data.Singletons.Prelude.Tuple ( src/Data/Singletons/Prelude/Tuple.hs, dist/build/Data/Singletons/Prelude/Tuple.o ) [Data.Singletons.Prelude.Instances changed] [37 of 45] Compiling Data.Promotion.Prelude.Tuple ( src/Data/Promotion/Prelude/Tuple.hs, dist/build/Data/Promotion/Prelude/Tuple.o ) [Data.Singletons.Prelude.Tuple changed] [38 of 45] Compiling Data.Promotion.Prelude.Base ( src/Data/Promotion/Prelude/Base.hs, dist/build/Data/Promotion/Prelude/Base.o ) [Data.Singletons.Prelude.Base changed] [39 of 45] Compiling Data.Singletons.Prelude.List ( src/Data/Singletons/Prelude/List.hs, dist/build/Data/Singletons/Prelude/List.o ) [Data.Singletons.Prelude.Base changed] [40 of 45] Compiling Data.Singletons.Prelude.Maybe ( src/Data/Singletons/Prelude/Maybe.hs, dist/build/Data/Singletons/Prelude/Maybe.o )[Data.Singletons.Prelude.Instances changed] [41 of 45] Compiling Data.Singletons.Prelude ( src/Data/Singletons/Prelude.hs, dist/build/Data/Singletons/Prelude.o ) [Data.Singletons.Prelude.Base changed] [42 of 45] Compiling Data.Promotion.Prelude.List ( src/Data/Promotion/Prelude/List.hs, dist/build/Data/Promotion/Prelude/List.o ) [Data.Promotion.Prelude.Ord changed] [43 of 45] Compiling Data.Promotion.Prelude.Maybe ( src/Data/Promotion/Prelude/Maybe.hs, dist/build/Data/Promotion/Prelude/Maybe.o ) [Data.Singletons.Prelude.Maybe changed] [45 of 45] Compiling Data.Promotion.TH ( src/Data/Promotion/TH.hs, dist/build/Data/Promotion/TH.o ) [Data.Singletons.Prelude.Bool changed] }}} Notice how file 18 of 45 fails to build and yet the build does not stop. It seems that while one thread fails the remaining ones pick up other files that can be compiled despite the failure. I'm not really sure if I'm against this design choice, but I'd certainly expect to get information that something went wrong during the build. Here I was confused when I realised that despite seemingly successful compilation my package was not built. Only after examining the build log I saw that one of the modules failed to build. This should be changed to clearly notify the user that compilation was not successful. PS. At first I thought this is cabal-install's fault, but [https://github.com/haskell/cabal/issues/1809 this was ruled out]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 15:24:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 15:24:28 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.0c3bd94e44b618119f3c6e808d50f26c@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): By "2) Allow more flexible partial kind signatures", I meant that, under (NEWCUSK), the kind of un-annotated type variables ''can'' unify with lexically-scoped kind variables, allowing the following to type-check: {{{ data Q f (a :: k) where MkQ :: f a -> Q f a -- fails under (PARTIAL) and (PARGEN) -- succeeds under (BASELINE) and (NEWCUSK) }}} If partial type signatures on terms are so useful (and I think they will be), then partial kind signatures, like the one on `Q`, would be, too. Yes, I am agreed with the examples in comment:21. (NEWCUSK) description was already on wiki page, and I have now added rules for closed type families. These rules are a breaking change from today's closed type families, but a "good" breakage, in that it tightens up the specification from the current wonky state of affairs. See the example from comment:18, which would no longer type-check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 16:07:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 16:07:58 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.5be9d88c729660be96a728342d51a4f8@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: stranal/should_compile/T9208 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by luite): Yes, in my real code I'm not quite doing this, but since it's part of the ghcjs-prim package I had to remove some code (`foreign import javascript`) that's not supported by normal GHC. The actual `loadTHData` would do some JavaScript runtime calls to load the code in the `ByteString`, initialise the info tables and then return a closure of the expected type. It's part of my work to decouple Template Haskell from the GHC process and thus the host platform. GHC sets up a connection to a TH service and incrementally sends compiled code (target architecture) to it, the TH service can query GHC for reification. For GHCJS this is a node.js server, but when when my proof of concept works, I'll ask on ghc-devs if there's interest in extending this for general cross compilation in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 16:29:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 16:29:37 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.d24dee7cd9cb218b1c39fba395f35ce5@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by dolio): I don't have a particular dislike for NEWCUSK, I think. Anything that allows you to do polymorphic recursion with sufficient annotation is at least tolerable. However, I don't really understand what the problem with PARGEN is that caused the added restrictions that make it less desirable. Is the entire problem closed, partially annotated type families that are non-parametric, and therefore act like GADT definitions and lack principal types? And is the motivation to then have a uniform rule for both these and everything else that doesn't require detecting situations that would fail to have a principal type? You (goldfire) and I discussed what we're doing in Ermine, which is now quite a lot like the (original) PARGEN strategy. It seems to work for the sort of partially specified type signatures we have, and it works for polymorphic recursion, including polymorphic recursion with partial signatures. For instance: {{{ let { u : a -> a -> a ; u x _ = x ; f : some b c. forall a. a -> b -> c ; f x y = let { z = u x y } in g x y ; g _ y = f () y } in f }}} Without the signature on `f` the inferred type is `() -> () -> c`, but with it the inferred type is `b -> b -> c`. Anyhow, I'm not particularly adamant about your choice of (original) PARGEN vs. NEWCUSK. But I'd like to understand what exactly the objections were, and whether they're tied to GADTs and type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 17:23:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 17:23:30 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.5b8b0efcf0baff89c80cf624d38194d0@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------ Reporter: nh2 | Owner: 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 | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by duncan): So I've started working on this. The design I'm following will mean that ghc the library does not depend on Cabal, but ghc-pkg will continue to depend on Cabal and so Cabal will still be built and shipped with ghc as it is now. (It also doesn't involve any unnatural splits in the Cabal lib). If I can get away with it, I'll also remove the support for single-file style package dbs, and just use the (now standard) `package.conf.d` style dbs. Any objections? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 17:30:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 17:30:31 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.73985a9ed5685c2c69187816dbc8bcf5@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): Replying to [comment:23 dolio]: > Is the entire problem closed, partially annotated type families that are non-parametric, and therefore act like GADT definitions and lack principal types? Not just these. Also partially annotated datatypes and classes will lack principal kinds. Here is the example: {{{ data W f (a :: k) where MkW :: W Maybe Int -> W f a }}} Do we have `W :: (k -> *) -> k -> *` or `W :: (* -> *) -> k -> *`, among others? Both seem reasonable, though the latter is certainly easier to infer. To eliminate ambiguity, we have to add the restriction to (PARGEN). This makes it clear that the second kind is the only allowable one. > And is the motivation to then have a uniform rule for both these and everything else that doesn't require detecting situations that would fail to have a principal type? Yes, that's my understanding. > > You (goldfire) and I discussed what we're doing in Ermine, which is now quite a lot like the (original) PARGEN strategy. From my understanding, your original implementation was like (PARGEN) + side condition. Only after discussing did you (effectively) remove the side condition. > It seems to work for the sort of partially specified type signatures we have, and it works for polymorphic recursion, including polymorphic recursion with partial signatures. For instance: > > {{{ > let { u : a -> a -> a > ; u x _ = x > ; f : some b c. forall a. a -> b -> c > ; f x y = let { z = u x y } in g x y > ; g _ y = f () y > } in f > }}} > > Without the signature on `f` the inferred type is `() -> () -> c`, but with it the inferred type is `b -> b -> c`. I believe the original (PARGEN) "works", in that it is sound, for an appropriate definition of sound. However, it can infer non-principal types, which seems bad. I don't think it's very wrong for Ermine to adopt (PARGEN) - side condition, but I have to say I don't think it's very right, either. I believe that the example you give has a principal type, which is inferred correctly. > > Anyhow, I'm not particularly adamant about your choice of (original) PARGEN vs. NEWCUSK. But I'd like to understand what exactly the objections were, and whether they're tied to GADTs and type families. I would say that the problems are wholly independent of GADTs and type families. There is a problem with closed type families that is closely related, but the fundamental problem is independent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 17:54:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 17:54:51 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.38a37ae67e4bca526abc67376801618b@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by dolio): This example: {{{ data W f (a :: k) where MkW :: W Maybe Int -> W f a }}} is just another Milner-Mycroft problem. The inferred kind is `(* -> *) -> k -> *`. The principal kind is `k0 -> k -> *`, but it can't be inferred. Just like {{{ data W f a = W (W Maybe Int) }}} will have inferred kind `(* -> *) -> * -> *`, even though `k0 -> k -> *` is valid and strictly more general. > From my understanding, your original implementation was like (PARGEN) + side condition. Only after discussing did you (effectively) remove the side condition. Yes, but this is because we were using skolem variables, which can lead to confusing rejection of partially annotated mutual definitions. When we started basing our algorithm on something closer to GHC, using what I think you called SigTvs, plus a per-signature distinctness check, that objection was no longer valid. > I believe the original (PARGEN) "works", in that it is sound, for an appropriate definition of sound. However, it can infer non-principal types, which seems bad. Hindley-Milner infers non-principal types (so does GHC, of course). > I don't think it's very wrong for Ermine to adopt (PARGEN) - side condition, but I have to say I don't think it's very right, either. I still don't think we have an example that doesn't involve GADTs or type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 17:55:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 17:55:05 -0000 Subject: [GHC] #8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) In-Reply-To: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> References: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> Message-ID: <060.a8a813680e604ebf3624e660d34e96f5@haskell.org> #8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) ---------------------------------------------+----------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Test Case: stranal/should_run/T8425 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------------+----------------------------- Comment (by jloos): is this related? https://github.com/bos/vector-binary-instances/issues/4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 18:03:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 18:03:32 -0000 Subject: [GHC] #9220: type roles for unboxed arrays Message-ID: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ rwbarton at morphism:~$ ghci GHCi, version 7.8.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :i Data.Array.Unboxed.UArray type role Data.Array.Base.UArray representational phantom data Data.Array.Base.UArray i e = Data.Array.Base.UArray !i !i {-# UNPACK #-} !Int GHC.Prim.ByteArray# -- Defined in ?Data.Array.Base? -- [instances trimmed] Prelude> :i Data.Array.IO.IOUArray type role Data.Array.IO.Internals.IOUArray representational phantom newtype Data.Array.IO.Internals.IOUArray i e = Data.Array.IO.Internals.IOUArray (Data.Array.Base.STUArray GHC.Prim.RealWorld i e) -- Defined in ?Data.Array.IO.Internals? Prelude> :i Data.Array.ST.STUArray type role Data.Array.Base.STUArray nominal representational phantom data Data.Array.Base.STUArray s i e = Data.Array.Base.STUArray !i !i {-# UNPACK #-} !Int (GHC.Prim.MutableByteArray# s) -- Defined in ?Data.Array.Base? Prelude> :i Data.Array.Storable.StorableArray type role Data.Array.Storable.Internals.StorableArray representational phantom data Data.Array.Storable.Internals.StorableArray i e = Data.Array.Storable.Internals.StorableArray !i !i Int !(GHC.ForeignPtr.ForeignPtr e) -- Defined in ?Data.Array.Storable.Internals? }}} These phantom roles for the element types let me create an unboxed array of one type (like Word8), cast it with `coerce` to another type (like Word64) and read outside the bounds of the array. I think they should all be nominal, since a newtype of an existing type could have a totally unrelated MArray or Storable instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 18:15:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 18:15:43 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.cbb351c6188dad3fe8403b974fdb0a6d@haskell.org> #9220: type roles for unboxed arrays --------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by goldfire): This is an area (arrays in Haskell) I know little about. How does this request compare to #9163, asking for `Ptr` to have a phantom role? Perhaps the difference is that `Ptr` refers to foreign objects but arrays store proper Haskell values? Sorry -- just not terribly familiar over here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 18:18:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 18:18:00 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.775a7bf95725e025e8a7551aa29ee5f1@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------ Reporter: nh2 | Owner: 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 | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): No objection from me to removing the old package DB format, though you might find that you need to update some tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 19:15:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 19:15:05 -0000 Subject: [GHC] #9112: support for deriving Vector/MVector instances In-Reply-To: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> References: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> Message-ID: <060.23136ff861a453403f81e2bd87e1e21e@haskell.org> #9112: support for deriving Vector/MVector instances -------------------------------------+------------------------------------ Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Remi): * cc: remi.turk@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 21:56:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 21:56:24 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.dc58de56d54db7eade1a9413d3b8d20c@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): I have edited the [wiki:GhcKinds/KindInference wiki page] so that the beginning part says what we actually plan to do. See if you agree with it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 19 22:03:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jun 2014 22:03:51 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.895071c9f70a6bf9ac14dca6b585e157@haskell.org> #9220: type roles for unboxed arrays --------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by simonpj): A difference is that you can index arrays, and that leads to the out-of- bounds possibilities that Reid highlights. But wouldn't reprsentational do? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 06:45:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 06:45:15 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine Message-ID: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: high | Version: 7.8.2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- im seeing slowdowns in parallel builds of a (simple!!) 6 module project when I build it on a 40 core server i'm using for work. for any given ghc invocation with -jn, once n>10, i start to see a super linear slow down as a function of n heres some basic numbers at -j1 0m2.693s at -j4 0m2.507s at -j10 0m2.763s at -j25 0m12.634s at -j30 : 0m39.154s at -j40 : 0m57.511s at -j60 : 2m21.821s these timings are another 2-4x worse if ghc is invoked indirectly via cabal-install / setup.hs according to the linux utility latencytop, 100% of ghc's cpu time was spent on user-space lock contention when I did the -j40 invocation. the timing in the -j40 case stayed the same even when ghc was also passed -O0 (and -fforce-recomp to ensure it did the same ) a bit of experimentation makes me believe that in *ANY* cabalized project on a 40 core machine will exhibit this perf issue. cabal clean ; cabal configure --ghc-options="-j" ; cabal build -j1 should be enough to trigger the lock contention. That said, I'll try to cook up a minimal repro that i can share the source for post haste. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 07:12:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 07:12:00 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.b6351586a55f9fcfdb54121279c77b09@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by carter): so my understanding is that the parUpsweep function in compiler/main/GhcMake.hs is the main culprit / object to focus on for this performance issue, right? (literally the only thing thats tripped the the -jN ghc invocation ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 07:16:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 07:16:49 -0000 Subject: [GHC] #9206: OverloadedStrings breaks show? In-Reply-To: <054.f2651fc0f70b38fc1158c5aef9677e6d@haskell.org> References: <054.f2651fc0f70b38fc1158c5aef9677e6d@haskell.org> Message-ID: <069.ec9cb40b8a386aa65d3ebc44b817fab9@haskell.org> #9206: OverloadedStrings breaks show? -------------------------------------+------------------------------------ Reporter: j80JjBjVNRMajmA | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"aec9e75bb09f6a99d77d3aeea255229ffb1925fa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="aec9e75bb09f6a99d77d3aeea255229ffb1925fa" Improve documentation of defaulting rules with OverloadedStrings See #9206 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 07:16:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 07:16:49 -0000 Subject: [GHC] #9216: hiding imports doesn't seem to check if an import exists In-Reply-To: <044.4af8f0db5847c0548c250c2f9c798063@haskell.org> References: <044.4af8f0db5847c0548c250c2f9c798063@haskell.org> Message-ID: <059.51b0962f36e6a433ae1c6eee2a278492@haskell.org> #9216: hiding imports doesn't seem to check if an import exists ------------------------------------------------+-------------------------- Reporter: flazz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: import Operating System: Unknown/Multiple | hiding Type of failure: GHC accepts invalid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Simon Peyton Jones ): In [changeset:"cdc74311a23beef47d1418349d492a17bf62ed6f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cdc74311a23beef47d1418349d492a17bf62ed6f" Add a new section to the manual about hiding things that a module doesn't export See Trac #9216 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 07:16:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 07:16:50 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.dd6f272f4b9b91cd7144f703fa4178b9@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: stranal/should_compile/T9208 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2e362ddebf2286409b7423d3dd49152117c1ae56/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2e362ddebf2286409b7423d3dd49152117c1ae56" Make splitStrProdDmd (and similarly Use) more robust The issue here is avoiding a GHC crash when a program uses unsafeCoerce is a dangerous (or even outright-wrong) way. See Trac #9208 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 07:16:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 07:16:50 -0000 Subject: [GHC] #9196: Higher-rank constraint treated as type instead In-Reply-To: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> References: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> Message-ID: <062.450cfa15dc646045ebef70786460a777@haskell.org> #9196: Higher-rank constraint treated as type instead -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"9c621e9b1c7d8a02b48f06f041da605ce27f4d80/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9c621e9b1c7d8a02b48f06f041da605ce27f4d80" Reject forall types in constraints in signatures Fixes Trac #9196. Thanks to archblob for an initial stab at this. In the end I fixed it in the kind checker rather than the subsequent validity check, (a) so that the error messages look more uniform, and (b) so that I did not need to meddle with isPredTy. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 07:20:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 07:20:08 -0000 Subject: [GHC] #9196: Higher-rank constraint treated as type instead In-Reply-To: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> References: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> Message-ID: <062.0d37bc394213211dacea7ad1002842d3@haskell.org> #9196: Higher-rank constraint treated as type instead ------------------------------------------------+-------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: typecheck/should_fail/T9196 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonpj): * status: patch => closed * testcase: => typecheck/should_fail/T9196 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 07:22:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 07:22:19 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.3b2b33f3c211de573f775f1e26925cde@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: stranal/should_compile/T9208 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => merge Comment: Fix is above. Merge to 7.8 when it's next convenient. Luite: yell if you really, really need this in 7.8.3. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 09:30:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 09:30:40 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.dfcb39412d7cfbf400659da5160ab7b5@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------ Reporter: nh2 | Owner: 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 | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by duncan): Oh, and the other thing my design relies on is the "cache" always being up to date. GHC will only read the binary cache file and never read any of the .conf files. (I've not checked if this was already the case or not.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 12:41:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 12:41:57 -0000 Subject: [GHC] #9214: UNPACK support for sum types In-Reply-To: <047.5213ff1d75a2abd5ff04d6c7bb79813f@haskell.org> References: <047.5213ff1d75a2abd5ff04d6c7bb79813f@haskell.org> Message-ID: <062.dae9f6a085b9dd3f4a2688f069e4f8ce@haskell.org> #9214: UNPACK support for sum types -------------------------------------+------------------------------------ Reporter: mojojojo | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by schyler): Smells fishy to me. Would create a pwr(N,2) number of denormalizations. Would be better to calculate the largest size of the fully unpacked type like a C compiler would for unions. o/t The behaviour of the trac for n^2 notation is really annoying! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 12:46:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 12:46:34 -0000 Subject: [GHC] #9214: UNPACK support for sum types In-Reply-To: <047.5213ff1d75a2abd5ff04d6c7bb79813f@haskell.org> References: <047.5213ff1d75a2abd5ff04d6c7bb79813f@haskell.org> Message-ID: <062.fc38c79f5e1cc207d53e8392cfc3e72d@haskell.org> #9214: UNPACK support for sum types -------------------------------------+------------------------------------ Reporter: mojojojo | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): It's even more complicated than just allocating the max needed by any of the unpacked sum type's constructor. The GC needs to know what the fields are in any given constructor to be able to GC correctly. I don't think this will be hard (that's why we haven't done it already). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 13:14:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 13:14:57 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.ef089692caa3af65f181ba876d8fb41e@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile ----------------------------------------------+---------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8634 ----------------------------------------------+---------------------------- Comment (by augustss): The documentation says 'Both the Paterson Conditions and the Coverage Condition are lifted if you give the -XUndecidableInstances flag'. This doesn't seem to be the case. And why does it matter that x is free? Can't it just be assumed to be universally quantified? It would be nice to get back whatever behaviour the old ghc had, because it did the right thing for this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 14:10:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 14:10:59 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.bc89662b52d05ec855a3e0b5a99f161b@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: stranal/should_compile/T9208 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by luite): Thanks for the fix. I have a workaround, so for me it's not essential for it to be in 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 14:52:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 14:52:09 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.136c092bba2cf51792e071e3c195a46c@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile ----------------------------------------------+---------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8634 ----------------------------------------------+---------------------------- Comment (by simonpj): Would anyone who knows or cares about functional dependencies like to look into this? Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 16:24:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 16:24:35 -0000 Subject: [GHC] #8897: Can't change "Full Name" in preferences In-Reply-To: <050.cac5fdb9d34ae50c72ea407a1870d09e@haskell.org> References: <050.cac5fdb9d34ae50c72ea407a1870d09e@haskell.org> Message-ID: <065.baa942d50e59827d6c44bcf1e8df82fc@haskell.org> #8897: Can't change "Full Name" in preferences -------------------------------------+------------------------------------ Reporter: novadenizen | Owner: hvr Type: bug | Status: new Priority: lowest | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thomie): This is a [http://trac-hacks.org/ticket/10910 bug] in the AccountManagerPlugin for Trac. It looks like it will be [http://trac- hacks.org/browser/accountmanagerplugin/trunk/changelog?rev=12689#L10 fixed] in the next release (0.5). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 19:21:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 19:21:38 -0000 Subject: [GHC] #8667: sync-all doesn't work properly if you run from a fork on github In-Reply-To: <046.9085bad8b794dc6ebf21080eed03b8f6@haskell.org> References: <046.9085bad8b794dc6ebf21080eed03b8f6@haskell.org> Message-ID: <061.b3239896238460f2942a327c6a47324f@haskell.org> #8667: sync-all doesn't work properly if you run from a fork on github -------------------------------------+------------------------------------ Reporter: schyler | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Resolution: duplicate | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thomie): * keywords: => sync-all * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #8379. Please reopen that one if you're still having problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 19:22:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 19:22:44 -0000 Subject: [GHC] #8379: sync-all broken when using the GitHub mirror In-Reply-To: <044.114df031cf2877f0c03690bd4ee1bfc8@haskell.org> References: <044.114df031cf2877f0c03690bd4ee1bfc8@haskell.org> Message-ID: <059.ae225f776362402c934d2ad55f46dc27@haskell.org> #8379: sync-all broken when using the GitHub mirror -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8667 -------------------------------------+------------------------------------ Changes (by thomie): * related: => #8667 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 19:34:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 19:34:58 -0000 Subject: [GHC] #8146: Library package cannot be found In-Reply-To: <047.ab87e5fa73e44b237e8d12b333309a34@haskell.org> References: <047.ab87e5fa73e44b237e8d12b333309a34@haskell.org> Message-ID: <062.52aeda4120df3a060d6eab5f9e32ae7f@haskell.org> #8146: Library package cannot be found ------------------------------------------+-------------------------------- Reporter: conradwt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: This should be fixed by b755c7bd6af9f2bee47427b1eaa6c29c72b2b17a and later commits. See also #8824. Please reopen if you're still having problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 19:36:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 19:36:43 -0000 Subject: [GHC] #8146: Library package cannot be found In-Reply-To: <047.ab87e5fa73e44b237e8d12b333309a34@haskell.org> References: <047.ab87e5fa73e44b237e8d12b333309a34@haskell.org> Message-ID: <062.01ca487efdd96ad46f2fb1c64b75d7bb@haskell.org> #8146: Library package cannot be found -------------------------------------+------------------------------------ Reporter: conradwt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8824 -------------------------------------+------------------------------------ Changes (by thomie): * keywords: => sync-all * failure: Installing GHC failed => None/Unknown * version: 7.6.3 => * component: Compiler => Trac & Git * related: => #8824 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 19:42:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 19:42:53 -0000 Subject: [GHC] #8983: sync-all get should respect branches In-Reply-To: <045.2387548a5134286050979bbad60135c3@haskell.org> References: <045.2387548a5134286050979bbad60135c3@haskell.org> Message-ID: <060.1a74379dd96ae9e491db405c76a50ef1@haskell.org> #8983: sync-all get should respect branches -------------------------------------+------------------------------------ Reporter: ezyang | Owner: hvr Type: bug | Status: new Priority: low | Milestone: Component: Trac & Git | Version: 7.9 Resolution: | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thomie): * keywords: => sync-all * owner: => hvr * component: Build System => Trac & Git -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 19:44:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 19:44:40 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.9c0169a86a01862b0d2e43abd090e883@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------ Reporter: nh2 | Owner: 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 | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): When using the new DB format, GHC only reads the cache and not the individual `.conf` files, so you're ok on that front. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 20:35:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 20:35:06 -0000 Subject: [GHC] #8369: Small improvements to ./sync-all In-Reply-To: <042.c6240151f5790c94f3ab310253d6a72c@haskell.org> References: <042.c6240151f5790c94f3ab310253d6a72c@haskell.org> Message-ID: <057.d15b0ead0972ef9319503e51414bcca8@haskell.org> #8369: Small improvements to ./sync-all -------------------------------------+------------------------------------ Reporter: nwf | Owner: hvr Type: bug | Status: new Priority: lowest | Milestone: Component: Trac & Git | Version: 7.7 Resolution: | Keywords: sync-all Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thomie): Can this ticket be closed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 23:21:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 23:21:50 -0000 Subject: [GHC] #8379: sync-all broken when using the GitHub mirror In-Reply-To: <044.114df031cf2877f0c03690bd4ee1bfc8@haskell.org> References: <044.114df031cf2877f0c03690bd4ee1bfc8@haskell.org> Message-ID: <059.7a88d824a40d04f588aebd88c9dbba49@haskell.org> #8379: sync-all broken when using the GitHub mirror -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8667 -------------------------------------+------------------------------------ Changes (by thomie): * status: closed => new * resolution: invalid => Comment: Since more people seem to run into this, someone please update the README. I added a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 20 23:22:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jun 2014 23:22:13 -0000 Subject: [GHC] #8379: sync-all broken when using the GitHub mirror In-Reply-To: <044.114df031cf2877f0c03690bd4ee1bfc8@haskell.org> References: <044.114df031cf2877f0c03690bd4ee1bfc8@haskell.org> Message-ID: <059.562844bd6160085bb3f6331099aa80bd@haskell.org> #8379: sync-all broken when using the GitHub mirror -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8667 -------------------------------------+------------------------------------ Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 00:29:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 00:29:20 -0000 Subject: [GHC] #8886: sync-all: END actions result in confusing error message In-Reply-To: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> References: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> Message-ID: <056.513f9ae28a7460787e2e23fdb6b49370@haskell.org> #8886: sync-all: END actions result in confusing error message -------------------------------+------------------------------------------- Reporter: fw | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: sync-all Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thomie): * status: closed => new * component: Build System => Trac & Git * owner: => hvr * failure: Building GHC failed => None/Unknown * keywords: => sync-all * resolution: fixed => Comment: This commit should be reverted IMHO. The idea of using the `END` block, if I understand correctly, is that it should run at the end, no matter what else happens. For example the change back to the `initial_working_directory` should not be skipped in case of errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 00:37:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 00:37:45 -0000 Subject: [GHC] #8886: sync-all: END actions result in confusing error message In-Reply-To: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> References: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> Message-ID: <056.345751f775eea9f605ca9973be28c0ce@haskell.org> #8886: sync-all: END actions result in confusing error message -------------------------------+------------------------------------------- Reporter: fw | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: sync-all Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thomie): * status: new => patch Comment: The false warning is also triggered when running a different `sync-all` command before the first succesful `sync-all get`, for example if one runs (for whatever reason): git clone git://github.com/ghc/ghc cd ghc ./sync-all -r http://git.haskell.org remote set-url origin The attached patch proposes a solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 02:37:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 02:37:45 -0000 Subject: [GHC] #9222: Unexpected DataKind Panic Message-ID: <045.cffc02ed4ea68b3271b743a554574855@haskell.org> #9222: Unexpected DataKind Panic -------------------------------------------+------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Here's a simplified version of a panic I'm getting: {{{ {-# LANGUAGE RankNTypes, GADTs, DataKinds, PolyKinds, TypeOperators, TypeFamilies #-} import Data.Proxy data Want :: (i,j) -> * where Want :: (a ~ '(b,c) => Proxy b) -> Want a }}} {{{ GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-apple-darwin): tcTyVarDetails k{tv aAv} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 05:01:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 05:01:30 -0000 Subject: [GHC] #9222: Unexpected DataKind Panic In-Reply-To: <045.cffc02ed4ea68b3271b743a554574855@haskell.org> References: <045.cffc02ed4ea68b3271b743a554574855@haskell.org> Message-ID: <060.ad81672d18411fde3e90ba721ae89d10@haskell.org> #9222: Unexpected DataKind Panic --------------------------------------------+------------------------------ Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by ekmett): If I fix up the quantifiers then the panic goes away, but the 'impossible' shouldn't happen, nonetheless. ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 07:42:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 07:42:19 -0000 Subject: [GHC] #9154: Links to Cabal documentation from the user guide are broken In-Reply-To: <046.fc5b062da2d1072804978e34c9b0db1c@haskell.org> References: <046.fc5b062da2d1072804978e34c9b0db1c@haskell.org> Message-ID: <061.70b1675c9b9c5c345b30f7e34193b6ef@haskell.org> #9154: Links to Cabal documentation from the user guide are broken -------------------------------------+------------------------------------ Reporter: etrepum | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 08:02:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 08:02:20 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.e00d301faae4cefcd3fe746a2907b149@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) ----------------------------+---------------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi | Difficulty: Moderate (less than a day) crash | Blocked By: Test Case: | Related Tickets: Blocking: | ----------------------------+---------------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 08:19:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 08:19:33 -0000 Subject: [GHC] #9223: Type equality makes type variable untouchable Message-ID: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> #9223: Type equality makes type variable untouchable -------------------------------------------+------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- This doesn't look right: {{{ {-# LANGUAGE RankNTypes, TypeFamilies #-} type family TF (m :: * -> *) run1 :: (forall m . Monad m => m a) -> a run1 = undefined run2 :: (forall m . (Monad m, TF m ~ ()) => m a) -> a run2 = undefined -- this works x1 = run1 (return ()) -- this fails x2 = run2 (return ()) {- Couldn't match expected type ?a? with actual type ?()? ?a? is untouchable inside the constraints (Monad m, TF m ~ ()) bound by a type expected by the context: (Monad m, TF m ~ ()) => m a at untouchable.hs:15:6-21 ?a? is a rigid type variable bound by the inferred type of x2 :: a at untouchable.hs:15:1 Relevant bindings include x2 :: a (bound at untouchable.hs:15:1) In the first argument of ?return?, namely ?()? In the first argument of ?run2?, namely ?(return ())? -} }}} I would expect x2 to type check just like x1 does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 08:21:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 08:21:29 -0000 Subject: [GHC] #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory In-Reply-To: <051.c7c74d65a5ac5256959953ba2081bc0a@haskell.org> References: <051.c7c74d65a5ac5256959953ba2081bc0a@haskell.org> Message-ID: <066.3aabf3f52db4dd3a07ca52eb6dd746a6@haskell.org> #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory -------------------------------+------------------------------------------- Reporter: | Owner: configurator | Status: patch Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 08:29:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 08:29:42 -0000 Subject: [GHC] #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X In-Reply-To: <043.14751a04063e97452853ca5e57a712e1@haskell.org> References: <043.14751a04063e97452853ca5e57a712e1@haskell.org> Message-ID: <058.e9b6685917e0674915a326ed0d9b4048@haskell.org> #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X -----------------------------------+------------------------------------ Reporter: kseo | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 09:44:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 09:44:02 -0000 Subject: [GHC] #9224: Add support for binary integer literals Message-ID: <042.1a89d47aeeec7e7c411448001a06492c@haskell.org> #9224: Add support for binary integer literals -------------------------------------------+------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Parser) | Version: Keywords: literals | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Currently, Haskell98/2010 support base-10, base-8 (via `0[oO]`-prefix) and base-16 (via `0[xX]`-prefix) integer literals. I hereby propose to add conditional support for base-2 integers via a `0[bB]`-prefix, controlled via a new `-XBinaryLiterals` language extension flag/pragma. The change to the lexer is trivial (see attached patch), however I'm stuck on the lexer using a 32-bit feature-mask, of which all 32bits are already taken, and I'd need a 33th bit for the `BinaryLiteralsBit` flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 09:52:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 09:52:27 -0000 Subject: [GHC] #9224: Add support for binary integer literals In-Reply-To: <042.1a89d47aeeec7e7c411448001a06492c@haskell.org> References: <042.1a89d47aeeec7e7c411448001a06492c@haskell.org> Message-ID: <057.c954a67c963d4c5d32998ab2deb7c135@haskell.org> #9224: Add support for binary integer literals -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: (Parser) | Keywords: literals Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by hvr): Initial patch (sans the language-extension) pushed to https://phabricator.haskell.org/D22 for review -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 11:56:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 11:56:28 -0000 Subject: [GHC] #9212: Cleanup of sync-all In-Reply-To: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> References: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> Message-ID: <060.08d02437b97ef3ab4386cf966b594bbf@haskell.org> #9212: Cleanup of sync-all -------------------------------------+------------------------------------ Reporter: thomie | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thomie): Concerning patch `0003-Delete-dead-code.patch`, also see this mailinglist [http://www.haskell.org/pipermail/ghc-devs/2013-August/002096.html reply]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 15:33:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 15:33:57 -0000 Subject: [GHC] #9211: Untouchable type variable (regression from 7.6) In-Reply-To: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> References: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> Message-ID: <061.058acc45eddf900263ddbdb69e3c5020@haskell.org> #9211: Untouchable type variable (regression from 7.6) -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by oleg): Indeed I use the equality constraint to essentially let-bind a type variable, which is quite handy. I'm glad to hear that it is also easy to implement. I, too, am curious what Dimitrios thinks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 17:00:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 17:00:55 -0000 Subject: [GHC] #9197: FFI types should be usable in foreign import decls without revealing representations In-Reply-To: <045.1e66fe66ff436f9c3e1f990da91bd5b9@haskell.org> References: <045.1e66fe66ff436f9c3e1f990da91bd5b9@haskell.org> Message-ID: <060.51f3132582ffcbd8fcd8c6f35cc4b99f@haskell.org> #9197: FFI types should be usable in foreign import decls without revealing representations -------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by duncan): I suspect it does have something to do with `CTYPE`. I looked at the code for that a bit. It's clear that it associates a string (representing a C type) with a Haskell type to use in FFI generated headers. I couldn't immediately tell if it also does anything for declaring it as one of the known FFI types, but I suspect not. It may well be quite reasonable to give the `CTYPE` pragma the extra duty of allowing looking through newtypes, rather than using a builtin list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 17:43:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 17:43:09 -0000 Subject: [GHC] #9161: Pattern synonyms interact badly with data kinds In-Reply-To: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> References: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> Message-ID: <066.e10bf2adbb8b055d18b93939a999af31@haskell.org> #9161: Pattern synonyms interact badly with data kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: merge Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: renamer, pattern Resolution: | synonyms, data kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile-time | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 21 17:43:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jun 2014 17:43:36 -0000 Subject: [GHC] #9161: Pattern synonyms interact badly with data kinds In-Reply-To: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> References: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> Message-ID: <066.4a0f1ac01ba69bc9c8daea678430ab8a@haskell.org> #9161: Pattern synonyms interact badly with data kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: merge Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: renamer, pattern Resolution: | synonyms, data kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile-time | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by cactus): Fixed using Simon's approach #1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 22 05:39:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jun 2014 05:39:50 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.9dc60b20527572b1540e3eb29f16fa3e@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by ekmett): * cc: ekmett@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 22 11:22:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jun 2014 11:22:20 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.1bfde0b97299e6f5e286d64308c12a3f@haskell.org> #9023: Error when using empty record update on binary pattern synonym ------------------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Test Case: patsyn/should_compile/T9023 | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by cactus): After fixing the conflicts, I've pushed a version on top of `ghc-7.8` as `wip/T9023`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 22 12:31:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jun 2014 12:31:19 -0000 Subject: [GHC] #8886: sync-all: END actions result in confusing error message In-Reply-To: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> References: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> Message-ID: <056.06a0c855526e87d9c33f7bc164bb3917@haskell.org> #8886: sync-all: END actions result in confusing error message -------------------------------+------------------------------------------- Reporter: fw | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: sync-all Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by fw): Replying to [comment:4 thomie]: > The idea of using the `END` block, if I understand correctly, is that it should run at the end, no matter what else happens. For example the change back to the `initial_working_directory` should not be skipped in case of errors. If the script dies with an error, the process is probably in a slightly broke state, and printing all those warnings only obscures the error. Changing the directory does not in itself have any effect because the process is about to terminate anyway, and its not the point of the `END` action. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 22 12:53:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jun 2014 12:53:40 -0000 Subject: [GHC] #8886: sync-all: END actions result in confusing error message In-Reply-To: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> References: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> Message-ID: <056.15e449a2ade8195053dc0c4cc30c858b@haskell.org> #8886: sync-all: END actions result in confusing error message -------------------------------+------------------------------------------- Reporter: fw | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: sync-all Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by thomie): Ok, you're right that changing the directory is not needed. But one thing I don't understand: why are those checks in the `END` block, if not for running even on an error. Wouldn't they be better placed straight in the main function then? Would make things simpler. I guess the author of those old repository checks in the `END` block thought about potential errors that could occur, and deemed it necessary to show those warnings. Yes it obscures the initial error, but maybe that error is caused by having an old repository in the first place. The bug that still stands is getting false warnings about old time library being present when running another command before `sync-all get`. My patch fixes that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 22 15:50:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jun 2014 15:50:26 -0000 Subject: [GHC] #9224: Add support for binary integer literals In-Reply-To: <042.1a89d47aeeec7e7c411448001a06492c@haskell.org> References: <042.1a89d47aeeec7e7c411448001a06492c@haskell.org> Message-ID: <057.e8f12802386408d7788d343c16da7e5a@haskell.org> #9224: Add support for binary integer literals -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: (Parser) | Keywords: literals Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Description changed by hvr: Old description: > Currently, Haskell98/2010 support base-10, base-8 (via `0[oO]`-prefix) > and base-16 (via `0[xX]`-prefix) integer literals. > > I hereby propose to add conditional support for base-2 integers via a > `0[bB]`-prefix, controlled via a new `-XBinaryLiterals` language > extension flag/pragma. The change to the lexer is trivial (see attached > patch), however I'm stuck on the lexer using a 32-bit feature-mask, of > which all 32bits are already taken, and I'd need a 33th bit for the > `BinaryLiteralsBit` flag. New description: Haskell2010 supports - base-10 (prefix-less), - base-8 (via `0[oO]`-prefix), and - base-16 (via `0[xX]`-prefix) integer literals. I hereby propose to add conditional support for base-2 integers literals via a `0[bB]`-prefix, disabled by default, and controllable via a new `{-# LANGUAGE BinaryLiterals #-}` language extension flag/pragma. The use of a `0b` prefix for indicating binary literals is known from popular programming languages such as Python, Ruby, and Java. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 22 16:30:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jun 2014 16:30:19 -0000 Subject: [GHC] #9225: Missing syntax error for package qualified import with version number Message-ID: <045.491fa452f637375b8cf3acd2fe942041@haskell.org> #9225: Missing syntax error for package qualified import with version number -------------------------+------------------------------------------------- Reporter: | Owner: ezyang ezyang | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler (Parser) | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Consider the following test file: {{{ {-# LANGUAGE PackageImports #-} module Foo where import "containers-0.5.0.0" Data.Map }}} where we have {{{ ezyang at sabre:~$ ghc-pkg list | grep containers containers-0.5.0.0 unordered-containers-0.2.3.0 }}} GHC will fail to compile this, but in an unusual way: {{{ ezyang at sabre:~$ ghc test.hs [1 of 1] Compiling Foo ( test.hs, test.o ) test.hs:3:1: Failed to load interface for `Data.Map' It is not a module in the current program, or in any known package. }}} That's misleading: the real reason the import failed is because this is a package qualified import (not package ID qualified imports). For my purposes, it would be useful to also support package ID imports, but in the meantime, it would be a good idea to run Cabal's syntax check on the package name, which requires every hyphenated component to contain an alphabetic character. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 22 17:33:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jun 2014 17:33:36 -0000 Subject: [GHC] #9176: GHC not generating dyn_hi files In-Reply-To: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> References: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> Message-ID: <062.cdfc2282b02b5205e86073f738430565@haskell.org> #9176: GHC not generating dyn_hi files -----------------------------+---------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: dynamic Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by heatsink): The dyn_hi file goes missing because GHC detects a bad module interface hash and disables dynamic-too. It's disabled in `findAndReadIface` by assigning False to `canGenerateDynamicToo`. That flag stops `hscWriteIface` from writing a dyn_hi file. GHC will print diagnostic messages if it's run with `-ddump-if-trace`, so you can see this happening. IMO, this condition should be an error because GHC does not generate the file it was told to generate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 22 18:08:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jun 2014 18:08:50 -0000 Subject: [GHC] #9212: Cleanup of sync-all In-Reply-To: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> References: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> Message-ID: <060.772e05333995a3e0ea2fd9bf77c6fa37@haskell.org> #9212: Cleanup of sync-all -------------------------------------+------------------------------------ Reporter: thomie | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thomie): Patch 4.5 should be applied before (the improved) patch 5. Both patches fix bugs. See the commit messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 22 20:36:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jun 2014 20:36:21 -0000 Subject: [GHC] #8886: sync-all: END actions result in confusing error message In-Reply-To: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> References: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> Message-ID: <056.eed2dd4b02dee960a082a8c577f04885@haskell.org> #8886: sync-all: END actions result in confusing error message -------------------------------+------------------------------------------- Reporter: fw | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: sync-all Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by fw): Replying to [comment:7 thomie]: > Ok, you're right that changing the directory is not needed. > > But one thing I don't understand: why are those checks in the `END` block, if not for running even on an error. Wouldn't they be better placed straight in the main function then? Probably, I don't understand they way the script is written. I have seen some Perl in my day, and this usage of `BEGIN` (for argument parsing, of all) and `END` blocks seemed highly suspect to me. I didn't want to audit the code for any forms of non-local control flow, so I put in just the exception check as a minimal, less risky change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 22 23:29:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jun 2014 23:29:53 -0000 Subject: [GHC] #9226: Internal error when using equality constraint in pattern synonyms Message-ID: <051.9ff7e888b2f688be0dafb9aefbac40b9@haskell.org> #9226: Internal error when using equality constraint in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.8.2 Keywords: renamer, pattern | Operating System: Linux synonyms, GADTs | Type of failure: GHC rejects Architecture: x86 | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- While going through [http://www.andres-loeh.de/dgp2005.pdf Extensible datatypes] I had the following code: {{{ {-# LANGUAGE GADTs, PatternSynonyms, ScopedTypeVariables, Rank2Types #-} data Rep a where RUnit :: Rep () RInt :: Rep Int RChar :: Rep Char REither :: Rep a -> Rep b -> Rep (Either a b) RPair :: Rep a -> Rep b -> Rep (a, b) foo :: (Rep a, a) -> Bool foo (RUnit, ()) = True }}} And I wanted to make a pattern synonyms matching `(RUnit, ())` in `foo`, my initial attempt was: {{{ pattern PUnit1 = (RUnit, ()) }}} gives the error (`punit1.log`) while writing {{{ pattern PUnit2 = (RUnit, ()) :: (Rep (), ()) }}} compiles but can't be used in `foo`. Trying: {{{ pattern PUnit3 = (RUnit, ()) :: (a ~ ()) => (Rep a, a) }}} gives a ''GHC internal error'' (`punit3.log`). I tried various other patterns such as: {{{ pattern PUnit4 <- (RUnit, ()) pattern PUnit5 <- (RUnit, ()) :: (Rep (), ()) pattern PUnit6 <- (RUnit, ()) :: (a ~ ()) => (Rep a, a) pattern PUnit7 = (RUnit, ()) :: forall a. (a ~ ()) => (Rep a, a) pattern PUnit8 <- (RUnit, ()) :: forall a. (a ~ ()) => (Rep a, a) ... }}} None of which work. The final goal was to rewrite: {{{ eq :: Rep a -> a -> a -> Bool eq rep a b = case (rep, a, b) of (RUnit, (), ()) -> True (RInt, n1, n2) -> n1 == n2 (RChar, c1, c2) -> c1 == c2 (REither l r, Left a, Left b) -> eq l a b (REither l r, Right a, Right b) -> eq r a b (REither{}, _, _) -> False (RPair l r, (a1, a2), (b1, b2)) -> eq l a1 b1 && eq r a2 b2 }}} as something like {{{ pattern PUnit = (RUnit, ()) -- (a ~ ()) => (Rep a, a) pattern PInt n = (RInt, n) -- (a ~ Int) => (Rep a, a) -- ... eq :: Rep a -> a -> a -> Bool eq rep a b = case ((rep, a), (rep, b)) of (PUnit, PUnit) -> True (PInt n1, PInt n2) -> n1 == n2 (PChar c1, PChar c2) -> c1 == c2 (PLeft l l1, PLeft l l2) -> eq l l1 l2 (PRight r r1, PRight r r2) -> eq r r1 r2 ((REither{}, _), _) -> False (PFst l (a1, b1), PSnd r (a2, b2)) -> eq l a1 b1 && eq r a2 b2 }}} where one can avoid pattern matching against the `Rep` constructor directly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 02:35:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 02:35:39 -0000 Subject: [GHC] #9223: Type equality makes type variable untouchable In-Reply-To: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> References: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> Message-ID: <063.2afb484dc16cd89e21ff89b994ac6766@haskell.org> #9223: Type equality makes type variable untouchable --------------------------------------------+------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by goldfire): I'm a little confused about what's going on about the core complaint, but, tangentially, it seems to me that calling `a` a "rigid type variable" is wrong here. Isn't `a` a metavariable, especially if it's untouchable? I should say that blindly following the rules from !OutsideIn about untouchable variables does lead me to a place of unifying `m a` with `m ()` where `a` is untouchable. But, something is still fishy about it that I can't quite pin down. In other cases, when something is untouchable, I can construct a way in which the type in question is not a principal type... and I can't quite do this here, hence my confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 05:53:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 05:53:59 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.dbb5b2b02d36ddc64f132b115ea59a2f@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: stranal/should_compile/T9208 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): There is something wrong with the test case. With `-DDEBUG`, I get {{{ Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20140622 for x86_64-unknown-linux): ASSERT failed! file compiler/codeGen/StgCmmExpr.hs, line 643 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T9208(optasm) }}} (full log at https://s3.amazonaws.com/archive.travis- ci.org/jobs/28166586/log.txt) while it worked without `-DDEBUG`. (Didn?t look into it deeper. Greetings from OPLSS! :-)) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 05:57:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 05:57:07 -0000 Subject: [GHC] #9115: The kind of (=>) In-Reply-To: <047.79a80bb2b897dcc6ec2d89a1e91dba60@haskell.org> References: <047.79a80bb2b897dcc6ec2d89a1e91dba60@haskell.org> Message-ID: <062.125214ba5719b0effde0fde39c19364b@haskell.org> #9115: The kind of (=>) -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ekmett): goldfire: Note: the latter is slightly weaker, since in Eq a => Show a => Read a => .. you can only reference backwards up the chain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 06:03:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 06:03:24 -0000 Subject: [GHC] #9212: Cleanup of sync-all In-Reply-To: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> References: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> Message-ID: <060.edf7e1ecef6214f8922c8d5d761ddc7f@haskell.org> #9212: Cleanup of sync-all -------------------------------------+------------------------------------ Reporter: thomie | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Do you have a git repo somewhere with these commits as a branch? Would make it a bit easier. And for some reason I miss a test suite for `sync-all` :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 06:28:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 06:28:15 -0000 Subject: [GHC] #9047: Testsuite fails on OS X Mavericks In-Reply-To: <047.0afe1c31b6584b760336c379b75efabc@haskell.org> References: <047.0afe1c31b6584b760336c379b75efabc@haskell.org> Message-ID: <062.b4728404fcdba39057d75a1d7b463cd0@haskell.org> #9047: Testsuite fails on OS X Mavericks ---------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"b84748121e777d098198f2583d11a9424c1b1650/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b84748121e777d098198f2583d11a9424c1b1650" Fix #9047 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 06:54:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 06:54:24 -0000 Subject: [GHC] #9047: Testsuite fails on OS X Mavericks In-Reply-To: <047.0afe1c31b6584b760336c379b75efabc@haskell.org> References: <047.0afe1c31b6584b760336c379b75efabc@haskell.org> Message-ID: <062.a4496876f109bc6934f5cd9c0e5b0162@haskell.org> #9047: Testsuite fails on OS X Mavericks ---------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Test Suite | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 07:04:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 07:04:50 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.c764b4cbef235e0e78d41e5d8d051285@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: stranal/should_compile/T9208 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): No, there's nothing wrong with the test case, but I should have commented on it. There really is a terrible bug in the program: it takes the value `()`, unsafely casts it to a function, and applies it. As it happens the ASSERT in `StgCmmExpr` can see this happening, and complains. (But a slightly more complicated example might conceal the problem.) So something bizarre is going to happen, but that's what the programmer asked for. In general GHC should never crash, no matter how bizarre the program. You could argue for a civilised error messaage. Or you could argue to remove the ASSERT. But I don't want to spend precious cycles thinking about programs that are wrong anyway. The strongest case for doing something is that building stage-2 with `-DDEBUG` is really a good plan for flushing out latent bugs, but this test will make it look as if there is a failure. I'm open to suggestions about how to fix that. Perhaps the best way would be to switch on `CmmLint` as well as `-DDEBUG`, and make sure `CmmLint` detects this particular problem. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 07:39:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 07:39:04 -0000 Subject: [GHC] #9096: GADT definition not accepted in prefix notation In-Reply-To: <047.0e9543e62d37f36829980e750c64d3ad@haskell.org> References: <047.0e9543e62d37f36829980e750c64d3ad@haskell.org> Message-ID: <062.087c3a13979ae4a2901a7c079fb57795@haskell.org> #9096: GADT definition not accepted in prefix notation -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 07:39:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 07:39:09 -0000 Subject: [GHC] #9128: Possible bug in strictness analyzer when where clause declared NOINLINE In-Reply-To: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> References: <045.8dea957b51c7cd8d8c62cc72c4b20d78@haskell.org> Message-ID: <060.206f553c83ca53878a6c979ca725a040@haskell.org> #9128: Possible bug in strictness analyzer when where clause declared NOINLINE -------------------------------------+------------------------------------- Reporter: aalevy | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: strictness Operating System: Linux | bytestring Type of failure: Runtime crash | Architecture: x86_64 (amd64) Test Case: | Difficulty: Unknown simplCore/should_run/T9128 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 07:39:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 07:39:16 -0000 Subject: [GHC] #9061: Warnings for redundant imports doesn't take name shadowing into account (Regression) In-Reply-To: <047.b503cfbcf30b76a6eb3638265399e795@haskell.org> References: <047.b503cfbcf30b76a6eb3638265399e795@haskell.org> Message-ID: <062.2d7964d83cf3887ca757cce1917cc609@haskell.org> #9061: Warnings for redundant imports doesn't take name shadowing into account (Regression) -------------------------------------------------+------------------------- Reporter: bergmark | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.3 Resolution: fixed | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | Unknown/Multiple Test Case: module/T9061 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 07:39:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 07:39:17 -0000 Subject: [GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap In-Reply-To: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> References: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> Message-ID: <062.e7c580cbd815a804376496f552f425e6@haskell.org> #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 07:53:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 07:53:54 -0000 Subject: [GHC] #9223: Type equality makes type variable untouchable In-Reply-To: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> References: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> Message-ID: <063.ab0a75cbbe168ead66ff326b2cecb827@haskell.org> #9223: Type equality makes type variable untouchable --------------------------------------------+------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): GHC is being schizophrenic about an interesting design choice here. The issue is this. When typechecking `x2`'s RHS, we assume that the RHS has type `alpha`, for some fresh unification variable `alpha`, and generate constraints from the RHS, giving the constraint: {{{ forall m. (Monad m, TF m ~ ()) -- Comes from run2's type => (m alpha ~ m (), -- Matching result of (return ()) with expected type (m alpha) Monad m) -- Call of return }}} That leads to the constraint `(alpha ~ ())`, but underneath an implication constraint that has an equality (like a GADT) in it. So !OutsideIn refrains from unifying `alpha`. Then GHC tries to infer a type for `x2` anyway, getting (essentially) {{{ x2 :: forall a. (a ~ ()) => a }}} where we have decided to quantify over `alpha` to `a`. Finally we end up reporting the insoluble constraint `(a ~ alpha)`. So the question is: what error message would you like to see? This "untouchable" stuff is a bit disconcerting, so we could say this: {{{ Couldn't match expected type ?a? with actual type ?()? ?a? is a rigid type variable bound by the inferred type of x2 :: forall a. a at untouchable.hs:15:1 Relevant bindings include x2 :: a (bound at untouchable.hs:15:1) In the first argument of ?return?, namely ?()? In the first argument of ?run2?, namely ?(return ())? }}} Here you get to see the inferred type of `x2`. (Side note: actually GHC currently prints `the inferred type of x2 :: a`, suppressing the `forall`, but in this context I suspect we should print the `forall` regardless of `-fprint-explicit-foralls`. I'll make that change anyway unless anyone yells.) A merit of this error message is that if you, the programmer, give `x2` that type signature `x2 :: forall a. a`, then indeed that is very much the message that you'll get. But I suppose it leaves open the question of '''why''' GHC inferred that type for `x2`. Alternatively we could give you {{{ Couldn't match expected type ?a? with actual type ?()? ?a? is untouchable inside the constraints (Monad m, TF m ~ ()) bound by a type expected by the context: (Monad m, TF m ~ ()) => m a at untouchable.hs:15:6-21 Relevant bindings include x2 :: a (bound at untouchable.hs:15:1) In the first argument of ?return?, namely ?()? In the first argument of ?run2?, namely ?(return ())? }}} which perhaps exposes a bit more of the mechanism of !OutsideIn, and has the merit of displayin the constraint(s) that make it untouchable. Which would you prefer? Currently GHC displays both, which I agree is confusing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 08:13:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 08:13:42 -0000 Subject: [GHC] #9226: Internal error when using equality constraint in pattern synonyms In-Reply-To: <051.9ff7e888b2f688be0dafb9aefbac40b9@haskell.org> References: <051.9ff7e888b2f688be0dafb9aefbac40b9@haskell.org> Message-ID: <066.627627a918c7d5d2b6946749d4142dac@haskell.org> #9226: Internal error when using equality constraint in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: renamer, pattern Operating System: Linux | synonyms, GADTs Type of failure: GHC rejects | Architecture: x86 valid program | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: cactus (added) Comment: You are absolutely right; there is a gaping hole in the pattern-synonym implementation. Gergo, the issue is this. When typechecking anything to do with GADTs, we need a type signature. The [wiki:PatternSynonyms wiki page] describes signatures for pattern synonyms, but they are not implemented. the `HsBinds.Sig` type has `PatSynSig`, but the parser does not recognise them, nor does the typechechecker do anything with them. Notably, in `tcPatSynDecl` we'll need to implement different code to ''check'' that the synonym has a specified type than to ''infer'' the type it has. While fixing this, I found another crash. This {{{ pattern PUnit1 = (RUnit, ()) :: (Rep a, a) }}} crashes with {{{ T9226.hs:15:38: GHC internal error: ?a? is not in scope during type checking, but it passed the renamer }}} Would you like to look at this Gergo? I'm happy to help. Meanwhile, iceland_jack, I think you're stalled till we do this. Thanks for reporting it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 08:19:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 08:19:50 -0000 Subject: [GHC] #9106: GHC Panic related to functional dependencies - kindFunResult In-Reply-To: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> References: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> Message-ID: <059.3f5b9935caa964623aacf542571f717a@haskell.org> #9106: GHC Panic related to functional dependencies - kindFunResult ---------------------------------------+--------------------------- Reporter: yuriy | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: polykinds/T9106 | Blocked By: Blocking: | Related Tickets: ---------------------------------------+--------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 08:25:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 08:25:56 -0000 Subject: [GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap In-Reply-To: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> References: <047.dada6418ea5f6bdcdd72b6896e8348f3@haskell.org> Message-ID: <062.fe25f88e529c95e58ea0ccbf40a41990@haskell.org> #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to HashMap --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by jstolarek): Perhaps it's also worth to resurrect the deleted Note? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 08:36:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 08:36:41 -0000 Subject: [GHC] #9226: Internal error when using equality constraint in pattern synonyms In-Reply-To: <051.9ff7e888b2f688be0dafb9aefbac40b9@haskell.org> References: <051.9ff7e888b2f688be0dafb9aefbac40b9@haskell.org> Message-ID: <066.cb9d59e1bbf139a8b634624c6eafc930@haskell.org> #9226: Internal error when using equality constraint in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: renamer, pattern Operating System: Linux | synonyms, GADTs Type of failure: GHC rejects | Architecture: x86 valid program | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8968 -------------------------------------+------------------------------------- Changes (by kosmikus): * related: => #8968 Comment: Also see #8968 for my own experiences trying to use pattern synonyms for GADTs and lots of discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 08:37:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 08:37:09 -0000 Subject: [GHC] #9227: Coverage Condition cannot be turned off Message-ID: <047.00cb6fa9fbf58c6b033bc498f885a9b9@haskell.org> #9227: Coverage Condition cannot be turned off ------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Compile this program {{{ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} module Bug1 where class C a b | a -> b data A a = A data B a = B instance C (A a) (B b) }}} and observe the error message {{{ Bug1.hs:9:10: Illegal instance declaration for `C (A a) (B b)' The coverage condition fails in class `C' for functional dependency: `a -> b' Reason: lhs type `A a' does not determine rhs type `B b' In the instance declaration for `C (A a) (B b)' }}} Then read manual, sec 7.6.3.3: {{{ Both the Paterson Conditions and the Coverage Condition are lifted if you give the -XUndecidableInstances flag }}} Compile again with -XUndecidableInstances. Observe the exact same error message. Either the compiler or the documentation is wrong. I certainly hope it is the compiler, because it worked in 7.6 and was quite useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 08:37:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 08:37:55 -0000 Subject: [GHC] #9226: Internal error when using equality constraint in pattern synonyms In-Reply-To: <051.9ff7e888b2f688be0dafb9aefbac40b9@haskell.org> References: <051.9ff7e888b2f688be0dafb9aefbac40b9@haskell.org> Message-ID: <066.a7fd473659674acad138790a01d1e575@haskell.org> #9226: Internal error when using equality constraint in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: renamer, pattern Operating System: Linux | synonyms, GADTs Type of failure: GHC rejects | Architecture: x86 valid program | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8968 -------------------------------------+------------------------------------- Comment (by Iceland_jack): The example wasn't anything serious so I can cope. Seeing how I've filed 4 reports about pattern synonyms in such a short time I seem to be abusing the extension somehow :) the response time here is jolly good, thank you for your efforts -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 08:42:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 08:42:41 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.d4673e6b230dbfe655ef20fd479c2945@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile ----------------------------------------------+---------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8634 ----------------------------------------------+---------------------------- Changes (by simonpj): * cc: dreixel, diatchki (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 08:45:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 08:45:47 -0000 Subject: [GHC] #9228: Internal compiler error with -O1 and -O2 Message-ID: <047.85eabab762dce9ba63253004f8d47fe4@haskell.org> #9228: Internal compiler error with -O1 and -O2 ------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Compiling a module gives the error message below. Sadly, I can't provide all the source code necessary to reproduce the problem since the code is proprietary. But maybe someone can find the bug given just the information that it exists. The module can be compiled with -O0, but not -O1 nor -O2. {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for i386-unknown-mingw32): StgCmmEnv: variable not found lvl44{v Xc7t} [lid] local binds for: main:Cortex.CM.CMVanilla.CMRawAPO.$fTypeableCMRawAPO{v r0} [gid[DFunId(nt)]] main:Cortex.CM.CMVanilla.CMRawAPO.$fTradeableCMRawAPO{v r1} [gid[DFunId]] main:Cortex.CM.CMVanilla.CMRawAPO.$fShowCMRawAPO{v r2} [gid[DFunId]] main:Cortex.CM.CMVanilla.CMRawAPO.$fReadCMRawAPO{v r3} [gid[DFunId]] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsVariantCMRawAPO{v r4} [gid[DFunId]] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO{v r5} [gid[DFunId]] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO{v r6} [gid[DFunId]] main:Cortex.CM.CMVanilla.CMRawAPO.weights{v rf} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.strikes{v rg} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.strikeIncludeds{v rh} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.settlementDates{v ri} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.quantoCcy{v rj} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.payoffTypes{v rk} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.notionals{v rl} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.nDigits{v rm} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.indexName{v rn} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.guaranteedFX{v ro} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.fixings{v rp} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.fixingQualifier{v rq} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.deliveryFixingSource{v rr} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.deliveryCcy{v rs} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.conversionDates{v rt} [gid[[RecSel]]] main:Cortex.CM.CMVanilla.CMRawAPO.$tCMRawAPO{v r7Ji} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$cCMRawAPO{v r7Nk} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$cgmapMo{v rcby} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$w$cgmapMo{v rdHg} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$cgmapMp{v rdHh} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$w$cgmapMp{v rdHi} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$cgmapM{v rdHj} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$w$cgmapM{v rdHk} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$cgmapQi{v rdHl} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$w$cgmapQi{v rdHm} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO1{v rdHn} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO2{v rdHo} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO3{v rdHp} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO4{v rdHq} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild{v rdHr} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO5{v rdHs} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO6{v rdHt} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO7{v rdHu} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO8{v rdHv} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go8{v rdHw} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO9{v rdHx} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO10{v rdHy} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild1{v rdHz} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv{v rdHA} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO11{v rdHB} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO12{v rdHC} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go1{v rdHD} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO13{v rdHE} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO14{v rdHF} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO15{v rdHG} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go2{v rdHH} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO16{v rdHI} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild2{v rdHJ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv1{v rdHK} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild3{v rdHL} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv2{v rdHM} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO17{v rdHN} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO18{v rdHO} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go3{v rdHP} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO19{v rdHQ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO20{v rdHR} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go4{v rdHS} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO21{v rdHT} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO22{v rdHU} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO23{v rdHV} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO24{v rdHW} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go5{v rdHX} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO25{v rdHY} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO26{v rdHZ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO27{v rdI0} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO28{v rdI1} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild4{v rdI2} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO29{v rdI3} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO30{v rdI4} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO31{v rdI5} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go6{v rdI6} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO32{v rdI7} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild5{v rdI8} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv3{v rdI9} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO33{v rdIa} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO34{v rdIb} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go7{v rdIc} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO35{v rdId} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO36{v rdIe} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO37{v rdIf} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go9{v rdIg} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO38{v rdIh} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO39{v rdIi} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO40{v rdIj} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild6{v rdIk} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO41{v rdIl} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO42{v rdIm} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO43{v rdIn} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go10{v rdIo} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO44{v rdIp} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild7{v rdIq} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv4{v rdIr} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO45{v rdIs} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO46{v rdIt} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go11{v rdIu} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO47{v rdIv} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO48{v rdIw} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO49{v rdIx} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go12{v rdIy} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO50{v rdIz} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO51{v rdIA} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO52{v rdIB} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild8{v rdIC} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO53{v rdID} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO54{v rdIE} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO55{v rdIF} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO56{v rdIG} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go13{v rdIH} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO57{v rdII} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO58{v rdIJ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild9{v rdIK} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv5{v rdIL} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO59{v rdIM} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO60{v rdIN} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go14{v rdIO} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO61{v rdIP} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO62{v rdIQ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO63{v rdIR} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go15{v rdIS} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO64{v rdIT} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO65{v rdIU} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild10{v rdIV} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO66{v rdIW} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO67{v rdIX} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO68{v rdIY} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go16{v rdIZ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO69{v rdJ0} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO70{v rdJ1} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO71{v rdJ2} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild11{v rdJ3} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO72{v rdJ4} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO73{v rdJ5} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO74{v rdJ6} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go17{v rdJ7} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO75{v rdJ8} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild12{v rdJ9} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv6{v rdJa} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO76{v rdJb} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO77{v rdJc} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go18{v rdJd} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO78{v rdJe} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO79{v rdJf} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO80{v rdJg} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go19{v rdJh} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO81{v rdJi} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO82{v rdJj} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild13{v rdJk} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv7{v rdJl} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO83{v rdJm} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO84{v rdJn} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go20{v rdJo} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO85{v rdJp} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO86{v rdJq} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO87{v rdJr} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go21{v rdJs} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO88{v rdJt} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO89{v rdJu} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild14{v rdJv} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv8{v rdJw} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild15{v rdJx} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv9{v rdJy} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO90{v rdJz} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO91{v rdJA} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go22{v rdJB} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO92{v rdJC} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO93{v rdJD} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go23{v rdJE} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO94{v rdJF} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO95{v rdJG} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO96{v rdJH} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go24{v rdJI} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO97{v rdJJ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO98{v rdJK} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO99{v rdJL} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild16{v rdJM} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO100{v rdJN} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO101{v rdJO} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO102{v rdJP} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go25{v rdJQ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO103{v rdJR} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild17{v rdJS} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv10{v rdJT} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO104{v rdJU} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO105{v rdJV} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go26{v rdJW} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO106{v rdJX} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO107{v rdJY} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO108{v rdJZ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go27{v rdK0} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$cgmapQ{v rdK1} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$cgmapQr{v rdK2} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$w$cgmapQr{v rdK3} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$cgmapQl{v rdK4} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$w$cgmapQl{v rdK5} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$cgmapT{v rdK6} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$w$cgmapT{v rdK7} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$cdataCast2{v rdK8} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$cdataCast1{v rdK9} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$cdataTypeOf{v rdKa} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO109{v rdKb} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO110{v rdKc} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO111{v rdKd} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$ctoConstr{v rdKe} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$cgunfold{v rdKf} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$w$cgunfold{v rdKg} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO112{v rdKh} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO113{v rdKi} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO114{v rdKj} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO115{v rdKk} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO116{v rdKl} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go28{v rdKm} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO117{v rdKn} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO118{v rdKo} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO119{v rdKp} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO120{v rdKq} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO121{v rdKr} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO122{v rdKs} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go29{v rdKt} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO123{v rdKu} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild18{v rdKv} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv11{v rdKw} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO124{v rdKx} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO125{v rdKy} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go30{v rdKz} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO126{v rdKA} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO127{v rdKB} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO128{v rdKC} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go31{v rdKD} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO129{v rdKE} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO130{v rdKF} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO131{v rdKG} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO132{v rdKH} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO133{v rdKI} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO134{v rdKJ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO135{v rdKK} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go32{v rdKL} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO136{v rdKM} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild19{v rdKN} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv12{v rdKO} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO137{v rdKP} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO138{v rdKQ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go33{v rdKR} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO139{v rdKS} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO140{v rdKT} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO141{v rdKU} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go34{v rdKV} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO142{v rdKW} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild20{v rdKX} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv13{v rdKY} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild21{v rdKZ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv14{v rdL0} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO143{v rdL1} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO144{v rdL2} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go35{v rdL3} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO145{v rdL4} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO146{v rdL5} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go36{v rdL6} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO147{v rdL7} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO148{v rdL8} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO149{v rdL9} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go37{v rdLa} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO150{v rdLb} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO151{v rdLc} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO152{v rdLd} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO153{v rdLe} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO154{v rdLf} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go38{v rdLg} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO155{v rdLh} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO156{v rdLi} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO157{v rdLj} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO158{v rdLk} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO159{v rdLl} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO160{v rdLm} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go39{v rdLn} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO161{v rdLo} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild22{v rdLp} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv15{v rdLq} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO162{v rdLr} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO163{v rdLs} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go40{v rdLt} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO164{v rdLu} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO165{v rdLv} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO166{v rdLw} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go41{v rdLx} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO167{v rdLy} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO168{v rdLz} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO169{v rdLA} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO170{v rdLB} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO171{v rdLC} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go42{v rdLD} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO172{v rdLE} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO173{v rdLF} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild23{v rdLG} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv16{v rdLH} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO174{v rdLI} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO175{v rdLJ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go43{v rdLK} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO176{v rdLL} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO177{v rdLM} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO178{v rdLN} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go44{v rdLO} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO179{v rdLP} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO180{v rdLQ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild24{v rdLR} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv17{v rdLS} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO181{v rdLT} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO182{v rdLU} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go45{v rdLV} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO183{v rdLW} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO184{v rdLX} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO185{v rdLY} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go46{v rdLZ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO186{v rdM0} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO187{v rdM1} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild25{v rdM2} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv18{v rdM3} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO188{v rdM4} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO189{v rdM5} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go47{v rdM6} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO190{v rdM7} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO191{v rdM8} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO192{v rdM9} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go48{v rdMa} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO193{v rdMb} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO194{v rdMc} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO195{v rdMd} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO196{v rdMe} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO197{v rdMf} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO198{v rdMg} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO199{v rdMh} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go49{v rdMi} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO200{v rdMj} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild26{v rdMk} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv19{v rdMl} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO201{v rdMm} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO202{v rdMn} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go50{v rdMo} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO203{v rdMp} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO204{v rdMq} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO205{v rdMr} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go51{v rdMs} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO206{v rdMt} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild27{v rdMu} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv20{v rdMv} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_wild28{v rdMw} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ipv21{v rdMx} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO207{v rdMy} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO208{v rdMz} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go52{v rdMA} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO209{v rdMB} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO210{v rdMC} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go53{v rdMD} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO211{v rdME} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO212{v rdMF} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO213{v rdMG} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_go54{v rdMH} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$cgfoldl{v rdMI} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$w$cgfoldl{v rdMJ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_$ctypeRep#{v rdMK} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO214{v rdML} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO215{v rdMM} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO216{v rdMN} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO_ww4{v rdMO} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fDataCMRawAPO217{v rdMP} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO_$cfromIRecord{v rdMQ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO1{v rdMR} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO2{v rdMS} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO3{v rdMT} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO4{v rdMU} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO5{v rdMV} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO6{v rdMW} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO7{v rdMX} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO8{v rdMY} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO9{v rdMZ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO10{v rdN0} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO11{v rdN1} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO12{v rdN2} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO13{v rdN3} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO14{v rdN4} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO15{v rdN5} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO16{v rdN6} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO17{v rdN7} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO18{v rdN8} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO19{v rdN9} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO20{v rdNa} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO21{v rdNb} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO22{v rdNc} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO23{v rdNd} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO24{v rdNe} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO25{v rdNf} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO26{v rdNg} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO27{v rdNh} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO28{v rdNi} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO29{v rdNj} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO30{v rdNk} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO31{v rdNl} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO32{v rdNm} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO33{v rdNn} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO34{v rdNo} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO35{v rdNp} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO36{v rdNq} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO37{v rdNr} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsIRecordCMRawAPO_$ctoIRecord{v rdNs} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$w$ctoIRecord{v rdNt} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsVariantCMRawAPO_$cfromVariant{v rdNu} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fIsVariantCMRawAPO_$ctoVariant{v rdNv} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fReadCMRawAPO_$creadListPrec{v rdNw} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fReadCMRawAPO1{v rdNx} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fReadCMRawAPO2{v rdNy} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fReadCMRawAPO3{v rdNz} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$wa{v rdNA} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fReadCMRawAPO_$creadPrec{v rdNB} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fReadCMRawAPO_$creadList{v rdNC} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fReadCMRawAPO4{v rdND} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fReadCMRawAPO_$creadsPrec{v rdNE} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fShowCMRawAPO_$cshowList{v rdNF} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fShowCMRawAPO1{v rdNG} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$w$cshowsPrec{v rdNH} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fShowCMRawAPO_$cshow{v rdNI} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fShowCMRawAPO_$cshowsPrec{v rdNJ} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fTradeableCMRawAPO_$cvalidation{v rdNK} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fTradeableCMRawAPO_$ccontractName{v rdNL} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fTradeableCMRawAPO_$ccontract{v rdNM} [gid] main:Cortex.CM.CMVanilla.CMRawAPO.$fTradeableCMRawAPO1{v rdNN} [gid] lvl{v rdNO} [gid] lvl1{v rdNP} [gid] lvl2{v rdNQ} [gid] lvl3{v rdNR} [gid] lvl4{v rdNS} [gid] lvl5{v rdNT} [gid] lvl6{v rdNU} [gid] lvl7{v rdNV} [gid] lvl8{v rdNW} [gid] lvl9{v rdNX} [gid] lvl10{v rdNY} [gid] lvl11{v rdNZ} [gid] lvl12{v rdO0} [gid] lvl13{v rdO1} [gid] lvl14{v rdO2} [gid] lvl15{v rdO3} [gid] lvl16{v rdO4} [gid] lvl17{v rdO5} [gid] lvl18{v rdO6} [gid] lvl19{v rdO7} [gid] lvl20{v rdO8} [gid] a{v rdO9} [gid] lvl21{v rdOa} [gid] a1{v rdOb} [gid] lvl22{v rdOc} [gid] a2{v rdOd} [gid] lvl23{v rdOe} [gid] a3{v rdOf} [gid] lvl24{v rdOg} [gid] a4{v rdOh} [gid] lvl25{v rdOi} [gid] lvl26{v rdOj} [gid] lvl27{v rdOk} [gid] lvl28{v rdOl} [gid] lvl29{v rdOm} [gid] lvl30{v rdOn} [gid] lvl31{v rdOo} [gid] lvl32{v rdOp} [gid] lvl33{v rdOq} [gid] lvl34{v rdOr} [gid] lvl35{v rdOs} [gid] lvl36{v rdOt} [gid] lvl37{v rdOu} [gid] lvl38{v rdOv} [gid] lvl39{v rdOw} [gid] lvl40{v rdOx} [gid] lvl41{v rdOy} [gid] lvl42{v rdOz} [gid] lvl43{v rdOA} [gid] lvl44{v rdOB} [gid] lvl45{v rdOC} [gid] lvl46{v rdOD} [gid] lvl47{v rdOE} [gid] lvl48{v rdOF} [gid] lvl49{v rdOG} [gid] lvl50{v rdOH} [gid] lvl51{v rdOI} [gid] a5{v rdOJ} [gid] a6{v rdOK} [gid] a7{v rdOL} [gid] a8{v rdOM} [gid] $dIsIFunction{v rdON} [gid] $dValue{v rdOO} [gid] $dPoly{v rdOP} [gid] $dRead{v rdOQ} [gid] lvl52{v rdOR} [gid] $dPoly1{v rdOS} [gid] $dRead1{v rdOT} [gid] $dIsIFunction1{v rdOU} [gid] $dValue1{v rdOV} [gid] $dPoly2{v rdOW} [gid] $dRead2{v rdOX} [gid] $dPoly3{v rdOY} [gid] lvl53{v rdOZ} [gid] $dShow{v rdP0} [gid] $dPoly4{v rdP1} [gid] lvl54{v rdP2} [gid] $dIsIFunction2{v rdP3} [gid] $dValue2{v rdP4} [gid] $dPoly5{v rdP5} [gid] $dRead3{v rdP6} [gid] lvl55{v rdP7} [gid] $dPoly6{v rdP8} [gid] $dRead4{v rdP9} [gid] lvl56{v rdPa} [gid] $dShow1{v rdPb} [gid] $dIsIFunction3{v rdPc} [gid] $dValue3{v rdPd} [gid] $dPoly7{v rdPe} [gid] $dRead5{v rdPf} [gid] $dPoly8{v rdPg} [gid] lvl57{v rdPh} [gid] $dShow2{v rdPi} [gid] $dRead6{v rdPj} [gid] $dRead7{v rdPk} [gid] ww{v senD} [lid] w{v senE} [lid] sat_senF{v} [lid] lvl58{v senH} [lid] lvl59{v senI} [lid] lvl60{v senJ} [lid] lvl61{v senK} [lid] lvl62{v senL} [lid] a9{v senM} [lid] lvl63{v senN} [lid] lvl64{v senO} [lid] lvl65{v senP} [lid] lvl66{v senQ} [lid] a10{v senR} [lid] lvl67{v senS} [lid] lvl68{v senT} [lid] lvl69{v senU} [lid] lvl70{v senV} [lid] a11{v senW} [lid] lvl71{v senX} [lid] lvl72{v senY} [lid] lvl73{v senZ} [lid] lvl74{v seo0} [lid] a12{v seo1} [lid] lvl75{v seo2} [lid] lvl76{v seo3} [lid] lvl77{v seo4} [lid] lvl78{v seo5} [lid] a13{v seo6} [lid] lvl79{v seo7} [lid] lvl80{v seo8} [lid] lvl81{v seo9} [lid] lvl82{v seoa} [lid] a14{v seob} [lid] lvl83{v seoc} [lid] lvl84{v seod} [lid] lvl85{v seoe} [lid] lvl86{v seof} [lid] a15{v seog} [lid] lvl87{v seoh} [lid] k{v sesN} [lid] w2{v sesO} [lid] sat_set1{v} [lid] sat_setx{v} [lid] sat_seu3{v} [lid] sat_seuz{v} [lid] sat_sev3{v} [lid] sat_sevz{v} [lid] sat_sew3{v} [lid] 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 Jun 23 08:49:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 08:49:51 -0000 Subject: [GHC] #9228: Internal compiler error with -O1 and -O2 In-Reply-To: <047.85eabab762dce9ba63253004f8d47fe4@haskell.org> References: <047.85eabab762dce9ba63253004f8d47fe4@haskell.org> Message-ID: <062.241797c08e803bf395b07f60047d90e2@haskell.org> #9228: Internal compiler error with -O1 and -O2 -------------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8892 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * related: => #8892 Comment: #8892 looks related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 08:50:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 08:50:07 -0000 Subject: [GHC] #9229: Compiler memory use regression Message-ID: <047.2dfbe078c69c15d5f9a03a8fcfb51c79@haskell.org> #9229: Compiler memory use regression -------------------------+------------------------------------------------- Reporter: | Owner: augustss | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Windows Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- I have a module which compiles fine with ghc 7.6, but where ghc 7.8.2 runs out of memory (32-bit Windows). Sadly, I cannot supply the source code since it's proprietary, so I realize that this bug will be almost impossible to fix. It is possible to compile the module with -O0 and -O1, but not -O2. (This is a very performance critical module so I'd like -O2.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 08:51:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 08:51:54 -0000 Subject: [GHC] #9229: Compiler memory use regression In-Reply-To: <047.2dfbe078c69c15d5f9a03a8fcfb51c79@haskell.org> References: <047.2dfbe078c69c15d5f9a03a8fcfb51c79@haskell.org> Message-ID: <062.36f874f29e47f54c8e415da0d1e2e480@haskell.org> #9229: Compiler memory use regression -------------------------------------------------+------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by thoughtpolice): This is probably #8960. Is it possible for you to turn off SpecConstr with `-fno-spec-constr` and see what difference it makes in compilation time and resulting executable speed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 08:57:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 08:57:01 -0000 Subject: [GHC] #9228: Internal compiler error with -O1 and -O2 In-Reply-To: <047.85eabab762dce9ba63253004f8d47fe4@haskell.org> References: <047.85eabab762dce9ba63253004f8d47fe4@haskell.org> Message-ID: <062.18e1efdc5c345fd3e32e8386eac686d3@haskell.org> #9228: Internal compiler error with -O1 and -O2 -------------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8892 -------------------------------------+------------------------------------ Comment (by simonpj): Try with `-dcore-lint` please. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 09:07:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 09:07:42 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.2286d9ed8b4421e488fc072a6c3e13bc@haskell.org> #9023: Error when using empty record update on binary pattern synonym ------------------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Test Case: patsyn/should_compile/T9023 | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Thanks Gergo, I've merged this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 09:27:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 09:27:43 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.38aa0ddb7e9b063eadc69daf6a85c0f4@haskell.org> #9023: Error when using empty record update on binary pattern synonym ------------------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Test Case: patsyn/should_compile/T9023 | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * milestone: 7.8.3 => 7.10.1 Comment: OK, so this couldn't go through cleanly because the Haddock change has a conflict that's proving to be extremely confusing: https://github.com/haskell/haddock/commit/e56a8037c04a32922cb0951c66f64ecc6ebfecb3 https://github.com/haskell/haddock/commit/e811b00837d19340047ad83273b4aa2dc2534dd8 I have no idea how to reconcile these two commits, since the v2.14 haddock branch has diverged from the 7.8 branch, and I have no clue what Fuuzetsu etc have planned here. So I'm inclined to just leave this one out I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 12:47:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 12:47:03 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.91bb09c3a389769d8ab6024ba1bd32ef@haskell.org> #9023: Error when using empty record update on binary pattern synonym ------------------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Test Case: patsyn/should_compile/T9023 | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by simonpj): Yes, just leave it out. There are other things wrong with pattern synonyms and we aren't going to fix all of them in the 7.8 branch. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 12:50:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 12:50:24 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.b0e2397197e56998351d07c694e4cc25@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): See also #9226, which is another instance of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 12:50:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 12:50:41 -0000 Subject: [GHC] #9226: Internal error when using equality constraint in pattern synonyms In-Reply-To: <051.9ff7e888b2f688be0dafb9aefbac40b9@haskell.org> References: <051.9ff7e888b2f688be0dafb9aefbac40b9@haskell.org> Message-ID: <066.12fe4dcdacd3f1aabfaf95d6ce7bda38@haskell.org> #9226: Internal error when using equality constraint in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: renamer, pattern Operating System: Linux | synonyms, GADTs Type of failure: GHC rejects | Architecture: x86 valid program | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8968 -------------------------------------+------------------------------------- Comment (by simonpj): I'd forgotten all about #8968. Yes, this ticket is really a dup of #8968. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 12:51:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 12:51:05 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.094d971264590a38657e66784a7e5392@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: pattern Type of failure: GHC rejects valid program | synonyms Test Case: | Architecture: Blocking: | Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by cactus): * keywords: => pattern synonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 13:15:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 13:15:46 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.c541a0a2114316931c763c27e674ce8a@haskell.org> #9023: Error when using empty record update on binary pattern synonym ------------------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Test Case: patsyn/should_compile/T9023 | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by cactus): That Haddock conflict is because of 7ac600d, which fixes #9175, which is also marked for merging anyway. I've updated the `wip/T9023` branch to contain both, then you can try merging from that again. I've also added a `wip/T9023` branch to Haddock for the same purpose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 14:15:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 14:15:33 -0000 Subject: [GHC] #9212: Cleanup of sync-all In-Reply-To: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> References: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> Message-ID: <060.0ad2ad28d7182c44c5e41e0f356003a3@haskell.org> #9212: Cleanup of sync-all -------------------------------------+------------------------------------ Reporter: thomie | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thomie): Here you go, all squashed up and rebased: https://github.com/thomie/ghc/commits/wip/T9212 Thanks for looking into this. A testsuite would need some work I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 15:07:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 15:07:29 -0000 Subject: [GHC] #9227: Coverage Condition cannot be turned off In-Reply-To: <047.00cb6fa9fbf58c6b033bc498f885a9b9@haskell.org> References: <047.00cb6fa9fbf58c6b033bc498f885a9b9@haskell.org> Message-ID: <062.c30e8c5779f25e21e82e5af4fdd7d3d2@haskell.org> #9227: Coverage Condition cannot be turned off ----------------------------+---------------------------------------------- Reporter: | Owner: augustss | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #1241, #2247, #8356, #8634 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by rwbarton): * related: => #1241, #2247, #8356, #8634 Comment: Without the Coverage Condition, functional dependencies are not actually functional at all. See #1241 for the original change, and #2247, #8356, #8634 (and probably others) for further discussion. Indeed, it looks like the documentation has not been updated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 15:23:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 15:23:28 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.2f2964c8419858abb58aef80b1311650@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8935 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: closed => new * resolution: fixed => * milestone: 7.8.3 => 7.8.4 Comment: This is now reverted on the 7.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 15:28:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 15:28:53 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.c2963aa09172a47fe170400b457de733@haskell.org> #9160: Panic: Template variable unbound in rewrite rule -------------------------------------------------+------------------------- Reporter: mietek | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | x86_64 (amd64) Test Case: | Difficulty: indexed_types/should_fail/T9160 | Unknown Blocking: | Blocked By: | Related Tickets: #4524 -------------------------------------------------+------------------------- Changes (by thoughtpolice): * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 15:29:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 15:29:09 -0000 Subject: [GHC] #9227: Coverage Condition cannot be turned off In-Reply-To: <047.00cb6fa9fbf58c6b033bc498f885a9b9@haskell.org> References: <047.00cb6fa9fbf58c6b033bc498f885a9b9@haskell.org> Message-ID: <062.f2f6255ee21bac096afc92b3a8714ae2@haskell.org> #9227: Coverage Condition cannot be turned off ----------------------------+---------------------------------------------- Reporter: | Owner: augustss | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #1241, #2247, #8356, #8634 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by augustss): That may be so, but in many circumstances the old behaviour worked fine. So there should be a flag to bring it back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 15:31:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 15:31:20 -0000 Subject: [GHC] #9199: Wrong Template Haskell desugaring In-Reply-To: <046.13d98ebb5f95442f706ab8481ad8b12c@haskell.org> References: <046.13d98ebb5f95442f706ab8481ad8b12c@haskell.org> Message-ID: <061.3881545fb98f67be37b6b1112245d01d@haskell.org> #9199: Wrong Template Haskell desugaring -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T9199 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 15:31:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 15:31:28 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.b6b6ae6dbada79e97b8b7d2e0ae1bdf6@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: stranal/should_compile/T9208 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 15:31:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 15:31:33 -0000 Subject: [GHC] #9199: Wrong Template Haskell desugaring In-Reply-To: <046.13d98ebb5f95442f706ab8481ad8b12c@haskell.org> References: <046.13d98ebb5f95442f706ab8481ad8b12c@haskell.org> Message-ID: <061.f7ed2e0174715ab31dc6e12632a4138c@haskell.org> #9199: Wrong Template Haskell desugaring -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T9199 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.8.4 => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 15:34:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 15:34:58 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.8a42206e791f09f180314788ede8125a@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8935 -------------------------------------+------------------------------------ Changes (by simonpj): * owner: => simonmar Comment: Back story: bug in runtime linker, introduced between 7.6 and 7.8 during dynamic linking changes. Fixing this changed the way we link dynamic libraries. But that introduced some other bug. Simon M will investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 15:51:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 15:51:46 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.16187d67e1c03a1d7ef20e7ce0703bb5@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: stranal/should_compile/T9208 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Joachim Breitner ): In [changeset:"518ada5cda08d3256826ed0383888111f8096de5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="518ada5cda08d3256826ed0383888111f8096de5" Mark T9208 as broken when debugging is on this seems to be expected, as explained by SPJ in comment 7 of #9208. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 15:58:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 15:58:56 -0000 Subject: [GHC] #9207: Detect obvious cases of infinite recursion. In-Reply-To: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> References: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> Message-ID: <062.9425118d9f7b1b8036abdd386abd8b6a@haskell.org> #9207: Detect obvious cases of infinite recursion. ------------------------------------+-------------------------------------- Reporter: mrugiero | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: infinite recursion Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | ------------------------------------+-------------------------------------- Comment (by rwbarton): Some version of strictness analysis could catch typos like `let y = y + 1 in ...` (oops, meant `let y = x + 1 in ...`), right? (Assuming `y` is inferred to have a concrete type like `Int` where `(+)` is known to be strict.) Those can be annoying to track down at runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 16:14:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 16:14:46 -0000 Subject: [GHC] #9207: Detect obvious cases of infinite recursion. In-Reply-To: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> References: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> Message-ID: <062.fd40a27126bf6171de03ee2dba195d35@haskell.org> #9207: Detect obvious cases of infinite recursion. ------------------------------------+-------------------------------------- Reporter: mrugiero | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: infinite recursion Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | ------------------------------------+-------------------------------------- Comment (by simonpj): GHC already does a guaranteed-divergence analysis. For example {{{ f [] = f [True] f (x:xs) = f xs }}} If you say {{{ ghc -c -O -ddump-simpl Foo.hs }}} you get something like this {{{ Foo.f [Occ=LoopBreaker] :: forall t_aK7. [GHC.Types.Bool] -> t_aK7 [GblId, Arity=1, Str=DmdType b] }}} That "`b`" in teh `Str=` part says "bottom" meaning guaranteed divergence. but it does not distinguish an infnite loop from a call to `error`. So {{{ f [] = f [True] f (x:xs) = error "urk" }}} would give the same result. Maybe this information can help? Though some functions are ''supposed'' to return bottom. Eg {{{ myError :: String -> a myError s = error ("Bad bad bad: " ++ s) }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 19:51:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 19:51:30 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default Message-ID: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------------+------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Tabs trip up an awful lot of Haskell beginners. Turning the warning on by default will likely save them a lot of grief. Any insane^h^h^h^h^h^hexperienced Haskellers who like tabs will have no trouble disabling the warning in their pragmas. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 20:07:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 20:07:18 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.5346555da4acf253d06743dccf0eaebb@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: patch Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9094 | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): there was some further discussion on https://phabricator.haskell.org/P5 and https://github.com/cartazio/ghc/compare/ghc:ghc-7.8...fixed-cpp-7.8 has the fixed up current patch on top of current ghc 7.8 head -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 23 23:58:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jun 2014 23:58:21 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.ddae74f4bc4293d39c8d44d05ba0ed1b@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: patch Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9094 | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): validates on linux 64bit intel with gcc and OS X 64bit with clang Unexpected results from: TEST="T3064 T5837 T6048" OVERALL SUMMARY for test run started at Mon Jun 23 19:20:11 2014 EDT 0:36:14 spent to go through 3963 total tests, which gave rise to 13079 test cases, of which 9461 were skipped 26 had missing libraries 3528 expected passes 61 expected failures 0 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T3064 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 01:18:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 01:18:28 -0000 Subject: [GHC] #9207: Detect obvious cases of infinite recursion. In-Reply-To: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> References: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> Message-ID: <062.e9eae06d00d633e6c3dae03916885dd4@haskell.org> #9207: Detect obvious cases of infinite recursion. ------------------------------------+-------------------------------------- Reporter: mrugiero | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: infinite recursion Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | ------------------------------------+-------------------------------------- Comment (by altaic): Replying to [comment:7 mrugiero]: > Those papers certainly sound interesting. Whoops, missed your comment, sorry! Here are the papers I have that are related to static complexity analysis, in no particular order: * Elvira Albert, Puri Arenas, Samir Genaim, Germ?n Puebla. ''Cost Relation Systems: A Language-Independent Target Language for Cost Analysis'' * Nao Hirokawa. ''Automated Complexity Analysis Based on the Dependency Pair Method'' * Jan Hoffmann and Zhong Shao. ''Type-Based Amortized Resource Analysis with Integers and Arrays'' * Jan Hoffmann and Martin Hofmann. ''Amortized Resource Analysis with Polymorphic Recursion and Partial Big-Step Operational Semantics'' * Jan Hoffmann and Martin Hofmann. ''Amortized Resource Analysis with Polynomial Potential: A Static Inference of Polynomial Bounds for Functional Programs (Extended Version)'' * Jennifer Paykin. ''Automated Cost Analysis of a Higher-Order Language in Coq'' * Lars Noschinski, Fabian Emmes, and J?rgen Giesl. ''A Dependency Pair Framework for Innermost Complexity Analysis of Term Rewrite Systems'' * Sumit Gulwani. ''SPEED: Symbolic Complexity Bound Analysis'' * Edward Z. Yang, David Mazi?res. ''Resource Limits for Haskell'' * Jan Hoffmann, Klaus Aehlig, and Martin Hofmann. ''Resource Aware ML'' * Jan Hoffmann, Klaus Aehlig, and Martin Hofmann. ''Multivariate Amortized Resource Analysis'' * Jan Hoffmann. ''Types with Potential: Polynomial Resource Bounds via Automatic Amortized Analysis'' * Martin Avanzini, Georg Moser, and Andreas Schnabl. ''Automated Implicit Computational Complexity Analysis (System Description)'' * Aart Middeldorp, Georg Moser, Friedrich Neurauter, Johannes Waldmann, and Harald Zankl. ''Joint Spectral Radius Theory for Automated Complexity Analysis of Rewrite Systems'' * Chris Okasaki. ''Purely Functional Data Structures'' * Alessandra Di Pierro and Herbert Wiklicky. ''Probabilistic Analysis of Programs: A Weak Limit Approach'' * R. M. Amadio, N. Ayache, F. Bobot, J. P. Boender, B. Campbell, I. Garnier, A. Madet, J. McKinna, D. P. Mulligan, M. Piccolo, R. Pollack, Y. R ?egis-Gianas, C. Sacerdoti Coen, I. Stark, and P. Tranquilli. ''Certified Complexity (CerCo)'' * M. Brockschmidt, F. Emmes, S. Falke, C. Fuhs, and J. Giesl. ''Alternating Runtime and Size Complexity Analysis of Integer Programs'' * Wolf Zimmermann. ''Automatic Worst Case Complexity Analysis of Parallel Programs'' * Jean-Pierre Jouannaud and Weiwen Xu. ''Automatic Complexity Analysis for Programs Extracted from Coq Proof'' * S?bastian Pop. ''Analysis of induction variables using chains of recurrences: extensions'' * Fran?ois Pottier. ''Types for complexity-checking'' (presentation) * Michael Kruse. ''Perfrewrite: Memory and Time Complexity Analysis via Source Code Instrumentation'' * Flemming Nielson, Hanne Riis Nielson, and Helmut Seidl. ''Automatic Complexity Analysis'' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 01:38:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 01:38:26 -0000 Subject: [GHC] #9047: Testsuite fails on OS X Mavericks In-Reply-To: <047.0afe1c31b6584b760336c379b75efabc@haskell.org> References: <047.0afe1c31b6584b760336c379b75efabc@haskell.org> Message-ID: <062.8195044f9cb8cac053c8d13542dc54be@haskell.org> #9047: Testsuite fails on OS X Mavericks ---------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Test Suite | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by kazu-yamamoto): Carter and I confirmed that "validate" works well on Mac. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 03:14:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 03:14:08 -0000 Subject: [GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico Message-ID: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> #9231: 7.8 regression in Read instance of Data.Fixed.Pico ------------------------------------+------------------------------------- Reporter: leonbaum2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If I run the following with ghc-7.8.2, the runtime system eats up all of my memory and doesn't produce a result: read "1" :: Data.Fixed.Pico -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 04:49:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 04:49:06 -0000 Subject: [GHC] #1721: Make GHCi print the entire result of an interactive 'bind' statement In-Reply-To: <046.657252b52c928fa83fef6abad76bac17@haskell.org> References: <046.657252b52c928fa83fef6abad76bac17@haskell.org> Message-ID: <061.7a1e307b32cc21352ff127515a0a385a@haskell.org> #1721: Make GHCi print the entire result of an interactive 'bind' statement -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Artyom.Kazak): * status: new => closed * resolution: => fixed Comment: The current choice (GHCi 7.8.2) is to print nothing even when there's only one bound variable, which is consistent and avoids unpleasant surprises (as the one Ryan Ingram stumbled upon ? see 1st comment). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 08:42:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 08:42:08 -0000 Subject: [GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico In-Reply-To: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> References: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> Message-ID: <063.975bd345468b4ebae566cd241d397db1@haskell.org> #9231: 7.8 regression in Read instance of Data.Fixed.Pico -------------------------------------+------------------------------------ Reporter: leonbaum2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): The parser code seems totally wrong, e.g. consider {{{#!hs convertFixed :: forall a . HasResolution a => Lexeme -> ReadPrec (Fixed a) convertFixed (Number n) | Just (i, f) <- numberToFixed r n = return (fromInteger i + (fromInteger f / (10 ^ r))) where r = resolution (undefined :: Fixed a) convertFixed _ = pfail }}} And note that `resolution` doesn't return an exponent but rather a power of 10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 08:43:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 08:43:01 -0000 Subject: [GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico In-Reply-To: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> References: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> Message-ID: <063.8969efcde7e4343cb4821743b267391c@haskell.org> #9231: 7.8 regression in Read instance of Data.Fixed.Pico -------------------------------------+------------------------------------ Reporter: leonbaum2 | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * cc: thoughtpolice (added) * keywords: => regression * priority: normal => highest * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 09:19:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 09:19:29 -0000 Subject: [GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico In-Reply-To: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> References: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> Message-ID: <063.0564b1a71c6a1c8c6791407b7843538b@haskell.org> #9231: 7.8 regression in Read instance of Data.Fixed.Pico -------------------------------------+------------------------------------ Reporter: leonbaum2 | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): I can't think of any cleaner fix for this other than radically rewriting `Data.Fixed` or extracting the 10-base exponent via {{{#!hs e = ceiling (logBase 10 (fromInteger r) :: Double) }}} and having the code read like {{{#!hs convertFixed :: forall a . HasResolution a => Lexeme -> ReadPrec (Fixed a) convertFixed (Number n) | Just (i, f) <- numberToFixed e n = return (fromInteger i + (fromInteger f / fromInteger r)) where r = resolution (undefined :: Fixed a) e = ceiling (logBase 10 (fromInteger r) :: Double) convertFixed _ = pfail }}} (Note that `numberToFixed` also expects an exponent rather than a power- of-10) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 09:22:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 09:22:54 -0000 Subject: [GHC] #9229: Compiler memory use regression In-Reply-To: <047.2dfbe078c69c15d5f9a03a8fcfb51c79@haskell.org> References: <047.2dfbe078c69c15d5f9a03a8fcfb51c79@haskell.org> Message-ID: <062.e34966c0c54ca7d4b75d80c09b51eaa0@haskell.org> #9229: Compiler memory use regression -------------------------------------------------+------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by augustss): Yes, turning off SpecConstr makes it work. Thanks for the workaround! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 09:29:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 09:29:02 -0000 Subject: [GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico In-Reply-To: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> References: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> Message-ID: <063.5f6ed3d59b0e1e16bf4176cc7eb87737@haskell.org> #9231: 7.8 regression in Read instance of Data.Fixed.Pico -------------------------------------+------------------------------------ Reporter: leonbaum2 | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): The really weird thing though is why the test-case at [[GhcFile(libraries/base/tests/readFixed001.hs)]] actually works as expected.... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 09:46:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 09:46:42 -0000 Subject: [GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico In-Reply-To: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> References: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> Message-ID: <063.1a51bf55e61c3450c8ea2211c21cda85@haskell.org> #9231: 7.8 regression in Read instance of Data.Fixed.Pico -------------------------------------+------------------------------------ Reporter: leonbaum2 | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * cc: igloo, ashley@? (added) Comment: `convertFixed` was last modified (or written) by Ian Lynagh. Much of the rest of `Data.Fixed` is by Ashley Yakeley. I'm copying both, not in a blaming way, but because they would both be well positioned to offer help on fixing. But others, please go ahead and suggest fixes. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 09:50:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 09:50:32 -0000 Subject: [GHC] #9232: Stats file has wrong numbers Message-ID: <047.3db25110988865ab6007bdabfb8b88ff@haskell.org> #9232: Stats file has wrong numbers ------------------------------------+----------------------------- Reporter: augustss | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+----------------------------- The summary numbers in the file generated with the -S flag cannot be right. Here's an example: {{{ 1,943,795,468 bytes allocated in the heap 17,587,189,232 bytes copied during GC }}} The corresponding numbers with ghc 7.2 are {{{ 193,859,474,520 bytes allocated in the heap 17,766,908,288 bytes copied during GC }}} While it's theoretically possible that allocation has improved that much, I don't believe it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 09:54:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 09:54:35 -0000 Subject: [GHC] #9232: Stats file has wrong numbers In-Reply-To: <047.3db25110988865ab6007bdabfb8b88ff@haskell.org> References: <047.3db25110988865ab6007bdabfb8b88ff@haskell.org> Message-ID: <062.a341108f2f5fd5f45fd0486bff3060d1@haskell.org> #9232: Stats file has wrong numbers -----------------------------------+------------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by simonpj): Does time improve? Does allocation rate change? It's unusual, but entirely possible. Eg better let-floating or whatnot. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 09:56:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 09:56:52 -0000 Subject: [GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico In-Reply-To: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> References: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> Message-ID: <063.0e884f44e5301037a60eb536a90a1431@haskell.org> #9231: 7.8 regression in Read instance of Data.Fixed.Pico -------------------------------------+------------------------------------ Reporter: leonbaum2 | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): I've just submitted https://phabricator.haskell.org/D25 for review to get the ball rolling -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 09:59:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 09:59:12 -0000 Subject: [GHC] #9233: Compiler performance regression Message-ID: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> #9233: Compiler performance regression ------------------------------------+--------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Compiling all of our Haskell modules (about 1300 modules, 310 kLOC) takes about 30% longer with ghc 7.8 than it did with ghc 7.2. (Using 32-bit Windows.) Sorry, I can't really provide any simple test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:06:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:06:51 -0000 Subject: [GHC] #9234: Compiled code performance regression Message-ID: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> #9234: Compiled code performance regression ------------------------------------+--------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Upgrading from ghc 7.2 to 7.8 has slowed down our main application noticeably. This is with 32-bit Windows. Here's some 7.2 numbers: {{{ INIT time 0.00s ( 0.00s elapsed) MUT time 287.78s (290.41s elapsed) GC time 87.39s ( 88.43s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 375.63s (378.86s elapsed) }}} And corresponding 7.8 numbers: {{{ INIT time 0.00s ( 0.00s elapsed) MUT time 298.34s (301.35s elapsed) GC time 88.16s ( 89.27s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 386.93s (390.62s elapsed) }}} This is not unexpected since every ghc upgrade so far has slowed down out code; it's just following the trend we expect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:07:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:07:20 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.aa0e143611032ac245c34565eaaf972b@haskell.org> #9233: Compiler performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by simonpj): I would love it if someone could do some profiling on GHC to see what is going on. Generally, we are weak on profiling the compiler. For example, I suspect there are easily-fixed space leaks. But someone has to roll up their sleeves and look. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:12:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:12:52 -0000 Subject: [GHC] #9232: Stats file has wrong numbers In-Reply-To: <047.3db25110988865ab6007bdabfb8b88ff@haskell.org> References: <047.3db25110988865ab6007bdabfb8b88ff@haskell.org> Message-ID: <062.b512b0cb901a39783d7074c187c629e8@haskell.org> #9232: Stats file has wrong numbers -----------------------------------+------------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by augustss): No, the overall time is worse. And the number of garbage collections has increased. ghc 7.6: {{{ Gen 0 1389 colls, 0 par 60.28s 60.75s 0.0437s 0.6840s Gen 1 21 colls, 0 par 27.11s 27.68s 1.3182s 4.0802s }}} ghc 7.8: {{{ Gen 0 1438 colls, 0 par 58.84s 58.68s 0.0408s 0.6828s Gen 1 21 colls, 0 par 29.31s 30.59s 1.4566s 4.5564s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:13:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:13:49 -0000 Subject: [GHC] #9234: Compiled code performance regression In-Reply-To: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> References: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> Message-ID: <062.27a626696259bdc03beeb1a19f23a476@haskell.org> #9234: Compiled code performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by simonpj): I'm more surprised about this. Generally I expect runtime performance to improve, not get worse. I do profile runtime performance more carefully, but my only benchmark suite is nofib. Anything you can do to characterise what is slowing down would be extremely helpful. Providing benchmark programs would be extremely helpful. Lacking either, and I know that both are hard for you, it's hard to know how to help. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:14:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:14:41 -0000 Subject: [GHC] #9234: Compiled code performance regression In-Reply-To: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> References: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> Message-ID: <062.e0823f5127ee072ae9d36fa9fe278405@haskell.org> #9234: Compiled code performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by tibbe): Could you set up a build bot the builds GHC HEAD and runs your application using it? That way we could better pinpoint when we regress. GHC should of course have such a build bot itself, using some benchmark suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:16:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:16:19 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.456c3456e5b5d3f6042f7b03f6b4567c@haskell.org> #9233: Compiler performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Old description: > Compiling all of our Haskell modules (about 1300 modules, 310 kLOC) takes > about 30% longer with ghc 7.8 than it did with ghc 7.2. (Using 32-bit > Windows.) > > Sorry, I can't really provide any simple test case. New description: Compiling all of our Haskell modules (about 1300 modules, 310 kLOC) takes about 30% longer with ghc 7.8 than it did with ghc 7.6. (Using 32-bit Windows.) Sorry, I can't really provide any simple test case. -- Comment (by augustss): Oops, I meant to say ghc 7.6, not 7.2 in my bug report. If I have some time I'll try to find a single module where the compilation has slowed down, and see if I can profile that. Is there a way to get hold of a profiling ghc binary? Compiling ghc on Windows always takes a few days to get working. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:17:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:17:32 -0000 Subject: [GHC] #9234: Compiled code performance regression In-Reply-To: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> References: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> Message-ID: <062.87e7135a7187a9d0a1aca43dce9bcfd6@haskell.org> #9234: Compiled code performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Description changed by augustss: Old description: > Upgrading from ghc 7.2 to 7.8 has slowed down our main application > noticeably. This is with 32-bit Windows. > > Here's some 7.2 numbers: > {{{ > INIT time 0.00s ( 0.00s elapsed) > MUT time 287.78s (290.41s elapsed) > GC time 87.39s ( 88.43s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 375.63s (378.86s elapsed) > }}} > > And corresponding 7.8 numbers: > {{{ > INIT time 0.00s ( 0.00s elapsed) > MUT time 298.34s (301.35s elapsed) > GC time 88.16s ( 89.27s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 386.93s (390.62s elapsed) > }}} > > This is not unexpected since every ghc upgrade so far has slowed down out > code; it's just following the trend we expect. New description: Upgrading from ghc 7.6 to 7.8 has slowed down our main application noticeably. This is with 32-bit Windows. Here's some 7.2 numbers: {{{ INIT time 0.00s ( 0.00s elapsed) MUT time 287.78s (290.41s elapsed) GC time 87.39s ( 88.43s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 375.63s (378.86s elapsed) }}} And corresponding 7.8 numbers: {{{ INIT time 0.00s ( 0.00s elapsed) MUT time 298.34s (301.35s elapsed) GC time 88.16s ( 89.27s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 386.93s (390.62s elapsed) }}} This is not unexpected since every ghc upgrade so far has slowed down out code; it's just following the trend we expect. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:19:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:19:09 -0000 Subject: [GHC] #9232: Stats file has wrong numbers In-Reply-To: <047.3db25110988865ab6007bdabfb8b88ff@haskell.org> References: <047.3db25110988865ab6007bdabfb8b88ff@haskell.org> Message-ID: <062.c6baafe568d5b30f98bd848f98c9943f@haskell.org> #9232: Stats file has wrong numbers -----------------------------------+------------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by simonpj): OK, so the displayed allocation rate (displayed by -S) must be much, much, much lower? After all, you are saying that GHC 7.8 allocates 100x less data, but takes longer, so the allocation rate must be much lower too. Would you like to show the actual output? A useful thing to do is to compile everything (libraries and all, ideally, but not essential) with `-ticky`. That has no effect on optimisation but does gather per-function allocation counts. Then run with `+RTS -rfoo.ticky`. Results in file `foo.ticky`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:21:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:21:11 -0000 Subject: [GHC] #9234: Compiled code performance regression In-Reply-To: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> References: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> Message-ID: <062.dd0200ad07c3abcdc42802cb47172c54@haskell.org> #9234: Compiled code performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by augustss): I did try to profile two different ghc versions another time to find out what happened, but the profile is very "smeared out", i.e., many things using a little time. The previous time I tried there was nothing that stuck out; everything just got a little slower. The trend is fairly consistent, we lose 3-10% performance on every ghc upgrade. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:23:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:23:09 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.4455b63d04b104e1ede143de445659c8@haskell.org> #9233: Compiler performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by simonpj): I guess that Austin might be able to put up a Windows version of GHC 7.8 ( plus I suppose 7.6) that has profiling enabled. You would not want to run that regularly, but it would mean you could compile both modules with a compiler that dumps its profile. Are you using -O2? The `SpecConstr` thing can make a pretty big difference. You could try switching it off globally and see what happens. Using `-dshow-passes` shows you the size of each intermediate can also be illuminating, because it shows size blow-ups clearly. Probably worth a try before the profiled-compiler stuff. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:25:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:25:56 -0000 Subject: [GHC] #9234: Compiled code performance regression In-Reply-To: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> References: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> Message-ID: <062.f37442765a5d7044a4f35f7bf2374f3f@haskell.org> #9234: Compiled code performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by augustss): If we had more resources (human and machine) it would be interesting to keep up with ghc HEAD. But keeping up with ghc is not effortless nor automatic. I've spent about 1.5 weeks upgrading from 7.6 to 7.8. It involves finding a set of packages that compiles with the new ghc, and fixing all the places in our code where the new ghc is incompatible with the old one. Note, I'm not complaining about having to do these changes, but we don't have the resources to do them continuously. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:26:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:26:12 -0000 Subject: [GHC] #9232: Stats file has wrong numbers In-Reply-To: <047.3db25110988865ab6007bdabfb8b88ff@haskell.org> References: <047.3db25110988865ab6007bdabfb8b88ff@haskell.org> Message-ID: <062.f5c3bdf90dd1d7e11a1a6180474d458c@haskell.org> #9232: Stats file has wrong numbers -----------------------------------+------------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by simonmar): We know that this isn't happening consistently, because our allocation measurements for e.g. nofib runs aren't showing any weirdness. Which means it's something more specific. I take it you can't share the program, and don't have a smaller example that demonstrates the problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:27:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:27:45 -0000 Subject: [GHC] #7483: Broken Read instance for Data.Fixed ("no parse" in legitimate cases). In-Reply-To: <046.6c8e930207622de060ca4dca8cd46112@haskell.org> References: <046.6c8e930207622de060ca4dca8cd46112@haskell.org> Message-ID: <061.bc9a11313b524f147a9a133d26c6a1bb@haskell.org> #7483: Broken Read instance for Data.Fixed ("no parse" in legitimate cases). ------------------------------------------------+-------------------------- Reporter: navaati | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: readFixed001 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #4502 ------------------------------------------------+-------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"c1035d51edaac2f388a0630e2ad25391e7e3c1ab/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c1035d51edaac2f388a0630e2ad25391e7e3c1ab" Fix regression in Data.Fixed Read instance (re #9231) `convertFixed` operates under the wrong assumption that `Data.Fixed.resolution` returns a base-10 exponent `e`, whereas it actually returns the power-of-10 value `10^e`. So while the code (that was introduced in 5f19f951d8 / #7483) happens to compute a correct result by coincidence, it allocates huge integer values in the process (i.e. `10^(10^e)`) which cause long computations which eventually result in out-of-memory conditions for `e`-values beyond `Data.Fixed.Milli`. A proper long-term fix would probably be to extend the `HasResolution` type-class to have a 2nd method providing the `e` value. Signed-off-by: Herbert Valerio Riedel Differential Revision: https://phabricator.haskell.org/D25 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:27:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:27:45 -0000 Subject: [GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico In-Reply-To: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> References: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> Message-ID: <063.7f8afffd73f055fbe983e8b74eeb50eb@haskell.org> #9231: 7.8 regression in Read instance of Data.Fixed.Pico -------------------------------------+------------------------------------ Reporter: leonbaum2 | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"c1035d51edaac2f388a0630e2ad25391e7e3c1ab/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c1035d51edaac2f388a0630e2ad25391e7e3c1ab" Fix regression in Data.Fixed Read instance (re #9231) `convertFixed` operates under the wrong assumption that `Data.Fixed.resolution` returns a base-10 exponent `e`, whereas it actually returns the power-of-10 value `10^e`. So while the code (that was introduced in 5f19f951d8 / #7483) happens to compute a correct result by coincidence, it allocates huge integer values in the process (i.e. `10^(10^e)`) which cause long computations which eventually result in out-of-memory conditions for `e`-values beyond `Data.Fixed.Milli`. A proper long-term fix would probably be to extend the `HasResolution` type-class to have a 2nd method providing the `e` value. Signed-off-by: Herbert Valerio Riedel Differential Revision: https://phabricator.haskell.org/D25 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:28:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:28:09 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.8b8278415b3fb7e78b25a6f595c3a68e@haskell.org> #9233: Compiler performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by augustss): We are using -O2. I'll try switching off SpecConstr and see what happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:28:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:28:30 -0000 Subject: [GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico In-Reply-To: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> References: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> Message-ID: <063.b4029fc4f5a3645dfad00a074f2c182c@haskell.org> #9231: 7.8 regression in Read instance of Data.Fixed.Pico -------------------------------------+------------------------------------ Reporter: leonbaum2 | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:30:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:30:48 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.d9fccdfa144e92810958d98c9158bcf0@haskell.org> #9233: Compiler performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by simonpj): Also see #8852, which I still have to investigate. Do you use attoparsec? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:33:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:33:25 -0000 Subject: [GHC] #9232: Stats file has wrong numbers In-Reply-To: <047.3db25110988865ab6007bdabfb8b88ff@haskell.org> References: <047.3db25110988865ab6007bdabfb8b88ff@haskell.org> Message-ID: <062.49e3f5fac597607f2ffc8d48a57482d3@haskell.org> #9232: Stats file has wrong numbers -----------------------------------+------------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by augustss): Sorry, we can't share the program. If I have time I'll try the -ticky. I'm not very concerned about this bug, but I do keep an eye on allocation numbers when making changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:37:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:37:19 -0000 Subject: [GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico In-Reply-To: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> References: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> Message-ID: <063.943193db81775bc6bac530e56126bfeb@haskell.org> #9231: 7.8 regression in Read instance of Data.Fixed.Pico -------------------------------------+------------------------------------ Reporter: leonbaum2 | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Ashley Yakeley): Just to clarify, r is not necessarily a power of 10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 10:40:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 10:40:37 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.77358ea9d9831b79e1aaf214033954e5@haskell.org> #9233: Compiler performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by augustss): We have attoparsec installed, but none of the 1300 modules directly imports anything from it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 12:14:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 12:14:20 -0000 Subject: [GHC] #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) In-Reply-To: <050.ccaf00573c35157f252c17db26bcc258@haskell.org> References: <050.ccaf00573c35157f252c17db26bcc258@haskell.org> Message-ID: <065.04fb9386d2fa0d39e93ded90f15c935c@haskell.org> #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) -------------------------------+------------------------------------------- Reporter: | Owner: jimenezrick | Status: patch Type: task | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/unix | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: POSIX | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by tibbe): * status: new => patch Comment: Is the linked to .patch file enough for review or would people like to see it as an attachment to this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 12:14:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 12:14:27 -0000 Subject: [GHC] #9161: Pattern synonyms interact badly with data kinds In-Reply-To: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> References: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> Message-ID: <066.03123efb7e30a288ec634aee074918ad@haskell.org> #9161: Pattern synonyms interact badly with data kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: merge Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: renamer, pattern Resolution: | synonyms, data kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile-time | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by simonpj): The actual commit is {{{ commit aa3166f42361cb605e046f4a063be3f9e1f48015 Author: Dr. ERDI Gergo Date: Sat Jun 21 22:37:50 2014 +0800 Add fake entries into the global kind environment for pattern synonyms. This is needed to give meaningful error messages (instead of internal panics) when a program tries to lift a pattern synonym into a kind. (fixes T9161) >--------------------------------------------------------------- aa3166f42361cb605e046f4a063be3f9e1f48015 compiler/typecheck/TcBinds.lhs | 23 ++++++++++++++++------- compiler/typecheck/TcHsType.lhs | 1 - testsuite/tests/patsyn/should_fail/T9161-1.hs | 7 +++++++ testsuite/tests/patsyn/should_fail/T9161-1.stderr | 4 ++++ testsuite/tests/patsyn/should_fail/T9161-2.hs | 9 +++++++++ testsuite/tests/patsyn/should_fail/T9161-2.stderr | 5 +++++ testsuite/tests/patsyn/should_fail/all.T | 2 ++ 7 files changed, 43 insertions(+), 8 deletions(-) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 12:24:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 12:24:56 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.2ff71ac95f729c720ff39757d8ce119a@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: stranal/should_compile/T9208 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8a0aa198f78cac1ca8d0695bd711778e8ad086aa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8a0aa198f78cac1ca8d0695bd711778e8ad086aa" Comment the expect_broken for Trac #9208 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 12:24:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 12:24:56 -0000 Subject: [GHC] #9161: Pattern synonyms interact badly with data kinds In-Reply-To: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> References: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> Message-ID: <066.2bcd4a8cfbb940674d32d14b522f0b1c@haskell.org> #9161: Pattern synonyms interact badly with data kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: merge Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: renamer, pattern Resolution: | synonyms, data kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile-time | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0757831eaca96c8ebfd99fc51427560d3568cffa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0757831eaca96c8ebfd99fc51427560d3568cffa" Add Note [Placeholder PatSyn kinds] in TcBinds This is just documentation for the fix to Trac #9161 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 12:35:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 12:35:05 -0000 Subject: [GHC] #9161: Pattern synonyms interact badly with data kinds In-Reply-To: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> References: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> Message-ID: <066.05862b7e05147570e874ab4da2d0e668@haskell.org> #9161: Pattern synonyms interact badly with data kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: merge Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: renamer, pattern Resolution: | synonyms, data kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile-time | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by cactus): Thanks for that note, which explains it much better than my original comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 13:21:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 13:21:45 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.b3ea4c33d0bfd23fc9f361d4a33a7e45@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------ Reporter: jcristovao | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jcristovao): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 14:03:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 14:03:18 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.17dd93675e266b67994e636b8c677ee6@haskell.org> #9233: Compiler performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by augustss): I turned off SpecConstr and the compile times remained pretty much the same. Total compile time with ghc-7.6 is 5041s and with ghc-7.8 it is 6963s, so 38% longer. This is compiling 853 modules, out of which 5 modules compiled faster with the new ghc and the rest are slower, some taking almost 3 times as long. I will see if I can isolate one of these module and include in this bug report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 14:17:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 14:17:59 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.d5bbe15b48c4d06e38515efbae9e4659@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------+------------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by goldfire): +1 from me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 14:18:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 14:18:35 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.fd775739763c260642cab9f5bb34bfe8@haskell.org> #9233: Compiler performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by augustss): I've attached an example. Run the command {{{ ghc --make -O2 -fno-spec-constr Options.hs }}} On my machine it takes 17s with ghc-7.6 and 38s with ghc-7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 14:28:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 14:28:20 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.d4f97822c88e4ede2f53082798cf5084@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------+------------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by tibbe): I've been bitten by files that mixed tabs and spaces before, so +1 from me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 14:44:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 14:44:37 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.fd5449967861adde47b482bcc019ff67@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------ Reporter: jcristovao | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): This kind of diff with no context is hard to read and in danger of getting out of date with upstream. Can you attach a diff produced by `git diff` or, failing that, at least with `diff -u`? (I think the attached diff is backwards, too.) Also, a documentation patch would be helpful. It's somewhat less obvious how I'm supposed to use a local .ghci_history file than a local .ghci file, since a .ghci file is written by the user, but a .ghci_history is (usually) produced by .ghci. Am I supposed to just create an empty .ghci_history file in the directory where I want to use local history? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 14:52:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 14:52:14 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.e302b9668a8476234a340b58f0eb5941@haskell.org> #9233: Compiler performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by goldfire): I, too, have noticed that GHC has gotten slower to compile between 7.6.3 and 7.8.2. And, I have a nice file that demonstrates the slowness. First, 7.6.3: {{{ rae:10:40:52 ~/temp/th-desugar> ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 rae:10:43:47 ~/temp/th-desugar> time ghc Language/Haskell/TH/Desugar/Core.hs [1 of 2] Compiling Language.Haskell.TH.Desugar.Util ( Language/Haskell/TH/Desugar/Util.hs, Language/Haskell/TH/Desugar/Util.o ) [2 of 2] Compiling Language.Haskell.TH.Desugar.Core ( Language/Haskell/TH/Desugar/Core.hs, Language/Haskell/TH/Desugar/Core.o ) real 0m2.674s user 0m2.512s sys 0m0.131s rae:10:43:53 ~/temp/th-desugar> rm -f `find . -name '*.o' -or -name '*.hi' -or -name '*.dyn*'` rae:10:43:58 ~/temp/th-desugar> time ghc Language/Haskell/TH/Desugar/Core.hs -O2 [1 of 2] Compiling Language.Haskell.TH.Desugar.Util ( Language/Haskell/TH/Desugar/Util.hs, Language/Haskell/TH/Desugar/Util.o ) [2 of 2] Compiling Language.Haskell.TH.Desugar.Core ( Language/Haskell/TH/Desugar/Core.hs, Language/Haskell/TH/Desugar/Core.o ) real 0m9.089s user 0m8.648s sys 0m0.241s rae:10:44:13 ~/temp/th-desugar> rm -f `find . -name '*.o' -or -name '*.hi' -or -name '*.dyn*'` rae:10:44:17 ~/temp/th-desugar> time ghc Language/Haskell/TH/Desugar/Core.hs -O2 -fno-spec-constr [1 of 2] Compiling Language.Haskell.TH.Desugar.Util ( Language/Haskell/TH/Desugar/Util.hs, Language/Haskell/TH/Desugar/Util.o ) [2 of 2] Compiling Language.Haskell.TH.Desugar.Core ( Language/Haskell/TH/Desugar/Core.hs, Language/Haskell/TH/Desugar/Core.o ) real 0m9.351s user 0m8.180s sys 0m0.242s }}} Now, 7.8.2: {{{ rae:10:44:41 ~/temp/th-desugar> ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.2 rae:10:44:45 ~/temp/th-desugar> rm -f `find . -name '*.o' -or -name '*.hi' -or -name '*.dyn*'` rae:10:44:49 ~/temp/th-desugar> time ghc Language/Haskell/TH/Desugar/Core.hs [1 of 2] Compiling Language.Haskell.TH.Desugar.Util ( Language/Haskell/TH/Desugar/Util.hs, Language/Haskell/TH/Desugar/Util.o ) [2 of 2] Compiling Language.Haskell.TH.Desugar.Core ( Language/Haskell/TH/Desugar/Core.hs, Language/Haskell/TH/Desugar/Core.o ) real 1m5.906s user 0m7.972s sys 0m0.449s rae:10:45:58 ~/temp/th-desugar> rm -f `find . -name '*.o' -or -name '*.hi' -or -name '*.dyn*'` rae:10:46:05 ~/temp/th-desugar> time ghc Language/Haskell/TH/Desugar/Core.hs -O2 [1 of 2] Compiling Language.Haskell.TH.Desugar.Util ( Language/Haskell/TH/Desugar/Util.hs, Language/Haskell/TH/Desugar/Util.o ) [2 of 2] Compiling Language.Haskell.TH.Desugar.Core ( Language/Haskell/TH/Desugar/Core.hs, Language/Haskell/TH/Desugar/Core.o ) real 0m58.498s user 0m18.374s sys 0m0.566s rae:10:47:06 ~/temp/th-desugar> rm -f `find . -name '*.o' -or -name '*.hi' -or -name '*.dyn*'` rae:10:47:14 ~/temp/th-desugar> time ghc Language/Haskell/TH/Desugar/Core.hs -O2 -fno-spec-constr [1 of 2] Compiling Language.Haskell.TH.Desugar.Util ( Language/Haskell/TH/Desugar/Util.hs, Language/Haskell/TH/Desugar/Util.o ) [2 of 2] Compiling Language.Haskell.TH.Desugar.Core ( Language/Haskell/TH/Desugar/Core.hs, Language/Haskell/TH/Desugar/Core.o ) real 1m32.710s user 0m17.552s sys 0m0.637s }}} The relevant files are attached. I don't have data for it, but I've noticed that compiling these files in GHCi is relatively snappy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 16:49:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 16:49:55 -0000 Subject: [GHC] #9235: Simplifier ticks exhausted on recursive class method Message-ID: <043.df7f9b9ba092e09a71bb6cbbadc19ff7@haskell.org> #9235: Simplifier ticks exhausted on recursive class method -----------------------------------+--------------------------------------- Reporter: klao | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- GHC 7.8 and HEAD panic on the following code: {{{#!haskell module C where class C a where c :: C a => a -> Int c a = c a {-# INLINE c #-} instance C () x :: Int x = c () }}} Note that it's the coincidence of the 3 conditions that triggers this bug: 1. the `c` method has to be inlined (explicity or implicitly) 2. it has to be recursive (but, it doesn't have to be as dumbly recursive as in the example) 3. it has to have this weird, slightly mistaken type signature: `C a => a -> Int` instead of simply `a -> Int`. But, when this incidentally happens (in my case, both 2. ''and'' 3. were unintentional), the user gets a very hard to debug issue. They don't even get an indication which module is responsible if `c` is used from a different module than the one with the class definition. Also note that this happens even with a non-optimized build. And in this example `c` has to be explicitly marked NOINLINE to prevent it. (In the instance that I caught in the wild simply removing the INLINE annotation was enough.) Finally, on a side note: shouldn't 3. by itself be an error? Or a warning at least? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 17:50:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 17:50:02 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.a119a24b8af367998ee7afbaf52c7ca5@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------ Reporter: nh2 | Owner: 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 | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by bardur.arantsson): * cc: bardur.arantsson (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 17:54:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 17:54:58 -0000 Subject: [GHC] #9236: hGetContents leads to late/silent failures Message-ID: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> #9236: hGetContents leads to late/silent failures ------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A common newbie error: {{{ #!haskell withFile "file" ReadMode hGetContents >>= putStr }}} The problem, of course, is that the result of `withFile "file" ReadMode hGetContents` isn't forced until `putStr` is executed, at which point the file has already been closed. The Haskell report doesn't specify what it will find, and, at least in 7.6.3, it finds the string empty. The behavior that seems most correct to me would be to guarantee that if a file has not been completely read (or read up to an I/O error) when it is closed, then its contents should be reported as something like `"Four score and seven years ag"++error "Forcing a suspended computation led to an attempted read from a handle that was already closed."` Since the current system apparently puts an `[]` as a temporary marker while waiting to see what the rest of the list will be, I imagine that the fix is as simple as putting the error thunk there instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 18:09:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 18:09:12 -0000 Subject: [GHC] #9236: hGetContents leads to late/silent failures In-Reply-To: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> References: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> Message-ID: <060.4a5e78f49544887b16eca482811f5cbe@haskell.org> #9236: hGetContents leads to late/silent failures -------------------------------------+------------------------------------ Reporter: dfeuer | Owner: Type: feature request | 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 | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dfeuer): Specifically, it looks like all that we need is to change {{{ #!haskell lazyRead :: Handle -> IO String lazyRead handle = unsafeInterleaveIO $ withHandle "hGetContents" handle $ \ handle_ -> do case haType handle_ of ClosedHandle -> return (handle_, "") SemiClosedHandle -> lazyReadBuffered handle handle_ _ -> ioException (IOError (Just handle) IllegalOperation "hGetContents" "illegal handle type" Nothing Nothing) }}} to {{{ #!haskell lazyRead :: Handle -> IO String lazyRead handle = unsafeInterleaveIO $ withHandle "hGetContents" handle $ \ handle_ -> do case haType handle_ of ClosedHandle -> return (handle_, error "You can't get blood from a stone.") SemiClosedHandle -> lazyReadBuffered handle handle_ _ -> ioException (IOError (Just handle) IllegalOperation "hGetContents" "illegal handle type" Nothing Nothing) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 18:22:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 18:22:58 -0000 Subject: [GHC] #9223: Type equality makes type variable untouchable In-Reply-To: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> References: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> Message-ID: <063.f3524fb63b7fd2f34bcce32ac7903784@haskell.org> #9223: Type equality makes type variable untouchable --------------------------------------------+------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by goldfire): I may have said this elsewhere, but if we keep the "untouchable" stuff in the error message, it would be great to include a link to more information. Untouchable variables are really subtle, and an understanding of them is necessary for a programmer to make progress here. Section 5.2 of the !OutsideIn paper is a great starting place for what should be at the other end of the link. Personally, I favor the second message above -- it has more information a programmer might use to fix the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 18:39:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 18:39:06 -0000 Subject: [GHC] #9236: hGetContents leads to late/silent failures In-Reply-To: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> References: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> Message-ID: <060.c978c3e00d4422a262c78d3c0f5b0816@haskell.org> #9236: hGetContents leads to late/silent failures -------------------------------+------------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by dfeuer): * failure: None/Unknown => Other * cc: hvr, ekmett (added) * component: Compiler => libraries/base * difficulty: Unknown => Easy (less than 1 hour) * version: 7.6.3 => 7.8.2 Old description: > A common newbie error: > {{{ > #!haskell > withFile "file" ReadMode hGetContents >>= putStr > }}} > > The problem, of course, is that the result of `withFile "file" ReadMode > hGetContents` isn't forced until `putStr` is executed, at which point the > file has already been closed. The Haskell report doesn't specify what it > will find, and, at least in 7.6.3, it finds the string empty. The > behavior that seems most correct to me would be to guarantee that if a > file has not been completely read (or read up to an I/O error) when it is > closed, then its contents should be reported as something like `"Four > score and seven years ag"++error "Forcing a suspended computation led to > an attempted read from a handle that was already closed."` Since the > current system apparently puts an `[]` as a temporary marker while > waiting to see what the rest of the list will be, I imagine that the fix > is as simple as putting the error thunk there instead. New description: A common newbie error: {{{ #!haskell withFile "file" ReadMode hGetContents >>= putStr }}} The problem, of course, is that the result of `withFile "file" ReadMode hGetContents` isn't forced until `putStr` is executed, at which point the file has already been closed. The Haskell report doesn't specify what it will find, and, at least in 7.6.3, it finds the string empty. The behavior that seems most correct to me would be to guarantee that if a file has not been completely read (or read up to an I/O error) when it is closed, then its contents should be reported as something like `"Four score and seven years ag"++error "Forcing a suspended computation led to an attempted read from a handle that was already closed."` My suggested fix is in a comment below. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 19:45:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 19:45:06 -0000 Subject: [GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico In-Reply-To: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> References: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> Message-ID: <063.af12cde34cf7bfd0ff9a4012500d90a2@haskell.org> #9231: 7.8 regression in Read instance of Data.Fixed.Pico -------------------------------------+------------------------------------ Reporter: leonbaum2 | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:9 Ashley Yakeley]: > Just to clarify, r is not necessarily a power of 10. Now that you say it, I had the impression an implicit power-of-10 assumption was baked into `Data.Fixed`, for instance consider the following weird behaviour (can be observed in GHC 7.6 as well): {{{ Prelude> import Data.Fixed Prelude Data.Fixed> data B7 Prelude Data.Fixed> instance HasResolution B7 where resolution _ = 128 Prelude Data.Fixed> 1.070 :: Fixed B7 1.062 Prelude Data.Fixed> 1.062 :: Fixed B7 1.054 Prelude Data.Fixed> 1.054 :: Fixed B7 1.046 Prelude Data.Fixed> 1.046 :: Fixed B7 1.039 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 20:13:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 20:13:23 -0000 Subject: [GHC] #7200: template-haskell-2.7.0.0 fails to build with GHC 7.0.4 due to missing pragma In-Reply-To: <044.3e99478eb756e411a5a6700a8a44d5a0@haskell.org> References: <044.3e99478eb756e411a5a6700a8a44d5a0@haskell.org> Message-ID: <059.7848e3c758b2b4784e8237ec3caf27ff@haskell.org> #7200: template-haskell-2.7.0.0 fails to build with GHC 7.0.4 due to missing pragma -------------------------------------+------------------------------------ Reporter: tibbe | Owner: duncan Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Template Haskell | Version: 7.0.4 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * status: new => closed * resolution: => wontfix Comment: 7.0.4 is quite old now and we have a way to make sure template-haskell doesn't get upgraded by cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 20:15:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 20:15:02 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops In-Reply-To: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> References: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> Message-ID: <059.e98b021c6ec746613e3e4633a8c6dfa6@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8157, #7883 -------------------------------------+------------------------------------ Changes (by tibbe): * status: new => closed * resolution: => fixed Comment: We added atomic primops for byte arrays (which can be used to implement a single cell mutable variable) in d8abf85f8ca176854e9d5d0b12371c4bc402aac3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 21:31:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 21:31:09 -0000 Subject: [GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico In-Reply-To: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> References: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> Message-ID: <063.4bb1bfa52d6e46a21c85a1b0b13cd11a@haskell.org> #9231: 7.8 regression in Read instance of Data.Fixed.Pico -------------------------------------+------------------------------------ Reporter: leonbaum2 | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"ec550e8f951e50fb91c89389e2e77a3358079c3a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ec550e8f951e50fb91c89389e2e77a3358079c3a" Fixup c1035d51e to behave more like in GHC 7.6 The fix in c1035d51e (addressing #9231) was done under the assumption that `Data.Fixed` is used only with power-of-10 `resolution`. This follow-up fixup changes the behavior to be more consistent with the previous behavior in GHC 7.6 For instance, for the following `B7` resolution > data B7 > instance HasResolution B7 where resolution _ = 128 After this patch, the following behavior is now observable: > 1.070 :: Fixed B7 1.062 > 1.062 :: Fixed B7 1.054 > read "1.070" :: Fixed B7 1.062 > read "1.062" :: Fixed B7 1.054 This doesn't provide the desirable "read . show == id" property yet (which didn't hold in GHC 7.6 either), but at least `fromRational` and `read` are consistent. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 24 22:09:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jun 2014 22:09:46 -0000 Subject: [GHC] #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) In-Reply-To: <050.ccaf00573c35157f252c17db26bcc258@haskell.org> References: <050.ccaf00573c35157f252c17db26bcc258@haskell.org> Message-ID: <065.9f33490ed4fa812a7dbf158c45d55897@haskell.org> #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) -------------------------------+------------------------------------------- Reporter: | Owner: jimenezrick | Status: patch Type: task | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/unix | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: POSIX | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by hvr): Could that maybe be filed as a PR at `unix`'s new upstream location at https://github.com/haskell/unix ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 25 00:01:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jun 2014 00:01:56 -0000 Subject: [GHC] #9236: hGetContents leads to late/silent failures In-Reply-To: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> References: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> Message-ID: <060.733b5387cbf1c32b5195b734f8be8ecd@haskell.org> #9236: hGetContents leads to late/silent failures -------------------------------+------------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by oerjan): * cc: oerjan (added) Comment: I think any error message should include the handle name. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 25 02:30:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jun 2014 02:30:36 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.92fd945ad7af830c0bd2964aa3b22190@haskell.org> #9200: Milner-Mycroft failure at the kind level ----------------------------------------------+---------------------------- Reporter: ekmett | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by goldfire): * owner: => goldfire Comment: Agreed. I'll fix this soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 25 08:31:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jun 2014 08:31:59 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.bfb922c792b9b948c8b1025c5ca23ba2@haskell.org> #8545: Reorganize Git repositories -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Trac & Git | Version: Resolution: | Keywords: git Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8251 -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"db19c665ec5055c2193b2174519866045aeff09a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="db19c665ec5055c2193b2174519866045aeff09a" Convert loose sub-repos into proper submodules (re #8545) Specifically, the following sub-repos/modules are converted: - libffi-tarballs - libraries/array - libraries/deepseq - libraries/directory - libraries/dph - libraries/filepath - libraries/haskell2010 - libraries/haskell98 - libraries/hoopl - libraries/hpc - libraries/old-locale - libraries/old-time - libraries/parallel - libraries/process - libraries/stm - libraries/unix - nofib - utils/hsc2hs N.B. ghc-tarballs is not converted as it will probably be handled differently in the future. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 25 09:23:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jun 2014 09:23:08 -0000 Subject: [GHC] #9237: GHC not recognizing "-llibrary" form in implicit linker scripts Message-ID: <051.f95f4904e896de4fcf955563f575c874@haskell.org> #9237: GHC not recognizing "-llibrary" form in implicit linker scripts ----------------------------------+--------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I have tried to build accelerate-llvm package and encountered an invalid behaviour of linker. I am using Arch Linux and GHC 7.8.2. I have installed llvm-general-3.4.2.2 and llvm-general-pure-3.4.2.2 from this branch: https://github.com/tvh/llvm- general/tree/curatedTargetMachine, and accelerate from HEAD to common sandbox. Then I tried to build accelerate-llvm using the sandbox and got this output during building: {{{ Building accelerate-llvm-0.15.0.0... Preprocessing library accelerate-llvm-0.15.0.0... [ 1 of 30] Compiling Data.Range.Range ( Data/Range/Range.hs, dist/build/Data/Range/Range.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package primitive-0.5.3.0 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package vector-0.10.11.0 ... linking ... done. Loading package mwc-random-0.13.1.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package transformers-0.4.1.0 ... linking ... done. Loading package mtl-2.2.1 ... linking ... done. Loading package text-1.1.1.3 ... linking ... done. Loading package parsec-3.1.5 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package setenv-0.1.1.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package llvm-general-pure-3.4.2.2 ... linking ... done. Loading package utf8-string-0.3.8 ... linking ... done. Loading package llvm-general-3.4.2.2 ... : can't load .so/.DLL for: /usr/lib/libcurses.so (-lncursesw: cannot open shared object file: No such file or directory) }}} After some searching I narrowed down the issue to `/usr/lib/libcurses.so` file. In Arch, this file contains `INPUT(-lncursesw)`. If I change it to `INPUT(libncursesw.so)` or `INPUT(/usr/lib/libncursesw.so)` it works fine. Symlinking `/usr/lib/libcurses.so` to `/usr/lib/libncursesw.so` also works. This bug seems to be connected to #2615. GHC still doesn't follow `INPUT` commands containing `-llibrary` form. Ld documentation allows this: {{{If you use `INPUT (-lfile)', ld will transform the name to libfile.a, as with the command line argument `-l'}}}. (https://sourceware.org/binutils/docs/ld/File-Commands.html) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 25 10:44:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jun 2014 10:44:39 -0000 Subject: [GHC] #9238: Negative zero broken Message-ID: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> #9238: Negative zero broken --------------------------+------------------------------------------------ Reporter: | Owner: augustss | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: | Operating System: Windows Compiler | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Try the following program {{{ compareDouble :: Double -> Double -> Ordering compareDouble x y = case (isNaN x, isNaN y) of (True, True) -> EQ (True, False) -> LT (False, True) -> GT (False, False) -> -- Make -0 less than 0 case (x == 0, y == 0, isNegativeZero x, isNegativeZero y) of (True, True, True, False) -> LT (True, True, False, True) -> GT _ -> x `compare` y main = do let l = [-0, 0] print [ (x, y, compareDouble x y) | x <- l, y <- l ] }}} Compile and run with -O0 {{{ $ ghc -O0 D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,EQ),(-0.0,0.0,LT),(0.0,-0.0,GT),(0.0,0.0,EQ)] }}} This is the correct output. Compile and run with -O1 {{{ $ ghc -O1 D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,LT),(-0.0,0.0,LT),(0.0,-0.0,EQ),(0.0,0.0,EQ)] }}} This is wrong. Put a NOINLINE pragma on compareDouble: {{{ $ ghc -O1 D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,EQ),(-0.0,0.0,EQ),(0.0,-0.0,EQ),(0.0,0.0,EQ)] }}} This is wrong in a different way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 25 10:46:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jun 2014 10:46:41 -0000 Subject: [GHC] #9238: Negative zero broken In-Reply-To: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> References: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> Message-ID: <062.a5c04ef77cd5468bbe9c03545868c640@haskell.org> #9238: Negative zero broken ------------------------------------------------+-------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by augustss): My guess is that this very function (which gives a total order to most doubles) is needed instead of ordinary comparison somewhere in the ghc optimizer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 25 11:07:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jun 2014 11:07:10 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.883fd836d65927cc723f6415d6e0c042@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC ---------------------------------+------------------------------------ Reporter: komadori | Owner: komadori Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #3390 ---------------------------------+------------------------------------ Changes (by niklasl): * cc: niklasl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 25 12:39:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jun 2014 12:39:15 -0000 Subject: [GHC] #9237: GHC not recognizing "-llibrary" form in implicit linker scripts In-Reply-To: <051.f95f4904e896de4fcf955563f575c874@haskell.org> References: <051.f95f4904e896de4fcf955563f575c874@haskell.org> Message-ID: <066.b988f271456934fc41f4fbf7bf6bbd41@haskell.org> #9237: GHC not recognizing "-llibrary" form in implicit linker scripts ---------------------------------------+---------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by rwbarton): I think GHC is trying to load `/usr/lib/libcurses.so` at runtime with `dlopen`, in order to run Template Haskell code in `Data.Range.Range`. It's not trying to link it with `ld`. So, this is a limitation of the system `dlopen`, and we are in "workaround" territory. (Incidentally, my `dlopen` on Debian (libc 2.18-4) doesn't seem to handle either `INPUT(-llibrary)` or `INPUT(filename)`.) #2615 was from when GHC used its own custom loader rather than `dlopen`. I'm not eager to bring any of that back, but I guess we could try to detect a linker script if `dlopen` fails. One thing (well, two things) I don't understand is where the dependency on `/usr/lib/libcurses.so` is coming from, and what kind of dependency it is exactly. Who is loading `/usr/lib/libcurses.so`: does `dlopen` load dependencies for us, or do we track them ourselves and load them first? Maybe we can arrange things when we build the `llvm-general-3.4.2.2` library so that the dependency is on the real shared object `/usr/lib/libncursesw.so`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 25 13:16:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jun 2014 13:16:30 -0000 Subject: [GHC] #9237: GHC not recognizing "-llibrary" form in implicit linker scripts In-Reply-To: <051.f95f4904e896de4fcf955563f575c874@haskell.org> References: <051.f95f4904e896de4fcf955563f575c874@haskell.org> Message-ID: <066.55bdd5459a3f0ed852b5418068367f79@haskell.org> #9237: GHC not recognizing "-llibrary" form in implicit linker scripts ---------------------------------------+---------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by rwbarton): Oh, hmm, I actually looked at the code and we do already inspect the error string from `dlopen` and try to parse a linker script. The problem is that we don't support `INPUT(-llibrary)`. I guess we can transform the name to `liblibrary.so` in that case? I still would like to avoid incurring dependencies on `.so`s that are really linker scripts, if possible... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 25 13:29:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jun 2014 13:29:31 -0000 Subject: [GHC] #9239: Program loops in syscall retries cancelled by rt_sigreturn signal Message-ID: <043.432cfdf14af4d214dca435423373e311@haskell.org> #9239: Program loops in syscall retries cancelled by rt_sigreturn signal --------------------------+------------------------------------------------ Reporter: k-bx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Sorry if this bug is not related to ghc, but it seems to me that it might be. Originally I reported it against hedis package, you can find description in it's bug tracker https://github.com/informatikr/hedis/issues/15 Short recap: one specific operation against redis database (zrangebyscoreLimit against big ZSET), program behaves differently. For me, most of the time it would hang, sometimes it succeeds, sometimes outputs "ConnectionLost" twice and dies. My environments are: Ubuntu 12.04/14.04, redis versions tested are 2.2 through 2.8 (latest in each even branch). Under GHC 7.6 and profiling enabled, strace would end up showing an infinite loop of these operations: {{{ --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, si_value=0} --- rt_sigreturn() = -1 EINTR (Interrupted system call) select(4, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be restarted if no handler) }}} Under 7.8.2 profiling enabled, it would also loop, but in few seconds it would hang, produring these last lines of output (plus result of Ctrl+C): {{{ select(4, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be restarted if no handler) --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, si_value=0} --- timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 rt_sigreturn() = -1 EINTR (Interrupted system call) select(4, [3], [], NULL, NULL^CProcess 16483 detached }}} With profiling disabled on 7.8.2 it would sometimes hang same way as with profiling, but sometimes it would finish with outputting "ConnectionLost" errors (you can find links to full strace output in github hedis issue page linked above). Sorry again if it's not related to GHC, meanwhile I'll try to investigate further. Thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 25 17:24:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jun 2014 17:24:09 -0000 Subject: [GHC] #9239: Program loops in syscall retries cancelled by rt_sigreturn signal In-Reply-To: <043.432cfdf14af4d214dca435423373e311@haskell.org> References: <043.432cfdf14af4d214dca435423373e311@haskell.org> Message-ID: <058.3d94a795f3b770bc1c093cd7ae4f508a@haskell.org> #9239: Program loops in syscall retries cancelled by rt_sigreturn signal ------------------------------------------------+-------------------------- Reporter: k-bx | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by k-bx): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 25 17:28:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jun 2014 17:28:09 -0000 Subject: [GHC] #9239: Program loops in syscall retries cancelled by rt_sigreturn signal In-Reply-To: <043.432cfdf14af4d214dca435423373e311@haskell.org> References: <043.432cfdf14af4d214dca435423373e311@haskell.org> Message-ID: <058.0f36ea03e316e5242e5715ccafc3ddc9@haskell.org> #9239: Program loops in syscall retries cancelled by rt_sigreturn signal ------------------------------------------------+-------------------------- Reporter: k-bx | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by k-bx): I thought about it a little and decided that it's best to only submit a ticket after I'll reproduce something with smallest possible program. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 25 20:27:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jun 2014 20:27:01 -0000 Subject: [GHC] #9112: support for deriving Vector/MVector instances In-Reply-To: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> References: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> Message-ID: <060.6ced7edf64d0f8b437a38febcc5d3c37@haskell.org> #9112: support for deriving Vector/MVector instances -------------------------------------+------------------------------------ Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): Replying to [comment:6 bitemyapp]: > I am trying to build hackage-server on Mac OS X with GHC 7.8 and I was told this ticket is relevant to my problems. > > I've included the build error in this comment. [...] These ''specific'' errors are easy to fix. `VecBase.MVector` (hereafter abbreviated `MVector`) is a standalone data family. There is an instance `MVector s Word32`, but no instance for the new type `MVector s DocId`. GHC 7.6.3 did not care at all about this when producing an instance `VecMut.MVector MVector DocId` with generalized newtype deriving, which is totally bogus because the derived instance has methods like `basicLength` of type `MVector s DocId -> Int`, even though there is no type `MVector s DocId` at all! A client can then define a mismatched instance `data instance MVector s DocId = Foo Char`, which will effectively be unsafely coerced to `MVector s Word32`, leading to undefined behavior (most likely a segfault). GHC 7.8 actually pays attention to what is going on here. To satisfy it all you need to do is define an instance for the data family in a way such that `MVector s DocId` is actually coercible to `MVector s Word32`. For example, `newtype instance MVector s DocId = DocVector (MVector s Word32)` will do the job. (Then you will want an instance for `VecBase.Vector`, too.) However, you will then immediately run into the other error involving the role of the parameter to `m` in the types of the other methods of `VecMut.MVector`, as discussed above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 02:33:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 02:33:01 -0000 Subject: [GHC] #9212: Cleanup of sync-all In-Reply-To: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> References: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> Message-ID: <060.6dd5d5bfe388af3ece2efeb31871ae1e@haskell.org> #9212: Cleanup of sync-all -------------------------------------+------------------------------------ Reporter: thomie | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): The patches themselves look good, judging from reading. But there are problems: {{{ $ git clone ~/build/haskell/ghc $ cd ghc $ ./sync-all get == running git config core.ignorecase true == running git submodule init Submodul 'libffi-tarballs' (/home/jojo/build/haskell/libffi-tarballs.git) f?r Pfad 'libffi-tarballs' in die Konfiguration eingetragen. Submodul 'libraries/Cabal' (/home/jojo/build/haskell/packages/Cabal.git) f?r Pfad 'libraries/Cabal' in die Konfiguration eingetragen. Submodul 'libraries/Win32' (/home/jojo/build/haskell/packages/Win32.git) f?r Pfad 'libraries/Win32' in die Konfiguration eingetragen. Submodul 'libraries/array' (/home/jojo/build/haskell/packages/array.git) f?r Pfad 'libraries/array' in die Konfiguration eingetragen. Submodul 'libraries/binary' (/home/jojo/build/haskell/packages/binary.git) f?r Pfad 'libraries/binary' in die Konfiguration eingetragen. Submodul 'libraries/bytestring' (/home/jojo/build/haskell/packages/bytestring.git) f?r Pfad 'libraries/bytestring' in die Konfiguration eingetragen. Submodul 'libraries/containers' (/home/jojo/build/haskell/packages/containers.git) f?r Pfad 'libraries/containers' in die Konfiguration eingetragen. Submodul 'libraries/deepseq' (/home/jojo/build/haskell/packages/deepseq.git) f?r Pfad 'libraries/deepseq' in die Konfiguration eingetragen. Submodul 'libraries/directory' (/home/jojo/build/haskell/packages/directory.git) f?r Pfad 'libraries/directory' in die Konfiguration eingetragen. Submodul 'libraries/dph' (/home/jojo/build/haskell/packages/dph.git) f?r Pfad 'libraries/dph' in die Konfiguration eingetragen. Submodul 'libraries/filepath' (/home/jojo/build/haskell/packages/filepath.git) f?r Pfad 'libraries/filepath' in die Konfiguration eingetragen. Submodul 'libraries/haskeline' (/home/jojo/build/haskell/packages/haskeline.git) f?r Pfad 'libraries/haskeline' in die Konfiguration eingetragen. Submodul 'libraries/haskell2010' (/home/jojo/build/haskell/packages/haskell2010.git) f?r Pfad 'libraries/haskell2010' in die Konfiguration eingetragen. Submodul 'libraries/haskell98' (/home/jojo/build/haskell/packages/haskell98.git) f?r Pfad 'libraries/haskell98' in die Konfiguration eingetragen. Submodul 'libraries/hoopl' (/home/jojo/build/haskell/packages/hoopl.git) f?r Pfad 'libraries/hoopl' in die Konfiguration eingetragen. Submodul 'libraries/hpc' (/home/jojo/build/haskell/packages/hpc.git) f?r Pfad 'libraries/hpc' in die Konfiguration eingetragen. Submodul 'libraries/old-locale' (/home/jojo/build/haskell/packages/old- locale.git) f?r Pfad 'libraries/old-locale' in die Konfiguration eingetragen. Submodul 'libraries/old-time' (/home/jojo/build/haskell/packages/old- time.git) f?r Pfad 'libraries/old-time' in die Konfiguration eingetragen. Submodul 'libraries/parallel' (/home/jojo/build/haskell/packages/parallel.git) f?r Pfad 'libraries/parallel' in die Konfiguration eingetragen. Submodul 'libraries/pretty' (/home/jojo/build/haskell/packages/pretty.git) f?r Pfad 'libraries/pretty' in die Konfiguration eingetragen. Submodul 'libraries/primitive' (/home/jojo/build/haskell/packages/primitive.git) f?r Pfad 'libraries/primitive' in die Konfiguration eingetragen. Submodul 'libraries/process' (/home/jojo/build/haskell/packages/process.git) f?r Pfad 'libraries/process' in die Konfiguration eingetragen. Submodul 'libraries/random' (/home/jojo/build/haskell/packages/random.git) f?r Pfad 'libraries/random' in die Konfiguration eingetragen. Submodul 'libraries/stm' (/home/jojo/build/haskell/packages/stm.git) f?r Pfad 'libraries/stm' in die Konfiguration eingetragen. Submodul 'libraries/terminfo' (/home/jojo/build/haskell/packages/terminfo.git) f?r Pfad 'libraries/terminfo' in die Konfiguration eingetragen. Submodul 'libraries/time' (/home/jojo/build/haskell/packages/time.git) f?r Pfad 'libraries/time' in die Konfiguration eingetragen. Submodul 'libraries/transformers' (/home/jojo/build/haskell/packages/transformers.git) f?r Pfad 'libraries/transformers' in die Konfiguration eingetragen. Submodul 'libraries/unix' (/home/jojo/build/haskell/packages/unix.git) f?r Pfad 'libraries/unix' in die Konfiguration eingetragen. Submodul 'libraries/vector' (/home/jojo/build/haskell/packages/vector.git) f?r Pfad 'libraries/vector' in die Konfiguration eingetragen. Submodul 'libraries/xhtml' (/home/jojo/build/haskell/packages/xhtml.git) f?r Pfad 'libraries/xhtml' in die Konfiguration eingetragen. Submodul 'nofib' (/home/jojo/build/haskell/nofib.git) f?r Pfad 'nofib' in die Konfiguration eingetragen. Submodul 'utils/haddock' (/home/jojo/build/haskell/haddock.git) f?r Pfad 'utils/haddock' in die Konfiguration eingetragen. Submodul 'utils/hsc2hs' (/home/jojo/build/haskell/hsc2hs.git) f?r Pfad 'utils/hsc2hs' in die Konfiguration eingetragen. == running git config submodule.libraries/Cabal.url /home/jojo/build/haskell/ghc/libraries/Cabal == running git config submodule.libraries/Win32.url /home/jojo/build/haskell/ghc/libraries/Win32 == running git config submodule.libraries/array.url /home/jojo/build/haskell/ghc/libraries/array == running git config submodule.libraries/binary.url /home/jojo/build/haskell/ghc/libraries/binary == running git config submodule.libraries/bytestring.url /home/jojo/build/haskell/ghc/libraries/bytestring == running git config submodule.libraries/containers.url /home/jojo/build/haskell/ghc/libraries/containers == running git config submodule.libraries/deepseq.url /home/jojo/build/haskell/ghc/libraries/deepseq == running git config submodule.libraries/directory.url /home/jojo/build/haskell/ghc/libraries/directory == running git config submodule.libraries/filepath.url /home/jojo/build/haskell/ghc/libraries/filepath == running git config submodule.libraries/haskeline.url /home/jojo/build/haskell/ghc/libraries/haskeline == running git config submodule.libraries/haskell2010.url /home/jojo/build/haskell/ghc/libraries/haskell2010 == running git config submodule.libraries/haskell98.url /home/jojo/build/haskell/ghc/libraries/haskell98 == running git config submodule.libraries/hoopl.url /home/jojo/build/haskell/ghc/libraries/hoopl == running git config submodule.libraries/hpc.url /home/jojo/build/haskell/ghc/libraries/hpc == running git config submodule.libraries/old-locale.url /home/jojo/build/haskell/ghc/libraries/old-locale == running git config submodule.libraries/old-time.url /home/jojo/build/haskell/ghc/libraries/old-time == running git config submodule.libraries/pretty.url /home/jojo/build/haskell/ghc/libraries/pretty == running git config submodule.libraries/primitive.url /home/jojo/build/haskell/ghc/libraries/primitive == running git config submodule.libraries/process.url /home/jojo/build/haskell/ghc/libraries/process == running git config submodule.libraries/random.url /home/jojo/build/haskell/ghc/libraries/random == running git config submodule.libraries/terminfo.url /home/jojo/build/haskell/ghc/libraries/terminfo == running git config submodule.libraries/time.url /home/jojo/build/haskell/ghc/libraries/time == running git config submodule.libraries/transformers.url /home/jojo/build/haskell/ghc/libraries/transformers == running git config submodule.libraries/unix.url /home/jojo/build/haskell/ghc/libraries/unix == running git config submodule.libraries/vector.url /home/jojo/build/haskell/ghc/libraries/vector == running git config submodule.libraries/xhtml.url /home/jojo/build/haskell/ghc/libraries/xhtml == running git config submodule.utils/haddock.url /home/jojo/build/haskell/ghc/utils/haddock == running git config submodule.utils/hsc2hs.url /home/jojo/build/haskell/ghc/utils/hsc2hs == running git submodule update fatal: Repository '/home/jojo/build/haskell/libffi-tarballs.git' existiert nicht. Klonen von '/home/jojo/build/haskell/libffi-tarballs.git' in Submodul-Pfad 'libffi-tarballs' fehlgeschlagen git failed: 256 at ./sync-all line 113. }}} But then, this problem is already there without your patches... anyways, can you fix that on your branch? I?ll then run a few simple tests and merge your patches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 02:54:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 02:54:25 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.ef6f5fad9a88000dfcc3c834c2702cac@haskell.org> #8545: Reorganize Git repositories -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Trac & Git | Version: Resolution: | Keywords: git Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8251 -------------------------------------+------------------------------------ Comment (by Thomas Miedema ): In [changeset:"72fe49d88565fc1dd807a0e185a5aa6fc4989ea0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="72fe49d88565fc1dd807a0e185a5aa6fc4989ea0" sync-all: infer remotepath from .gitmodules file After this commit, running `sync-all remote set-url` works properly for the haddock package: command: ./sync-all -r git://git.haskell.org remote set-url origin before: git://git.haskell.org/packages/haddock.git after: git://git.haskell.org/haddock.git By doing the `remotepath` lookup before the `$is_github_repo` check, running `sync-all remote set-url` now also works properly for submodule repos on github: command: ./sync-all -r git://github.com/ghc remote set-url origin before: git://github.com/ghc/packages/binary after: git://github.com/ghc/packages-binary * Relevant prior commits: 4f4357 "Make `sync-all remote set-url` use normalized `/packages/` urls" 34b072 "Convert haddock into a proper submodule (re #8545)" 974a97 "sync-all: Apply submodule url rewriting also to stuff in util/" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 02:54:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 02:54:25 -0000 Subject: [GHC] #9212: Cleanup of sync-all In-Reply-To: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> References: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> Message-ID: <060.7d1987b8ba56f39fe8fc32882f799635@haskell.org> #9212: Cleanup of sync-all -------------------------------------+------------------------------------ Reporter: thomie | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"c61260e0f716c32334ef32c759616f12f49b579e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c61260e0f716c32334ef32c759616f12f49b579e" Merge Thomas Miedema?s syn-all improvments as submitted on #9212. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 02:54:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 02:54:57 -0000 Subject: [GHC] #9212: Cleanup of sync-all In-Reply-To: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> References: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> Message-ID: <060.51d140a26a40c4cf53efdba6106dbc66@haskell.org> #9212: Cleanup of sync-all -------------------------------------+------------------------------------ Reporter: thomie | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Nevermind, fixed these problems myself and now your commits look good. Thanks for your contribution! If you could continue to keep an eye on `./sync-all`, that?d be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 02:55:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 02:55:04 -0000 Subject: [GHC] #9212: Cleanup of sync-all In-Reply-To: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> References: <045.18f69a28effee485bf387e5f5147a4e3@haskell.org> Message-ID: <060.2d300a3201252f8ff68ef0c4b5d16393@haskell.org> #9212: Cleanup of sync-all -------------------------------------+------------------------------------ Reporter: thomie | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 08:43:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 08:43:59 -0000 Subject: =?utf-8?b?W0dIQ10gIzkyNDA6ICJyZWFkIC4gc2hvdyDiiaEgaWQiIG5vdCBz?= =?utf-8?q?atisfied_by_Data=2EFixed?= Message-ID: <042.bb0c4150424061c49087c6a88d193db3@haskell.org> #9240: "read . show ? id" not satisfied by Data.Fixed ------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9213 | ------------------------------------+------------------------------------- As pointed out in #9213, the desired property "read . show ? id" is not satisfied for all resolutions. For instance, consider the following example: {{{ > data B7 > instance HasResolution B7 where resolution _ = 128 > 1.070 :: Fixed B7 1.062 > 1.062 :: Fixed B7 1.054 > read "1.070" :: Fixed B7 1.062 > read "1.062" :: Fixed B7 1.054 }}} This behaviour can be reproduced all the way back to GHC 7.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 08:46:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 08:46:25 -0000 Subject: [GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico In-Reply-To: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> References: <048.014ccbcfb3eb5c0719498f9730abfe14@haskell.org> Message-ID: <063.7a27a43b1a0db974e84f0a8c39fe0d8c@haskell.org> #9231: 7.8 regression in Read instance of Data.Fixed.Pico -------------------------------------+------------------------------------ Reporter: leonbaum2 | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.3 Component: libraries/base | Version: 7.8.2 Resolution: fixed | Keywords: regression Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9240 #7483 -------------------------------------+------------------------------------ Changes (by hvr): * status: merge => closed * resolution: => fixed * related: => #9240 #7483 Comment: The fix for the regression has been merged to ghc-7.8 via [99462b6877308003442942cbddb3296f29cfb9a8/base] and [4254e158e05ac86b922dea6ba3c3c330732d991b/base]. The remaining "read . show == id" has been moved into a ticket of its own (#9240) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 08:51:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 08:51:29 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5MjQwOiAicmVhZCAuIHNob3cg4omhIGlkIiBu?= =?utf-8?q?ot_satisfied_by_Data=2EFixed?= In-Reply-To: <042.bb0c4150424061c49087c6a88d193db3@haskell.org> References: <042.bb0c4150424061c49087c6a88d193db3@haskell.org> Message-ID: <057.1c900d35acc90569f51fe9426f45a3b0@haskell.org> #9240: "read . show ? id" not satisfied by Data.Fixed -------------------------------------+------------------------------------ Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9231 -------------------------------------+------------------------------------ Changes (by hvr): * related: #9213 => #9231 Old description: > As pointed out in #9213, the desired property "read . show ? id" is not > satisfied for all resolutions. For instance, consider the following > example: > > {{{ > > data B7 > > instance HasResolution B7 where resolution _ = 128 > > > 1.070 :: Fixed B7 > 1.062 > > 1.062 :: Fixed B7 > 1.054 > > > read "1.070" :: Fixed B7 > 1.062 > > read "1.062" :: Fixed B7 > 1.054 > }}} > > This behaviour can be reproduced all the way back to GHC 7.2.1 New description: As pointed out in #9231, the desired property "read . show ? id" is not satisfied for all resolutions. For instance, consider the following example: {{{#!hs > data B7 > instance HasResolution B7 where resolution _ = 128 > 1.070 :: Fixed B7 1.062 > 1.062 :: Fixed B7 1.054 > read "1.070" :: Fixed B7 1.062 > read "1.062" :: Fixed B7 1.054 }}} This behaviour can be reproduced all the way back to GHC 7.2.1 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 12:21:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 12:21:08 -0000 Subject: [GHC] #9241: Add a"same" function to Data.Eq Message-ID: <047.b99c525811fd7638f7969203c831dc33@haskell.org> #9241: Add a"same" function to Data.Eq ------------------------------------+------------------------------------- Reporter: mhwombat | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Prelude | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Add a"same" function to Data.Eq that parallels the "comparing" function in Data.Ord. For example: -- | -- > same p x y = (p x) == (p y) -- -- Useful combinator for use in conjunction with the @xxxBy@ family -- of functions from "Data.List", for example: -- -- > ... groupBy (same fst) ... same :: (Eq a) => (b -> a) -> b -> b -> Bool same p x y = (p x) == (p y) For a closer parallel, I suppose "same" could return "Equality" (similar to "Ordering"), and the functions "nubBy", "deleteBy", "deleteFirstsBy", "unionBy", "intersectBy" and "groupBy" should take (a -> a -> Equality) (a -> a -> Bool). But I don't know if there's any benefit to that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 14:05:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 14:05:22 -0000 Subject: [GHC] #9241: Add a"same" function to Data.Eq In-Reply-To: <047.b99c525811fd7638f7969203c831dc33@haskell.org> References: <047.b99c525811fd7638f7969203c831dc33@haskell.org> Message-ID: <062.ba31a65245e3c69c8abfdb3aa2fda227@haskell.org> #9241: Add a"same" function to Data.Eq -------------------------------------+------------------------------------ Reporter: mhwombat | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * cc: hvr, ekmett (added) * component: Prelude => libraries/base Old description: > Add a"same" function to Data.Eq that parallels the "comparing" function > in Data.Ord. For example: > > -- | > -- > same p x y = (p x) == (p y) > -- > -- Useful combinator for use in conjunction with the @xxxBy@ family > -- of functions from "Data.List", for example: > -- > -- > ... groupBy (same fst) ... > same :: (Eq a) => (b -> a) -> b -> b -> Bool > same p x y = (p x) == (p y) > > For a closer parallel, I suppose "same" could return "Equality" (similar > to "Ordering"), and the functions "nubBy", "deleteBy", "deleteFirstsBy", > "unionBy", "intersectBy" and "groupBy" should take (a -> a -> Equality) > (a -> a -> Bool). But I don't know if there's any benefit to that. New description: Add a"same" function to Data.Eq that parallels the "comparing" function in Data.Ord. For example: {{{#!hs -- | -- > same p x y = (p x) == (p y) -- -- Useful combinator for use in conjunction with the @xxxBy@ family -- of functions from "Data.List", for example: -- -- > ... groupBy (same fst) ... same :: (Eq a) => (b -> a) -> b -> b -> Bool same p x y = (p x) == (p y) }}} For a closer parallel, I suppose "same" could return "Equality" (similar to "Ordering"), and the functions "nubBy", "deleteBy", "deleteFirstsBy", "unionBy", "intersectBy" and "groupBy" should take (a -> a -> Equality) (a -> a -> Bool). But I don't know if there's any benefit to that. -- Comment: What's the benefit of `same p` over {{{(==) `on` p}}}? {{{#!hs ((==) `on`) :: Eq b => (a -> b) -> a -> a -> Bool }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 14:25:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 14:25:42 -0000 Subject: [GHC] #9241: Add a"same" function to Data.Eq In-Reply-To: <047.b99c525811fd7638f7969203c831dc33@haskell.org> References: <047.b99c525811fd7638f7969203c831dc33@haskell.org> Message-ID: <062.4ba7168eb79175a9177112bf6bad133e@haskell.org> #9241: Add a"same" function to Data.Eq -------------------------------------+------------------------------------ Reporter: mhwombat | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): Additions to base should go through the http://www.haskell.org/haskellwiki/Library_submissions process. Also, see #979 which suggests adding the same function under the name `equating`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 14:40:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 14:40:34 -0000 Subject: [GHC] #9241: Add a"same" function to Data.Eq In-Reply-To: <047.b99c525811fd7638f7969203c831dc33@haskell.org> References: <047.b99c525811fd7638f7969203c831dc33@haskell.org> Message-ID: <062.7e9a3440e97ca0d80d2a321dfba00db7@haskell.org> #9241: Add a"same" function to Data.Eq -------------------------------------+------------------------------------ Reporter: mhwombat | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ekmett): I agree that this should go through the libraries@ process. For the record I'm also on the `equating` bandwagon, but keep in mind `comparing` was created before `on` was discovered, so when this has come up for discussion before `comparing` was being left around as a historical artifact than as a model to copy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 14:41:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 14:41:25 -0000 Subject: [GHC] #3032: would be nice if -fno-code and --make worked together In-Reply-To: <045.95d90490c3a839988666e452fac25300@haskell.org> References: <045.95d90490c3a839988666e452fac25300@haskell.org> Message-ID: <060.6680ec4a293523105e491d27e094d8b6@haskell.org> #3032: would be nice if -fno-code and --make worked together -------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: I think this works now, modulo Cabal support: {{{ ezyang at sabre:~/Dev/labs$ cabal unpack parsec cd Unpacking to parsec-3.1.5/ ezyang at sabre:~/Dev/labs$ cd parsec-3.1.5/ ezyang at sabre:~/Dev/labs/parsec-3.1.5$ cabal configure --ghc-option=-fno- code Resolving dependencies... Configuring parsec-3.1.5... ezyang at sabre:~/Dev/labs/parsec-3.1.5$ time cabal build Building parsec-3.1.5... Preprocessing library parsec-3.1.5... [ 1 of 25] Compiling Text.Parsec.Pos ( Text/Parsec/Pos.hs, nothing ) [ 2 of 25] Compiling Text.Parsec.Error ( Text/Parsec/Error.hs, nothing ) [ 3 of 25] Compiling Text.ParserCombinators.Parsec.Error ( Text/ParserCombinators/Parsec/Error.hs, nothing ) [ 4 of 25] Compiling Text.ParserCombinators.Parsec.Pos ( Text/ParserCombinators/Parsec/Pos.hs, nothing ) [ 5 of 25] Compiling Text.Parsec.Prim ( Text/Parsec/Prim.hs, nothing ) [ 6 of 25] Compiling Text.Parsec.Char ( Text/Parsec/Char.hs, nothing ) [ 7 of 25] Compiling Text.Parsec.Combinator ( Text/Parsec/Combinator.hs, nothing ) [ 8 of 25] Compiling Text.ParserCombinators.Parsec.Combinator ( Text/ParserCombinators/Parsec/Combinator.hs, nothing ) [ 9 of 25] Compiling Text.Parsec.String ( Text/Parsec/String.hs, nothing ) [10 of 25] Compiling Text.ParserCombinators.Parsec.Char ( Text/ParserCombinators/Parsec/Char.hs, nothing ) [11 of 25] Compiling Text.Parsec.ByteString ( Text/Parsec/ByteString.hs, nothing ) [12 of 25] Compiling Text.Parsec.ByteString.Lazy ( Text/Parsec/ByteString/Lazy.hs, nothing ) [13 of 25] Compiling Text.Parsec.Text ( Text/Parsec/Text.hs, nothing ) [14 of 25] Compiling Text.Parsec.Text.Lazy ( Text/Parsec/Text/Lazy.hs, nothing ) [15 of 25] Compiling Text.Parsec.Token ( Text/Parsec/Token.hs, nothing ) [16 of 25] Compiling Text.ParserCombinators.Parsec.Token ( Text/ParserCombinators/Parsec/Token.hs, nothing ) [17 of 25] Compiling Text.Parsec.Expr ( Text/Parsec/Expr.hs, nothing ) [18 of 25] Compiling Text.ParserCombinators.Parsec.Prim ( Text/ParserCombinators/Parsec/Prim.hs, nothing ) [19 of 25] Compiling Text.ParserCombinators.Parsec ( Text/ParserCombinators/Parsec.hs, nothing ) [20 of 25] Compiling Text.ParserCombinators.Parsec.Expr ( Text/ParserCombinators/Parsec/Expr.hs, nothing ) [21 of 25] Compiling Text.Parsec ( Text/Parsec.hs, nothing ) [22 of 25] Compiling Text.Parsec.Language ( Text/Parsec/Language.hs, nothing ) [23 of 25] Compiling Text.ParserCombinators.Parsec.Language ( Text/ParserCombinators/Parsec/Language.hs, nothing ) [24 of 25] Compiling Text.Parsec.Perm ( Text/Parsec/Perm.hs, nothing ) [25 of 25] Compiling Text.ParserCombinators.Parsec.Perm ( Text/ParserCombinators/Parsec/Perm.hs, nothing ) /usr/bin/ar: dist/build/Text/Parsec.o: No such file or directory real 0m2.110s user 0m1.682s sys 0m0.281s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 15:03:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 15:03:34 -0000 Subject: [GHC] #3032: would be nice if -fno-code and --make worked together In-Reply-To: <045.95d90490c3a839988666e452fac25300@haskell.org> References: <045.95d90490c3a839988666e452fac25300@haskell.org> Message-ID: <060.9514e9574f60f3bc7235b43a1c2db2b2@haskell.org> #3032: would be nice if -fno-code and --make worked together -------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): To make it work with Cabal we need to make -no-code a Cabal flag (that gets converted to a GHC flag). Right now it's opaque to Cabal what's going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 21:31:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 21:31:04 -0000 Subject: [GHC] #1487: unix package: test needed for getLoginName In-Reply-To: <047.1ef8c4d73f5dccee00ba133a94dc0060@haskell.org> References: <047.1ef8c4d73f5dccee00ba133a94dc0060@haskell.org> Message-ID: <062.bc37b5a833bf71d8019eaebc4fcd4fac@haskell.org> #1487: unix package: test needed for getLoginName -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thomie Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: libraries/unix | Version: 6.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thomie): * owner: adrien => thomie -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 22:15:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 22:15:42 -0000 Subject: [GHC] #1487: unix package: test needed for getLoginName In-Reply-To: <047.1ef8c4d73f5dccee00ba133a94dc0060@haskell.org> References: <047.1ef8c4d73f5dccee00ba133a94dc0060@haskell.org> Message-ID: <062.bbd726c85a18b55347c6229c47d60db0@haskell.org> #1487: unix package: test needed for getLoginName -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thomie Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: libraries/unix | Version: 6.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thomie): The attached patch fixes this issue. I tried going the pseudo-terminal route, but it doesn't work. System.Posix.User's `getLoginName` calls the C function `getlogin`. This function, on GNU/Linux at least, looks in the file /var/run/utmp for a login record with a tty name that matches that of the terminal connected to stdin (filedescriptor 0). It is possible to trick `getlogin` to check a pseudo terminal's name with something like: (master, slave) <- openPseudoTerminal dupTo master stdInput But, as far as I understand, pseudo-terminals are never registered in /var/run/utmp. Therefore `getlogin` will not find the user's login name and just return 'No such file or directory'. Maybe better than 'Inappropriate ioctl for device', but still an error. What does work, surprisingly, is adding this to `user001.hs`: dupTo stdOutput stdInput , but only if we wouldn't redirect stdout as well. The same for stderr. The solution is to simply not redirect stdin (i.e. don't do ./user001 < /dev/null). This implies skipping the ghci way. The commit that introduced the `no_stdin` test option alluded to this as well: fa52a8c9d8eae5e3fc4c0cf0e5672875e161e05c. One general concern is that there are no guarantees that `getlogin` will return anything other than NULL, so the test with this patch applied might fail on some systems. Another option therefore would be to turn the getLoginName test back off again, document why, and close this issue regardless. Review of -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 26 22:16:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jun 2014 22:16:42 -0000 Subject: [GHC] #1487: unix package: test needed for getLoginName In-Reply-To: <047.1ef8c4d73f5dccee00ba133a94dc0060@haskell.org> References: <047.1ef8c4d73f5dccee00ba133a94dc0060@haskell.org> Message-ID: <062.4bbb50e3e105847f46854d05d30dd505@haskell.org> #1487: unix package: test needed for getLoginName -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thomie Type: bug | Status: patch Priority: lowest | Milestone: Component: libraries/unix | Version: Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * version: 6.6.1 => * milestone: 7.6.2 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 07:24:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 07:24:04 -0000 Subject: [GHC] #8293: user001 spuriously fails if getGroupEntryForID correctly fails In-Reply-To: <045.bf4c709250a72368e2867943f2aa3774@haskell.org> References: <045.bf4c709250a72368e2867943f2aa3774@haskell.org> Message-ID: <060.450f49bdaf0a02fee256c92cbbbc9e42@haskell.org> #8293: user001 spuriously fails if getGroupEntryForID correctly fails ------------------------------------------------+-------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: libraries/unix | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: user001 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1487 ------------------------------------------------+-------------------------- Changes (by thomie): * related: => #1487 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 07:24:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 07:24:42 -0000 Subject: [GHC] #1487: unix package: test needed for getLoginName In-Reply-To: <047.1ef8c4d73f5dccee00ba133a94dc0060@haskell.org> References: <047.1ef8c4d73f5dccee00ba133a94dc0060@haskell.org> Message-ID: <062.eddbc4724030054316601ee2156d2d1e@haskell.org> #1487: unix package: test needed for getLoginName -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thomie Type: bug | Status: patch Priority: lowest | Milestone: Component: libraries/unix | Version: Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #8293 -------------------------------------+------------------------------------- Changes (by thomie): * related: => #8293 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 07:44:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 07:44:22 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas Message-ID: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The language extensions `-XIncoherentInstances` and `-XOverlappingInstances` (described in [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap the user manual]) apply to every instance declaration in the module. Internally, however, GHC records this information on a per-instance-declaration basis. It would be much better for the programmer to be able to control these matters on a per-instance-declaration basis. Thus: {{{ instance Show a => Show [a] where {-# OVERLAPPABLE #-} ... instance Show [Char] where ... }}} We came across the need for this when discussing the `Typeable` instances. We have a generic instance like this: {{{ instance (Typeable f, Typeable a) => Typeable (f a) where .... }}} but also want {{{ instance KnownNat n => Typeable (n :: Nat) where ... }}} If we seek `(Typeable (x::Nat))`, we should pick the second instance even though in principle you might imagine that `x` might be instantiated to `(f a)`, for some `f` and `a`. But we know that there are no type constructors `f` of kind `blah -> Nat`, so this can never happen and it's safe to pick the second instance. So a local `{-# INCOHERENT #-}` pragma for this particular instance declaration would be very useful to express this fact. {{{ instance KnownNat n => Typeable (n :: Nat) where {-# INCOHERENT #-} ... }}} Quite apart from this special case, it's plain better to have per-instance control * Rather than a remote per-module flag, the pragma draws attention that ''this particular instance'' is incoherent, overlappable or whatever. * The current situation almost certainly means that more instances are marked overlapping than are really necessary. I have some design questions. * Where should the pragma appear, syntactically? {{{ instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... or instance Show a => Show [a] {-# OVERLAPPABLE #-} where ... or instance Show a => Show [a] where {-# OVERLAPPABLE #-} }}} Remember that `SPECIALISE INSTANCE` pragmas appear in the third of the above positions, so I mildly favour that. * The user manual (link above) allows overlap if ''either'' instance is compiled with `-XOverlappingInstances` (see the rules towards the end of [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap 7.6.3.5). It would be more explicit to have two pragmas, one to say "I can be overlapped" and one to say "I can overlap something else". The rule would then be that "either IX is marked `{-# OVERLAPPABLE #-}` or IY is marked `{-# OVERLAPPING #-}`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 07:44:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 07:44:59 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.37c3fc90b11cc988367e39e33a8272e5@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------ Reporter: simonpj | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * owner: => diatchki Comment: Iavor has agreed to execute on this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 07:45:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 07:45:34 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.28f9af2dc9b80e403ae2057b724945c9@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------ Reporter: simonpj | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by simonpj: Old description: > The language extensions `-XIncoherentInstances` and > `-XOverlappingInstances` (described in > [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- > extensions.html#instance-overlap the user manual]) apply to every > instance declaration in the module. Internally, however, GHC records > this information on a per-instance-declaration basis. > > It would be much better for the programmer to be able to control these > matters on a per-instance-declaration basis. Thus: > {{{ > instance Show a => Show [a] where > {-# OVERLAPPABLE #-} > ... > > instance Show [Char] where > ... > }}} > We came across the need for this when discussing the `Typeable` > instances. We have a generic instance like this: > {{{ > instance (Typeable f, Typeable a) => Typeable (f a) where .... > }}} > but also want > {{{ > instance KnownNat n => Typeable (n :: Nat) where ... > }}} > If we seek `(Typeable (x::Nat))`, we should pick the second instance even > though in principle you might imagine that `x` might be instantiated to > `(f a)`, for some `f` and `a`. But we know that there are no type > constructors `f` of kind `blah -> Nat`, so this can never happen and it's > safe to pick the second instance. So a local `{-# INCOHERENT #-}` > pragma for this particular instance declaration would be very useful to > express this fact. > {{{ > instance KnownNat n => Typeable (n :: Nat) where > {-# INCOHERENT #-} > ... > }}} > Quite apart from this special case, it's plain better to have per- > instance control > * Rather than a remote per-module flag, the pragma draws attention that > ''this particular instance'' is incoherent, overlappable or whatever. > * The current situation almost certainly means that more instances are > marked overlapping than are really necessary. > > I have some design questions. > * Where should the pragma appear, syntactically? > {{{ > instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... > or > instance Show a => Show [a] {-# OVERLAPPABLE #-} where ... > or > instance Show a => Show [a] where > {-# OVERLAPPABLE #-} > }}} > Remember that `SPECIALISE INSTANCE` pragmas appear in the third of the > above positions, so I mildly favour that. > > * The user manual (link above) allows overlap if ''either'' instance is > compiled with `-XOverlappingInstances` (see the rules towards the end of > [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- > extensions.html#instance-overlap 7.6.3.5). It would be more explicit to > have two pragmas, one to say "I can be overlapped" and one to say "I can > overlap something else". The rule would then be that "either IX is > marked `{-# OVERLAPPABLE #-}` or IY is marked `{-# OVERLAPPING #-}`. New description: The language extensions `-XIncoherentInstances` and `-XOverlappingInstances` (described in [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap the user manual]) apply to every instance declaration in the module. Internally, however, GHC records this information on a per-instance-declaration basis. It would be much better for the programmer to be able to control these matters on a per-instance-declaration basis. Thus: {{{ instance Show a => Show [a] where {-# OVERLAPPABLE #-} ... instance Show [Char] where ... }}} We came across the need for this when discussing the `Typeable` instances. We have a generic instance like this: {{{ instance (Typeable f, Typeable a) => Typeable (f a) where .... }}} but also want {{{ instance KnownNat n => Typeable (n :: Nat) where ... }}} If we seek `(Typeable (x::Nat))`, we should pick the second instance even though in principle you might imagine that `x` might be instantiated to `(f a)`, for some `f` and `a`. But we know that there are no type constructors `f` of kind `blah -> Nat`, so this can never happen and it's safe to pick the second instance. So a local `{-# INCOHERENT #-}` pragma for this particular instance declaration would be very useful to express this fact. {{{ instance KnownNat n => Typeable (n :: Nat) where {-# INCOHERENT #-} ... }}} Quite apart from this special case, it's plain better to have per-instance control * Rather than a remote per-module flag, the pragma draws attention that ''this particular instance'' is incoherent, overlappable or whatever. * The current situation almost certainly means that more instances are marked overlapping than are really necessary. I have some design questions. * Where should the pragma appear, syntactically? {{{ instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... or instance Show a => Show [a] {-# OVERLAPPABLE #-} where ... or instance Show a => Show [a] where {-# OVERLAPPABLE #-} }}} Remember that `SPECIALISE INSTANCE` pragmas appear in the third of the above positions, so I mildly favour that. * The user manual (link above) allows overlap if ''either'' instance is compiled with `-XOverlappingInstances` (see the rules towards the end of [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap 7.6.3.5]. It would be more explicit to have two pragmas, one to say "I can be overlapped" and one to say "I can overlap something else". The rule would then be that "either IX is marked `{-# OVERLAPPABLE #-}` or IY is marked `{-# OVERLAPPING #-}`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 07:45:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 07:45:49 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.304efea8743ad86cc0d77651ca2e387c@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------ Reporter: simonpj | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by simonpj: Old description: > The language extensions `-XIncoherentInstances` and > `-XOverlappingInstances` (described in > [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- > extensions.html#instance-overlap the user manual]) apply to every > instance declaration in the module. Internally, however, GHC records > this information on a per-instance-declaration basis. > > It would be much better for the programmer to be able to control these > matters on a per-instance-declaration basis. Thus: > {{{ > instance Show a => Show [a] where > {-# OVERLAPPABLE #-} > ... > > instance Show [Char] where > ... > }}} > We came across the need for this when discussing the `Typeable` > instances. We have a generic instance like this: > {{{ > instance (Typeable f, Typeable a) => Typeable (f a) where .... > }}} > but also want > {{{ > instance KnownNat n => Typeable (n :: Nat) where ... > }}} > If we seek `(Typeable (x::Nat))`, we should pick the second instance even > though in principle you might imagine that `x` might be instantiated to > `(f a)`, for some `f` and `a`. But we know that there are no type > constructors `f` of kind `blah -> Nat`, so this can never happen and it's > safe to pick the second instance. So a local `{-# INCOHERENT #-}` > pragma for this particular instance declaration would be very useful to > express this fact. > {{{ > instance KnownNat n => Typeable (n :: Nat) where > {-# INCOHERENT #-} > ... > }}} > Quite apart from this special case, it's plain better to have per- > instance control > * Rather than a remote per-module flag, the pragma draws attention that > ''this particular instance'' is incoherent, overlappable or whatever. > * The current situation almost certainly means that more instances are > marked overlapping than are really necessary. > > I have some design questions. > * Where should the pragma appear, syntactically? > {{{ > instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... > or > instance Show a => Show [a] {-# OVERLAPPABLE #-} where ... > or > instance Show a => Show [a] where > {-# OVERLAPPABLE #-} > }}} > Remember that `SPECIALISE INSTANCE` pragmas appear in the third of the > above positions, so I mildly favour that. > > * The user manual (link above) allows overlap if ''either'' instance is > compiled with `-XOverlappingInstances` (see the rules towards the end of > [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- > extensions.html#instance-overlap 7.6.3.5]. It would be more explicit to > have two pragmas, one to say "I can be overlapped" and one to say "I can > overlap something else". The rule would then be that "either IX is > marked `{-# OVERLAPPABLE #-}` or IY is marked `{-# OVERLAPPING #-}`. New description: The language extensions `-XIncoherentInstances` and `-XOverlappingInstances` (described in [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap the user manual]) apply to every instance declaration in the module. Internally, however, GHC records this information on a per-instance-declaration basis. It would be much better for the programmer to be able to control these matters on a per-instance-declaration basis. Thus: {{{ instance Show a => Show [a] where {-# OVERLAPPABLE #-} ... instance Show [Char] where ... }}} We came across the need for this when discussing the `Typeable` instances. We have a generic instance like this: {{{ instance (Typeable f, Typeable a) => Typeable (f a) where .... }}} but also want {{{ instance KnownNat n => Typeable (n :: Nat) where ... }}} If we seek `(Typeable (x::Nat))`, we should pick the second instance even though in principle you might imagine that `x` might be instantiated to `(f a)`, for some `f` and `a`. But we know that there are no type constructors `f` of kind `blah -> Nat`, so this can never happen and it's safe to pick the second instance. So a local `{-# INCOHERENT #-}` pragma for this particular instance declaration would be very useful to express this fact. {{{ instance KnownNat n => Typeable (n :: Nat) where {-# INCOHERENT #-} ... }}} Quite apart from this special case, it's plain better to have per-instance control * Rather than a remote per-module flag, the pragma draws attention that ''this particular instance'' is incoherent, overlappable or whatever. * The current situation almost certainly means that more instances are marked overlapping than are really necessary. I have some design questions. * Where should the pragma appear, syntactically? {{{ instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... or instance Show a => Show [a] {-# OVERLAPPABLE #-} where ... or instance Show a => Show [a] where {-# OVERLAPPABLE #-} }}} Remember that `SPECIALISE INSTANCE` pragmas appear in the third of the above positions, so I mildly favour that. * The user manual (link above) allows overlap if ''either'' instance is compiled with `-XOverlappingInstances` (see the rules towards the end of [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap 7.6.3.5]). It would be more explicit to have two pragmas, one to say "I can be overlapped" and one to say "I can overlap something else". The rule would then be that "either IX is marked `{-# OVERLAPPABLE #-}` or IY is marked `{-# OVERLAPPING #-}`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 08:19:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 08:19:11 -0000 Subject: [GHC] #9222: Unexpected DataKind Panic In-Reply-To: <045.cffc02ed4ea68b3271b743a554574855@haskell.org> References: <045.cffc02ed4ea68b3271b743a554574855@haskell.org> Message-ID: <060.1084abfa1d8c0532620c9fee8865e513@haskell.org> #9222: Unexpected DataKind Panic --------------------------------------------+------------------------------ Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"2be99d2309471bc75ddb9cb47acda9ccbcb7ab63/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2be99d2309471bc75ddb9cb47acda9ccbcb7ab63" In TcValidity.checkAmbiguity, skolemise kind vars that appear free in the kinds of type variables This was shown up by Trac #9222. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 08:22:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 08:22:47 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.eb7904f195205cad9c9f3067054835aa@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------ Reporter: jcristovao | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thomie): * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 08:26:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 08:26:51 -0000 Subject: [GHC] #9222: Unexpected DataKind Panic In-Reply-To: <045.cffc02ed4ea68b3271b743a554574855@haskell.org> References: <045.cffc02ed4ea68b3271b743a554574855@haskell.org> Message-ID: <060.73fef9b093d3a2946d64a6b27219b94c@haskell.org> #9222: Unexpected DataKind Panic --------------------------------------------+------------------------------ Reporter: ekmett | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: polykinds/T9222 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * status: new => merge * testcase: => polykinds/T9222 * milestone: => 7.8.4 Comment: Merge if we ever do 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 08:31:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 08:31:19 -0000 Subject: [GHC] #9092: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.b9f7cb051e72bab7727c2bd0d31fa554@haskell.org> References: <046.b9f7cb051e72bab7727c2bd0d31fa554@haskell.org> Message-ID: <061.ea4d76736643ab2eccff4cec0a40b975@haskell.org> #9092: ghc: panic! (the 'impossible' happened) ---------------------------------------+----------------------------------- Reporter: alex404 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: panic Operating System: Linux | impossible Type of failure: Compile-time crash | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * status: new => infoneeded Comment: I hope this is a dup of #9208 which is fixed, and will be in 7.8.3. Can you try with 7.8.3 and re-open if it's still broken? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 09:28:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 09:28:10 -0000 Subject: [GHC] #9112: support for deriving Vector/MVector instances In-Reply-To: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> References: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> Message-ID: <060.8a77f8b6571cc6d2e5cd59f91218b887@haskell.org> #9112: support for deriving Vector/MVector instances -------------------------------------+------------------------------------ Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): My current belief is that #9123 is the nub of the issue. Once we've fixed that, I hope that this ticket will also be solved. Please yell if you disagree. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 09:41:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 09:41:09 -0000 Subject: [GHC] #9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface Message-ID: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> #9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface -------------------------+------------------------------------------------- Reporter: | Owner: ezyang | Status: new Type: bug | Milestone: Priority: | Version: 7.9 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- With the latest `-fwrite-interface` enhancements, a build directory can contain interface files independently of object files. In cases like this, we would like to have recompilation avoidance avoid typechecking files whose interface files are up-to-date. However, this does not currently work: we always re-typecheck: {{{ t-edyang at cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc- backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface [1 of 1] Compiling A ( A.hs, nothing ) t-edyang at cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc- backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface [1 of 1] Compiling A ( A.hs, nothing ) }}} The reason for this is that recompilation avoidance logic in `compileOne` (in `DriverPipeline.hs`) seems to rely exclusively on "linkables" in order to figure out if source has been modified or not. We never generate an object file with `-fwrite-interface`, so the compiler always concludes that we need to retypecheck. However, recompilation avoidance for hs-boot does work. The reason for this is because we create a dummy o-boot linkable. We can't use this strategy for `-fno-code`, because the dummy object file would imply that we actually compiled the file (which we didn't). The upshot is that to fix this problem, it looks like we might have to rejigger all of the logic in `compileOne`, which why I gave up on this for now. Related to https://github.com/haskell/cabal/issues/1179 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 15:34:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 15:34:39 -0000 Subject: [GHC] #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables Message-ID: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables -------------------------+------------------------------------------------- Reporter: | Owner: stusmith | Status: new Type: | Milestone: feature request | Version: 7.6.3 Priority: | Operating System: Unknown/Multiple normal | Type of failure: Incorrect warning at Component: | compile-time Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- GHC already warns about variable shadowing: {{{ timesTwoPlusOne x = timesTwo x + 1 where timesTwo x = x * 2 Warning: This binding for `x' shadows the existing binding bound at }}} However the similar warning doesn't happen for type variables. {{{ tryMaybe :: IO a -> IO (Maybe a) tryMaybe action = do result <- (try action) :: IO (Either SomeException a) return $ case result of Left _ -> Nothing Right v -> Just v Couldn't match type `a' with `a1' `a' is a rigid type variable bound by the type signature for tryMaybe :: IO a -> IO (Maybe a) at types.hs::13 `a1' is a rigid type variable bound by an expression type signature: IO (Either SomeException a1) at types.hs::15 Expected type: IO a1 Actual type: IO a ... }}} Here, I thought that the 'a' in the function's type declaration was the same 'a' in the expression type declaration. However in Haskell 98, they are completely different variables. Suggestion: if a type variable is renamed by the compiler due to a clash with another type variable, issue a warning that the second shadows the first, and give a hint about using -XScopedTypeVariables and forall. Alternative suggestion: if an error is displayed, where the error contains a renamed type variable, issue a hint that the second shadows the first, and give a hint about using -XScopedTypeVariables and forall. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 15:57:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 15:57:25 -0000 Subject: [GHC] #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion In-Reply-To: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> References: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> Message-ID: <058.81b295ea5e10bcdc0ca18979dae0f7cf@haskell.org> #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion -------------------------------------+------------------------------------ Reporter: ion1 | Owner: rrnewton Type: feature request | Status: closed Priority: normal | Milestone: 7.8.4 Component: libraries/random | Version: 7.9 Resolution: fixed | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4218 -------------------------------------+------------------------------------ Changes (by thomie): * cc: rrnewton (added) * status: patch => closed * version: 7.6.3 => 7.9 * resolution: => fixed * milestone: => 7.8.4 Comment: This has been committed in [http://git.haskell.org/packages/random.git/commit/4695ffa366f659940369f05e419a4f2249c3a776 4695ffa366f659940369f05e419a4f2249c3a776]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 16:18:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 16:18:19 -0000 Subject: [GHC] #5280: System.Random commits (rand `mod` base) error. In-Reply-To: <047.60f391d6681d1ce2e4d33e581c53c327@haskell.org> References: <047.60f391d6681d1ce2e4d33e581c53c327@haskell.org> Message-ID: <062.5566dd960cfb032c642fb7f4f90303ed@haskell.org> #5280: System.Random commits (rand `mod` base) error. ------------------------------------------------+-------------------------- Reporter: rrnewton | Owner: Type: bug | rrnewton Priority: normal | Status: closed Component: libraries/random | Milestone: 7.8.4 Resolution: fixed | Version: 7.9 Operating System: Unknown/Multiple | Keywords: random Type of failure: Incorrect result at runtime | mod base Test Case: | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thomie): * status: new => closed * cc: rrnewton (added) * difficulty: => Unknown * version: 7.0.3 => 7.9 * milestone: ? => 7.8.4 * resolution: => fixed Comment: Fixed in #8898. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 27 18:58:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jun 2014 18:58:24 -0000 Subject: [GHC] #9224: Add support for binary integer literals In-Reply-To: <042.1a89d47aeeec7e7c411448001a06492c@haskell.org> References: <042.1a89d47aeeec7e7c411448001a06492c@haskell.org> Message-ID: <057.7e82da5fa4241068a3485fb68c62c422@haskell.org> #9224: Add support for binary integer literals -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: (Parser) | Keywords: literals Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"1c0b5fdc9f2b6ea8166cc565383d4cd20432343c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1c0b5fdc9f2b6ea8166cc565383d4cd20432343c" Add -XBinaryLiterals language extension (re #9224) Haskell2010 supports - base-10 (prefix-less), - base-8 (via `0[oO]`-prefix), and - base-16 (via `0[xX]`-prefix) integer literals. This commit adds syntax support for base-2 integer literals via the new `0[bB]` prefix. The use of a `0b` prefix for indicating binary literals is known from popular programming languages such as C++14, Perl, Python, Ruby, and Java. This syntax extension is disabled by default and can be enabled via the new `{-# LANGUAGE BinaryLiterals #-}` pragma and/or the new `-XBinaryLiterals` This new extensions requires to upgrade the `ExtsBitmap` type from `Word` to `Word64` as this adds a 33th flag which is not guaranteed to fit into a `Word`. Signed-off-by: Herbert Valerio Riedel Differential Revision: https://phabricator.haskell.org/D22 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 28 10:39:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jun 2014 10:39:45 -0000 Subject: [GHC] #9245: In absence of recursive imports, hs-boot files not checked for consistency Message-ID: <045.3ecc2f7950efa9c4a06162798d78f5dc@haskell.org> #9245: In absence of recursive imports, hs-boot files not checked for consistency -----------------------------------+--------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Example: B.hs-boot {{{ module B where b :: Bool }}} A.hs {{{ module A where import {-# SOURCE #-} B a = b }}} B.hs {{{ module B where }}} Main.hs {{{ import A main = print a }}} Compilation: {{{ ghc -c B.hs-boot ghc -c A.hs ghc -c B.hs ghc -c Main.hs ghc -o main A.o B.o Main.o }}} Error: {{{A.o:(.text+0x79): undefined reference to `B_b_closure' A.o: In function `A_a_srt': (.data+0x0): undefined reference to `B_b_closure' collect2: error: ld returned 1 exit status }}} The culprit seems to be this code: {{{ -- OK, so we're in one-shot mode. -- In that case, we're read all the direct imports by now, -- so eps_is_boot will record if any of our imports mention us by -- way of hi-boot file { eps <- getEps ; case lookupUFM (eps_is_boot eps) (moduleName mod) of { Nothing -> return emptyModDetails ; -- The typical case Just (_, False) -> failWithTc moduleLoop ; -- Someone below us imported us! -- This is a loop with no hi-boot in the way Just (_mod, True) -> -- There's a hi-boot interface below us }}} but I am not 100% sure what the correct new logic is yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 28 10:40:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jun 2014 10:40:04 -0000 Subject: [GHC] #9245: In absence of recursive imports, hs-boot files not checked for consistency In-Reply-To: <045.3ecc2f7950efa9c4a06162798d78f5dc@haskell.org> References: <045.3ecc2f7950efa9c4a06162798d78f5dc@haskell.org> Message-ID: <060.9882f49e143c1486f66a8afcdd0b2f3b@haskell.org> #9245: In absence of recursive imports, hs-boot files not checked for consistency ---------------------------------------+----------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Description changed by ezyang: Old description: > Example: > > B.hs-boot > {{{ > module B where > b :: Bool > }}} > > A.hs > {{{ > module A where > import {-# SOURCE #-} B > a = b > }}} > > B.hs > {{{ > module B where > }}} > > Main.hs > {{{ > import A > main = print a > }}} > > Compilation: > > {{{ > ghc -c B.hs-boot > ghc -c A.hs > ghc -c B.hs > ghc -c Main.hs > ghc -o main A.o B.o Main.o > }}} > > Error: > {{{A.o:(.text+0x79): undefined reference to `B_b_closure' > A.o: In function `A_a_srt': > (.data+0x0): undefined reference to `B_b_closure' > collect2: error: ld returned 1 exit status > }}} > > The culprit seems to be this code: > > {{{ > -- OK, so we're in one-shot mode. > -- In that case, we're read all the direct imports by now, > -- so eps_is_boot will record if any of our imports mention us by > -- way of hi-boot file > { eps <- getEps > ; case lookupUFM (eps_is_boot eps) (moduleName mod) of { > Nothing -> return emptyModDetails ; -- The typical case > > Just (_, False) -> failWithTc moduleLoop ; > -- Someone below us imported us! > -- This is a loop with no hi-boot in the way > > Just (_mod, True) -> -- There's a hi-boot interface > below us > }}} > > but I am not 100% sure what the correct new logic is yet. New description: Example: B.hs-boot {{{ module B where b :: Bool }}} A.hs {{{ module A where import {-# SOURCE #-} B a = b }}} B.hs {{{ module B where }}} Main.hs {{{ import A main = print a }}} Compilation: {{{ ghc -c B.hs-boot ghc -c A.hs ghc -c B.hs ghc -c Main.hs ghc -o main A.o B.o Main.o }}} Error: {{{ A.o:(.text+0x79): undefined reference to `B_b_closure' A.o: In function `A_a_srt': (.data+0x0): undefined reference to `B_b_closure' collect2: error: ld returned 1 exit status }}} The culprit seems to be this code: {{{ -- OK, so we're in one-shot mode. -- In that case, we're read all the direct imports by now, -- so eps_is_boot will record if any of our imports mention us by -- way of hi-boot file { eps <- getEps ; case lookupUFM (eps_is_boot eps) (moduleName mod) of { Nothing -> return emptyModDetails ; -- The typical case Just (_, False) -> failWithTc moduleLoop ; -- Someone below us imported us! -- This is a loop with no hi-boot in the way Just (_mod, True) -> -- There's a hi-boot interface below us }}} but I am not 100% sure what the correct new logic is yet. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 28 13:29:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jun 2014 13:29:11 -0000 Subject: [GHC] #9245: In absence of recursive imports, hs-boot files not checked for consistency In-Reply-To: <045.3ecc2f7950efa9c4a06162798d78f5dc@haskell.org> References: <045.3ecc2f7950efa9c4a06162798d78f5dc@haskell.org> Message-ID: <060.1c212b01f0d9de7d301dab7d7f780b0c@haskell.org> #9245: In absence of recursive imports, hs-boot files not checked for consistency ---------------------------------------+----------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by ezyang): https://phabricator.haskell.org/D30 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 28 13:43:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jun 2014 13:43:57 -0000 Subject: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2. In-Reply-To: <046.611e1011b849d674524f2ee05d864a89@haskell.org> References: <046.611e1011b849d674524f2ee05d864a89@haskell.org> Message-ID: <061.d0a5634b82b5c194e7c671803acac06e@haskell.org> #5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thomie): How about implementing Euclidean division? [http://legacy.cs.uu.nl/daan/download/papers/divmodnote.pdf Division and Modulus for Computer Scientists] (6 pages pdf) by [http://research.microsoft.com/en-us/people/daan/ Daan Leijen]. "Boute argues that Euclidean division is superior to the other ones in terms of regularity and useful mathematical properties, allthough floored division, promoted by Knuth, is also a good definition. Despite its widespread use, truncated division is shown to be inferior to the other definitions. An interesting mathematical property that is only satisfied by Euclidean division is the shift-rule. A compiler can use this to optimize divisions by a power of two into an arithmetical shift or a bitwise-and operation." D '''div''',,E,, (2^n^) = D '''asr''' n D '''mod''',,E,, (2^n^) = D '''and''' (2^n - 1^) Note: [https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer /dart-core.num Dart]'s modulo operator (%) uses Euclidean division. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 28 15:46:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jun 2014 15:46:34 -0000 Subject: [GHC] #9245: In absence of recursive imports, hs-boot files not checked for consistency In-Reply-To: <045.3ecc2f7950efa9c4a06162798d78f5dc@haskell.org> References: <045.3ecc2f7950efa9c4a06162798d78f5dc@haskell.org> Message-ID: <060.9b59a5816749669197c9dc1118229c7e@haskell.org> #9245: In absence of recursive imports, hs-boot files not checked for consistency ---------------------------------------+----------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Edward Z. Yang ): In [changeset:"0763a2f2eec4f6d9933fe17ee0d4a3a57823e6bf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0763a2f2eec4f6d9933fe17ee0d4a3a57823e6bf" Fix #9245 by always checking hi-boot for consistency if we find one. Summary: What this fix does is reorder how we look for hi-boot files: we unconditionally check for an hi-boot file, and if we don't find one, we check the import graph to see if there was circularity. This is as opposed to the previous scheme (check for circularity, then load hi-boot file). This costs us an extra file system access every typecheck, which is not the best. Signed-off-by: Edward Z. Yang Test Plan: Validate and check for compiler regressions in nofib Reviewers: simonpj, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D30 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 28 15:58:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jun 2014 15:58:29 -0000 Subject: [GHC] #9245: In absence of recursive imports, hs-boot files not checked for consistency In-Reply-To: <045.3ecc2f7950efa9c4a06162798d78f5dc@haskell.org> References: <045.3ecc2f7950efa9c4a06162798d78f5dc@haskell.org> Message-ID: <060.ab28491339437d33cb6291a770d0d4fe@haskell.org> #9245: In absence of recursive imports, hs-boot files not checked for consistency ---------------------------------------+----------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 28 16:07:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jun 2014 16:07:56 -0000 Subject: [GHC] #9238: Negative zero broken In-Reply-To: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> References: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> Message-ID: <062.414a66556c4d842348dd90219a965fe1@haskell.org> #9238: Negative zero broken ------------------------------------------------+-------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by ezyang): Appears to be a regression from 7.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 28 16:15:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jun 2014 16:15:18 -0000 Subject: [GHC] #9238: Negative zero broken In-Reply-To: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> References: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> Message-ID: <062.7ee7790a1f6e5c01599c47ebda1729e3@haskell.org> #9238: Negative zero broken ------------------------------------------------+-------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by ezyang): * os: Windows => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 28 17:02:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jun 2014 17:02:12 -0000 Subject: [GHC] #8993: Fold NullaryTypeClasses into MPTC In-Reply-To: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> References: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> Message-ID: <058.39ab116134d312198e7cdd24397e5c87@haskell.org> #8993: Fold NullaryTypeClasses into MPTC -------------------------------------+------------------------------------ Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * status: closed => new * resolution: fixed => Comment: It seems that currently `NullaryTypeClasses` has no effect anymore? Specifically, `make WAY=normal TEST=TcNullaryTC` fails with {{{ =====> TcNullaryTC(normal) 2009 of 4031 [0, 0, 0] cd ./typecheck/should_run && '/home/hvr/Haskell/GHC/ghc/inplace/bin/ghc- stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history -o TcNullaryTC TcNullaryTC.hs >TcNullaryTC.comp.stderr 2>&1 Compile failed (status 256) errors were: TcNullaryTC.hs:1:14: Warning: -XNullaryTypeClasses is deprecated: use -XMultiParamTypeClasses or pragma {-# LANGUAGE MultiParamTypeClasses #-} instead [1 of 1] Compiling Main ( TcNullaryTC.hs, TcNullaryTC.o ) TcNullaryTC.hs:5:1: No parameters for class ?R? (Use MultiParamTypeClasses to allow no-parameter classes) In the class declaration for ?R? *** unexpected failure for TcNullaryTC(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 28 17:56:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jun 2014 17:56:06 -0000 Subject: [GHC] #9238: Negative zero broken In-Reply-To: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> References: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> Message-ID: <062.ec001489e06616f135d07b4d59dd886c@haskell.org> #9238: Negative zero broken ------------------------------------------------+-------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by carter): I can reproduce the behavior on ghc 7.8.2 on OS X 64 bit i've also started taking a look at the core generated for the 3 alternatives lennart laid out, using variations of the following ghc invocation {{{ ghc -O1 -ddump-simpl -dsuppress-idinfo -dsuppress-coercions -dsuppress- type-applications -dsuppress-uniques -dsuppress-module-prefixes bugMain.hs > bugO1CoreNOINLINE.simple }}} though i'm still working through which differences are real and which arent https://gist.github.com/cartazio/351f15ae74257a7ab64d -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 28 21:12:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jun 2014 21:12:41 -0000 Subject: [GHC] #4880: Functor, Monad, Applicative instances for Data.Monoid.First, Data.Monoid.Last In-Reply-To: <043.40e973f46a003a38ecb9f13d0d37e07c@haskell.org> References: <043.40e973f46a003a38ecb9f13d0d37e07c@haskell.org> Message-ID: <058.830038661f58dd38f351466b6acceb1e@haskell.org> #4880: Functor, Monad, Applicative instances for Data.Monoid.First, Data.Monoid.Last -------------------------------+------------------------------------------- Reporter: sclv | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.0.1 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by hvr): * status: closed => new * cc: hvr, ekmett (added) * resolution: invalid => * difficulty: => Easy (less than 1 hour) * milestone: Not GHC => 7.10.1 * type: proposal => feature request Comment: Morphed this into a feature-request ticket, as the proposal effectively passed the submission process, and the [http://www.haskell.org/pipermail/libraries/2014-June/023231.html patch got blessed by Edward]. I'd just like to wait until Phab:D13 lands -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 28 23:48:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jun 2014 23:48:14 -0000 Subject: [GHC] #9246: GHC generates poor code for repeated uses of min/max Message-ID: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> #9246: GHC generates poor code for repeated uses of min/max ------------------------------+-------------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime performance bug (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #6135 | ------------------------------+-------------------------------------------- Consider the following module, which intends to implement a [http://tavianator.com/2011/05/fast-branchless-raybounding-box- intersections/ branchless ray-AABB intersection test]: {{{ module SimpleGeom where data Vec3 = Vec3 {-# UNPACK #-} !Double {-# UNPACK #-} !Double {-# UNPACK #-} !Double data Ray = Ray !Vec3 !Vec3 !Vec3 data AABB = AABB !Vec3 !Vec3 testRayAABBIntersection :: Ray -> AABB -> Bool testRayAABBIntersection (Ray (Vec3 ox oy oz) _ (Vec3 invDx invDy invDz)) (AABB (Vec3 minX minY minZ) (Vec3 maxX maxY maxZ)) = let tx1 = (minX - ox) * invDx tx2 = (maxX - ox) * invDx ty1 = (minY - oy) * invDy ty2 = (maxY - oy) * invDy tz1 = (minZ - oz) * invDz tz2 = (maxZ - oz) * invDz tmin = min tx1 tx2 `max` min ty1 ty2 `max` min tz1 tz2 tmax = max tx1 tx2 `min` max ty1 ty2 `min` max tz1 tz2 in tmax >= max 0 tmin }}} Everything is strict primitive operations, so GHC should generate very simple, fast code, right? But upon compiling with {{{ghc -O -ddump-simpl -ddump-to-file SimpleGeom}}}, I found a mess of nested local lambdas and similar performance-killing expression forms. (See the attached output file.) There are two possible issues I can see here. 1. GHC is trying to expand out all of the branches recursively (I would presume via case-of-cases transformation), which is a bad idea in this instance compared to just performing the cases sequentially and storing their results. 1. GHC is generating branches for floating-point min/max. Instruction sets like SSE2 include non-branching floating-point min/max instructions, which is exactly what this algorithm was designed to exploit, but GHC does not generate code that could take advantage of these instructions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 01:36:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 01:36:03 -0000 Subject: [GHC] #9246: GHC generates poor code for repeated uses of min/max In-Reply-To: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> References: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> Message-ID: <064.0c14f043f97c937f0bddfd4c9486fe5f@haskell.org> #9246: GHC generates poor code for repeated uses of min/max --------------------------------------------+------------------------------ Reporter: arotenberg | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #6135 --------------------------------------------+------------------------------ Changes (by carter): * type: bug => feature request * milestone: => 7.10.1 Comment: So if you take a look at the haskell level primops that GHC provides http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim-0.3.1.0 /GHC-Prim.html you'll notice that theres no primops for min or max on the underlying unlifted types Double# or Float# (or Int#). So if you need a branchless inner loop today, you'll either need to write a teeny bit of C you'll call out to, encode the logic as some bit fiddling on the floats, OR do something like describe the algorithm programmatically in a Haskell DSL, and at runtime use LLVM-General to generate the code you want http://hackage.haskell.org/package/llvm- general (i'm told some video codecs actually use LLVM for runtime code gen!) Adding these to ghc is a pretty reasonable feature request, though such wouldn't land till 7.10. If you're interested in doing some of the leg work , i'm happy to try to guide you through the process! (If not, thats fine too, its a really concrete task i'll give to someone who wants to do their first ghc patch, ) zooming out, 1. do you have any benchmarks (say, using criterion) for this code? 2. how does eg using -fllvm as your backend fair vs -fasm for this code in such a benchmark -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 11:58:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 11:58:27 -0000 Subject: [GHC] #9224: Add support for binary integer literals In-Reply-To: <042.1a89d47aeeec7e7c411448001a06492c@haskell.org> References: <042.1a89d47aeeec7e7c411448001a06492c@haskell.org> Message-ID: <057.2c0539949f214171a173a38b2224137e@haskell.org> #9224: Add support for binary integer literals -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: (Parser) | Keywords: literals Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"dab0fa06fa33eeb45cef16c06c41d6c45b102451/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dab0fa06fa33eeb45cef16c06c41d6c45b102451" Update Cabal to BinaryLiterals-aware 1.20 version In 1c0b5fdc9f2b6ea8166cc565383d4cd20432343c (re #9224) `BinaryLiterals` was temporarily added to T4437's `expectedGhcOnlyExtensions` list. This can now reverted as Cabal has been made aware of `BinaryLiterals` (see haskell/cabal#1970 and haskell/cabal#1972). updates Cabal submodule Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 11:58:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 11:58:27 -0000 Subject: [GHC] #1970: ghci -hide-all-packages gives bad error message In-Reply-To: <046.46e655a12ebdc87b2836ef76c030a7e8@haskell.org> References: <046.46e655a12ebdc87b2836ef76c030a7e8@haskell.org> Message-ID: <061.5e8b0eb67a73e6bd47022bb15946bca7@haskell.org> #1970: ghci -hide-all-packages gives bad error message ----------------------------+------------------------------- Reporter: dfranke | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.8.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Difficulty: Unknown | Test Case: ----------------------------+------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"dab0fa06fa33eeb45cef16c06c41d6c45b102451/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dab0fa06fa33eeb45cef16c06c41d6c45b102451" Update Cabal to BinaryLiterals-aware 1.20 version In 1c0b5fdc9f2b6ea8166cc565383d4cd20432343c (re #9224) `BinaryLiterals` was temporarily added to T4437's `expectedGhcOnlyExtensions` list. This can now reverted as Cabal has been made aware of `BinaryLiterals` (see haskell/cabal#1970 and haskell/cabal#1972). updates Cabal submodule Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 11:58:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 11:58:27 -0000 Subject: [GHC] #1972: Shadowed binding warning message lacks essential information In-Reply-To: <051.d5da36bf62f0ebf5adc4ea003134b2fe@haskell.org> References: <051.d5da36bf62f0ebf5adc4ea003134b2fe@haskell.org> Message-ID: <066.7b076c88935923680a0c4a70f1acb4b8@haskell.org> #1972: Shadowed binding warning message lacks essential information -------------------------------------+--------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: T1972 -------------------------------------+--------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"dab0fa06fa33eeb45cef16c06c41d6c45b102451/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dab0fa06fa33eeb45cef16c06c41d6c45b102451" Update Cabal to BinaryLiterals-aware 1.20 version In 1c0b5fdc9f2b6ea8166cc565383d4cd20432343c (re #9224) `BinaryLiterals` was temporarily added to T4437's `expectedGhcOnlyExtensions` list. This can now reverted as Cabal has been made aware of `BinaryLiterals` (see haskell/cabal#1970 and haskell/cabal#1972). updates Cabal submodule Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 12:00:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 12:00:20 -0000 Subject: [GHC] #9224: Add support for binary integer literals In-Reply-To: <042.1a89d47aeeec7e7c411448001a06492c@haskell.org> References: <042.1a89d47aeeec7e7c411448001a06492c@haskell.org> Message-ID: <057.d687f8f46e464113a25fea64d6869a95@haskell.org> #9224: Add support for binary integer literals -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: (Parser) | Keywords: literals Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 14:03:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 14:03:23 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.dfcc78261f41211a7727fc16feb20223@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------------------+------------------------- Reporter: hvr | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: Runtime performance bug | Keywords: Test Case: | Architecture: simplCore/should_compile/T8832 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"40ba3daa8ce68eea92f7a42b0c1f6c716636b494/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="40ba3daa8ce68eea92f7a42b0c1f6c716636b494" Expect test failure for T8832 on 32bit (re #8832) Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 14:41:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 14:41:21 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.bdf243d05c341f469afc47851764caf0@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by slyfox): I've noticed it as well. For superficial tests -jN>4 does not make much sense even on 8-core box. Attached a cabal build test (takes ~50 seconds to build). Use as: {{{ $ cd $ghc-source ./test-ghc-cabal.sh >build-log }}} Results for my machine: {{{ RUN jobs: 1 real 0m51.745s user 0m49.825s sys 0m1.553s RUN jobs: 2 real 0m34.254s user 0m57.075s sys 0m6.278s RUN jobs: 3 real 0m31.670s user 1m7.058s sys 0m10.970s RUN jobs: 4 real 0m32.008s user 1m10.548s sys 0m18.194s RUN jobs: 5 real 0m32.329s user 1m15.384s sys 0m27.939s RUN jobs: 6 real 0m33.993s user 1m25.190s sys 0m41.473s RUN jobs: 7 real 0m35.410s user 1m32.354s sys 0m51.201s RUN jobs: 8 real 0m36.111s user 1m42.945s sys 1m1.740s RUN jobs: 9 real 0m37.426s user 1m49.708s sys 1m7.805s RUN jobs: 10 real 0m40.149s user 2m0.625s sys 1m13.054s RUN jobs: 11 real 0m44.515s user 2m18.503s sys 1m21.783s RUN jobs: 12 real 0m44.393s user 2m25.161s sys 1m26.875s RUN jobs: 13 real 0m47.298s user 2m44.370s sys 1m29.611s RUN jobs: 14 real 0m52.647s user 3m16.386s sys 1m37.780s RUN jobs: 15 real 0m54.757s user 3m18.954s sys 1m45.547s RUN jobs: 16 real 0m58.655s user 3m49.732s sys 1m49.191s }}} Notice how sys time creeps up taking over performance gain on N>4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 14:57:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 14:57:25 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.1271dbd31078fb32351ba98acaa7ddcb@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 15:02:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 15:02:46 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.eb16d85d368311c077642e9c98ea29df@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by hvr): Replying to [comment:2 slyfox]: > Notice how sys time creeps up taking over performance gain on N>4. It's also quite visible in the quick R plot I made: [[Image(graph1.png)]] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 15:06:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 15:06:58 -0000 Subject: [GHC] #8993: Fold NullaryTypeClasses into MPTC In-Reply-To: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> References: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> Message-ID: <058.d39e34c3811bb513fff0519c8d667b5c@haskell.org> #8993: Fold NullaryTypeClasses into MPTC -------------------------------------+------------------------------------ Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"26f41922e8923185bc77ceb8ef44d23564d29bed/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="26f41922e8923185bc77ceb8ef44d23564d29bed" Promote TcNullaryTC and TcCoercible to fast tests I'm wondering whether it's sensible to omit so many typecheck testcases from the default validate test target. As for instance, TcNullaryTC has been failing since its introduction in c63a465011b99eeafbb957074e54c2e6bbf751d9 (re #8993) and it seems to have gone unnoticed so far. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 15:42:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 15:42:05 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.d60cf6e0ce14155a4b286e7c197f3d39@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by tibbe): * cc: tibbe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 15:57:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 15:57:46 -0000 Subject: [GHC] #9246: GHC generates poor code for repeated uses of min/max In-Reply-To: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> References: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> Message-ID: <064.1c9c8caa08ca13c8e275ddfe52d59492@haskell.org> #9246: GHC generates poor code for repeated uses of min/max --------------------------------------------+------------------------------ Reporter: arotenberg | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #6135 --------------------------------------------+------------------------------ Comment (by arotenberg): I tried using criterion to profile different versions of this function, but I couldn't get the results to not be noisy and "microbenchmarky". The way I originally found this issue was by profiling the raytracer program I'm writing, which fingered this function as both the single largest time sink and the largest allocator. I tried replacing the definition with this variant: {{{ testRayAABBIntersection :: Ray -> AABB -> Bool testRayAABBIntersection (Ray (Vec3 (D# ox) (D# oy) (D# oz)) _ (Vec3 (D# invDx) (D# invDy) (D# invDz))) (AABB (Vec3 (D# minX) (D# minY) (D# minZ)) (Vec3 (D# maxX) (D# maxY) (D# maxZ))) = let tx1 = minusTimes## minX ox invDx tx2 = minusTimes## maxX ox invDx ty1 = minusTimes## minY oy invDy ty2 = minusTimes## maxY oy invDy tz1 = minusTimes## minZ oz invDz tz2 = minusTimes## maxZ oz invDz tmin = min## tx1 tx2 `max##` min## ty1 ty2 `max##` min## tz1 tz2 tmax = max## tx1 tx2 `min##` max## ty1 ty2 `min##` max## tz1 tz2 in isTrue# (tmax >=## max## 0.0## tmin) {-# NOINLINE minusTimes## #-} minusTimes## :: Double# -> Double# -> Double# -> Double# minusTimes## minA oa invDa = (minA -## oa) *## invDa {-# NOINLINE min## #-} {-# NOINLINE max## #-} min##, max## :: Double# -> Double# -> Double# max## x y = if isTrue# (x <=## y) then y else x min## x y = if isTrue# (x <=## y) then x else y }}} This gets the function's heap allocation down to the expected zero bytes, but at the cost of actually making the program slower (both with and without profiling)! I haven't tried comparing results with the LLVM backend yet. I might look into it later today. It would be nice to see non-branching min/max implemented for the primitive numeric types where available. Min/max for integer types can probably be implemented efficiently on many platforms using conditional move instructions. I'm not particularly interested in implementing it myself, but I'm happy with having it as a feature request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 16:42:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 16:42:50 -0000 Subject: [GHC] #9247: Document -XDatatypeContexts in flag reference Message-ID: <047.5847e6375288b1fe9155bf048d9f1ac4@haskell.org> #9247: Document -XDatatypeContexts in flag reference ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It may be a deprecated feature, but it still exists and should be listed. I can do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 16:47:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 16:47:43 -0000 Subject: [GHC] #9248: Document -XHaskell98 and -XHaskell2010 in flag reference Message-ID: <047.f98b7df1c3966676c7fecca73ea7b44a@haskell.org> #9248: Document -XHaskell98 and -XHaskell2010 in flag reference ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 16:54:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 16:54:59 -0000 Subject: [GHC] #9249: Link to "latest" user's guide Message-ID: <047.de05e08954a03649b76e01617284c75d@haskell.org> #9249: Link to "latest" user's guide ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I search (say, on Google) for a GHC-related bit of documentation, I variously get referred to old manuals. There doesn't seem to a good way for us, the GHC devs, to avoid this. But, perhaps we can include some information in the header of the pages to allow visitors to link to the latest manual, or perhaps to several versions. This header should also include the version number of the GHC that the page is documenting; currently, this info is only in the URL. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 17:14:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 17:14:22 -0000 Subject: [GHC] #8993: Fold NullaryTypeClasses into MPTC In-Reply-To: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> References: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> Message-ID: <058.4d44e516baa05db7ba3836796ff23b64@haskell.org> #8993: Fold NullaryTypeClasses into MPTC -------------------------------------+------------------------------------ Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by monoidal): Sorry about that. Will fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 17:14:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 17:14:36 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.8e0d9984ed660a514881789d85fd4162@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by slyfox): Box I performed tests on is a 8-CPU one (4-cores x 2 threads each): {{{ Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 18:47:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 18:47:51 -0000 Subject: [GHC] #9246: GHC generates poor code for repeated uses of min/max In-Reply-To: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> References: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> Message-ID: <064.bb4fab4fd8b1f6d0afc58135e907dee4@haskell.org> #9246: GHC generates poor code for repeated uses of min/max --------------------------------------------+------------------------------ Reporter: arotenberg | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #6135 --------------------------------------------+------------------------------ Comment (by carter): I think your foo## operations can be safely marked INLINE, rather than NOINLINE. Was there a reason for the NOINLINE? the code loos pretty darn pure, so i don't see how NOINLINE would be needed, and that lack of inlining would explain why the branchless stuff was slower -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 19:37:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 19:37:31 -0000 Subject: [GHC] #9246: GHC generates poor code for repeated uses of min/max In-Reply-To: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> References: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> Message-ID: <064.ebd8e8eead7407ef6f693598e5729ef0@haskell.org> #9246: GHC generates poor code for repeated uses of min/max --------------------------------------------+------------------------------ Reporter: arotenberg | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #6135 --------------------------------------------+------------------------------ Comment (by arotenberg): On the contrary, replacing the NOINLINEs with INLINEs results in essentially the original Core, local lambdas and all. I explicitly put the NOINLINEs in because that was the only way I could find to force GHC to not expand the branches and add the unnecessary lambdas and lazy lets. Perhaps this issue should be split into two tickets - something like "Add branchless min/max primops" and "Min/max-like functions cause unnecessary closure creation"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 20:11:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 20:11:37 -0000 Subject: [GHC] #910: --make should have a -j flag for parallel building In-Reply-To: <044.71389d84cf1d08cc9be1b6b2f82c78b7@haskell.org> References: <044.71389d84cf1d08cc9be1b6b2f82c78b7@haskell.org> Message-ID: <059.95780d81be51bcf02d20749f6c8f0891@haskell.org> #910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: 8184, 8235 Blocking: | Related Tickets: #9221 -------------------------------------+------------------------------------ Changes (by hvr): * related: => #9221 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 20:12:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 20:12:10 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.4501d0200dc82a20cf2d05a5e009b65a@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: 910 -------------------------------------------------+------------------------- Changes (by hvr): * related: => 910 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 20:12:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 20:12:38 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.8f67e632f40f008618e89be2d64a17fc@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #910 -------------------------------------------------+------------------------- Changes (by hvr): * related: => #910 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 21:26:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 21:26:54 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.1c2b8f4afa7b154804a288e77dfe00cc@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------ Reporter: jcristovao | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jcristovao): I am so sorry about this... I should have checked the diff, it was almost useless. Attached is a proper diff (I hope). > Am I supposed to just create an empty .ghci_history > file in the directory where I want to use local history? Yes, that is basically it. Just as you need to create a local .ghci file when you want one. The other alternative would be a command line option, but this seems simpler. What do you think? When we reach an agreement, I'll add the documentation patch. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 21:27:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 21:27:27 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.13bb743d42de3f4c459e44b34c19b009@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------ Reporter: jcristovao | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jcristovao): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 23:23:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 23:23:55 -0000 Subject: [GHC] #9250: let makes function too much specific Message-ID: <048.254274309b6887735ca6a427a0c0c01d@haskell.org> #9250: let makes function too much specific --------------------------+------------------------------------------------ Reporter: | Owner: KommuSoft | Status: new Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: x86_64 | Blocking: (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Say you define a `myadd` function: let myadd x y = x + y Then the type is `Num a => a -> a -> a`. If on the other hand, you define the method using currying: let myadd2 \x -> \y -> x + y The type is more specific: `Integer -> Integer -> Integer`. Strangely enough `:t \x -> \y -> x + y` returns the more general form. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 29 23:24:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jun 2014 23:24:21 -0000 Subject: [GHC] #9250: let makes function too much specific In-Reply-To: <048.254274309b6887735ca6a427a0c0c01d@haskell.org> References: <048.254274309b6887735ca6a427a0c0c01d@haskell.org> Message-ID: <063.f829deac7de73b1d42c9a173c51b0936@haskell.org> #9250: let makes function too much specific ------------------------------------------------+-------------------------- Reporter: KommuSoft | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Description changed by KommuSoft: Old description: > Say you define a `myadd` function: > > let myadd x y = x + y > > Then the type is `Num a => a -> a -> a`. If on the other hand, you define > the method using currying: > > let myadd2 \x -> \y -> x + y > > The type is more specific: `Integer -> Integer -> Integer`. Strangely > enough `:t \x -> \y -> x + y` returns the more general form. New description: Say you define a `myadd` function: let myadd x y = x + y Then the type is `Num a => a -> a -> a`. If on the other hand, you define the method using currying: let myadd2 \x -> \y -> x + y The type is more specific: `Integer -> Integer -> Integer`. Strangely enough `:t \x -> \y -> x + y` returns the more general form. URL: http://stackoverflow.com/questions/24481024/why-does-currying- anonymous-functions-change-haskells-type-inference-from-num-t -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 00:37:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 00:37:45 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.5695e1036b72a058643f869e12b6496c@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------ Reporter: simonpj | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Iavor S. Diatchki ): In [changeset:"6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178" Overlapable pragmas for individual instances (#9242) Programmers may provide a pragma immediately after the `instance` keyword to control the overlap/incoherence behavior for individual instances. For example: instance {-# OVERLAP #-} C a where ... I chose this notation, rather than the other two outlined in the ticket for these reasons: 1. Having the pragma after the type looks odd, I think. 2. Having the pragma after there `where` does not work for stand-alone derived instances I have implemented 3 pragams: 1. NO_OVERLAP 2. OVERLAP 3. INCOHERENT These correspond directly to the internal modes currently supported by GHC. If a pragma is specified, it will be used no matter what flags are turned on. For example, putting `NO_OVERLAP` on an instance will mark it as non-overlapping, even if `OVERLAPPIN_INSTANCES` is turned on for the module. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 00:37:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 00:37:45 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.f8ffd9b3ceaed66ea802dcba81cf8e6c@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------ Reporter: simonpj | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Iavor S. Diatchki ): In [changeset:"b7f9b6a7c800da98d5ba17c45df2a589cc999975/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b7f9b6a7c800da98d5ba17c45df2a589cc999975" Eliminate `Unify.validKindShape` (#9242) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 01:41:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 01:41:48 -0000 Subject: [GHC] #9251: ghc does not expose brancheless max/min operations as primops Message-ID: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> #9251: ghc does not expose brancheless max/min operations as primops ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | ------------------------------------+------------------------------------- It was pointed out in #9246 that GHC currently does not expose primops for Max and Min on various unlifted types such as Float# and Double# and Int# and Word#, but that on most modern CPU architectures there is instruction level support for these operations. (Eg, Float# and #Double min and max can be provided on any 64bit x86 system pretty easily ) This ticket is to track doing that task. I'll probably do it one of the next two weekends to get back in the GHC hacking groove, or maybe this should be used as a "getting started" ticket for a new contributor? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 01:46:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 01:46:22 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops (was: ghc does not expose brancheless max/min operations as primops) In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.871d2179f426fa008e7f89ba9f926cdc@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9246 -------------------------------------+------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 01:47:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 01:47:05 -0000 Subject: [GHC] #9246: GHC generates poor code for repeated uses of min/max In-Reply-To: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> References: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> Message-ID: <064.cdfdec1ab9b3ceec212f8e9f354fc233@haskell.org> #9246: GHC generates poor code for repeated uses of min/max --------------------------------------------+------------------------------ Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #6135 --------------------------------------------+------------------------------ Changes (by carter): * type: feature request => bug * milestone: 7.10.1 => Comment: yes, lets do that. I'll switch this ticket to being the bug one and open a new one for the feature request element and we can back and forth about generating the core etc here. What were the ghc flags and optimization levels etc you were using to check the core? I'd like to make sure i can reproduce your findings before I try out my own hacking to help you out with near term work around over the next week (as my own work permits, though helping folks with perf engineering in haskell DOES overlap with my work a teeny bit) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 02:41:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 02:41:13 -0000 Subject: [GHC] #9246: GHC generates poor code for repeated uses of min/max In-Reply-To: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> References: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> Message-ID: <064.dfe9fd1e6982d133e89bd744ea97bf3f@haskell.org> #9246: GHC generates poor code for repeated uses of min/max --------------------------------------------+------------------------------ Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #6135 --------------------------------------------+------------------------------ Comment (by arotenberg): You should be able to reproduce the issue by using the versions and flags I listed in the original description with a fresh GHC 7.8.2 install. I'm in no rush to get this fixed since the program I'm working on is just a hobby project. I just ran into the issue and figured I'd report it. I mentioned "min/max-like functions" in my previous comment because it's easy to contrive other functions that cause similar issues. Try compiling this module with `ghc -O -ddump-simpl -ddump-to-file UglyBranching.hs` and look at the Core file it generates. {{{ module UglyBranching where foo :: Int -> Int -> Int -> Int -> Int foo a b c d = (((a `bar` b) `bar` (c `bar` d)) `bar` ((a `bar` c) `bar` (b `bar` d))) `bar` (((b `bar` a) `bar` (d `bar` c)) `bar` ((c `bar` a) `bar` (d `bar` b))) bar :: Int -> Int -> Int bar m n = if m + n > 5 then m else n }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 07:10:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 07:10:05 -0000 Subject: [GHC] #9250: let makes function too much specific In-Reply-To: <048.254274309b6887735ca6a427a0c0c01d@haskell.org> References: <048.254274309b6887735ca6a427a0c0c01d@haskell.org> Message-ID: <063.8acb9bad1fa83743c597af156d82e9ae@haskell.org> #9250: let makes function too much specific ------------------------------------------------+-------------------------- Reporter: KommuSoft | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: There are good answers on !StackOverflow. I believe, though you do not say so, that you are describing GHCi. `let` does generalisation, subject to the monomorphism restriction (like all top level bindings); `:type` ignores the monomorphism restriction (it isn't a top level binding). Do re-open if you think there is a bug here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 07:21:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 07:21:10 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.874bfe76463c05792ba8cf9c006205fb@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------ Reporter: simonpj | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): What about the last bullet point of the ticket description? The relationship between two overlapping instances is not symmetrical. I suggested "OVERLAPPABLE" and "OVERLAPPING". Yes, it's a bit more fiddly, but much more explicit. Oh, and I suppose you should be able to have both. {{{ instance {-# OVERLAPPABE #-} C a where instance {-# OVERLAPPABLE, OVERLAPPING #-} C [a] where ... isntance {-# OVERLAPPING #-} C [Maybe a] where ... }}} Here the middle one overlaps `C a` and is overlapped by `C [Maybe a]`. Or is this over-elaborate? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 07:22:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 07:22:26 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.bee3f20e2dea42e64ca306135073ee91@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------ Reporter: simonpj | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): PS: could you also update the user manual? Are we going to deprecate `-XOverlappingInstances` in favour of these pragmas? (I vote yes.) In which case that's something else to do. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 07:28:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 07:28:57 -0000 Subject: [GHC] #9246: GHC generates poor code for repeated uses of min/max In-Reply-To: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> References: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> Message-ID: <064.c50c2c1667ae2f39b49bb3ef91ad7787@haskell.org> #9246: GHC generates poor code for repeated uses of min/max --------------------------------------------+------------------------------ Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #6135 --------------------------------------------+------------------------------ Comment (by simonpj): Indeed! What Core would you ''like'' to see generates for examples like `UglyBranching`? The underlying difficulty is that the case-of-case transformation is utterly crucial for optimising Haskell programs, and it's hard to predict when it'll be unproductive, or even counter-productive. I'd welcome ideas. case-of-case is described in "A transformation based optimiser for Haskell", and (in passing) in many other papers. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 07:59:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 07:59:52 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.d2768100215123a6b854bc87c2099f4c@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------------------+-------------------------- Reporter: Blaisorblade | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: typecheck/should_fail/T8883 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Jan Stolarek ): In [changeset:"d5c6fd6c8525477f869d62d5c71945672b46ee56/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d5c6fd6c8525477f869d62d5c71945672b46ee56" Document #8883 in the release notes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 08:00:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 08:00:50 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.7664a866f2f6c6941cfce4b963127779@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------------------+-------------------------- Reporter: Blaisorblade | Owner: Type: bug | jstolarek Priority: normal | Status: closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: typecheck/should_fail/T8883 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by jstolarek): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 08:26:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 08:26:52 -0000 Subject: [GHC] #703: all binaries built by ghc have executable stacks In-Reply-To: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> References: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> Message-ID: <060.cce280c40426334395e96a143f1de773@haskell.org> #703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Comment (by tibbe): Could someone please write a test so this doesn't regress again? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 08:42:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 08:42:33 -0000 Subject: [GHC] #703: all binaries built by ghc have executable stacks In-Reply-To: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> References: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> Message-ID: <060.34e0b161c01447fa2c1c691697c6fd62@haskell.org> #703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): I did write a test, but we never figured out why Fedora 64bit was still having executable stacks, and then the problem went away. So... I'm not really sure what was going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 08:51:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 08:51:44 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.e2c56321e93f1558c441c90819e24249@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------ Reporter: simonpj | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): There's been talk about implementing a `-XNoOrphanInstances` flag, which should make overlapping always safe (I think). If so perhaps it's useful to have a `-XOverlappingInstances` club to allow overlaps everywhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 09:03:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 09:03:48 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.1f5d7274690eb036c3bf52be21ddcca7@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------ Reporter: simonpj | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Safe or not, I still think it'd be better to signal it locally. Clubs are rather blunt instruments. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 09:24:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 09:24:10 -0000 Subject: [GHC] #9235: Simplifier ticks exhausted on recursive class method In-Reply-To: <043.df7f9b9ba092e09a71bb6cbbadc19ff7@haskell.org> References: <043.df7f9b9ba092e09a71bb6cbbadc19ff7@haskell.org> Message-ID: <058.783e0dcb93769c7e15169c40f2f09976@haskell.org> #9235: Simplifier ticks exhausted on recursive class method ---------------------------------------+----------------------------------- Reporter: klao | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by simonpj): This is a dup of #5722, but I'm going to leave it open as evidence that someone else has tripped up over it. The weird type signature is a special case of something that is generally allowed. I don't in general know how to stop it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 09:24:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 09:24:24 -0000 Subject: [GHC] #5722: GHC inlines class method forever In-Reply-To: <049.65fe5459cb96d02731459b7ea1777cc0@haskell.org> References: <049.65fe5459cb96d02731459b7ea1777cc0@haskell.org> Message-ID: <064.125025c75cecf8358703c997816756a4@haskell.org> #5722: GHC inlines class method forever ---------------------------------------+----------------------------------- Reporter: benmachine | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by simonpj): See #9235 for another example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 09:38:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 09:38:50 -0000 Subject: [GHC] #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables In-Reply-To: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> References: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> Message-ID: <062.e7acff6e396000740de61cf297d8c169@haskell.org> #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables -------------------------------------------------+------------------------- Reporter: stusmith | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): I think that's a fine idea. The easiest place to try this might be the renamer. At the moment the type signature for `tryMaybe` {{{ tryMaybe :: IO a -> IO (Maybe a) }}} does not bring `a` into scope in the body. You need `-XScopedTypeVariables`, ''and'' you need an explicit forall: {{{ tryMaybe :: forall a. IO a -> IO (Maybe a) }}} But it might be reasonable for the renamer to suggest that this is perhaps what you intended, when it comes across that `a` mentioned in {{{ (try action) :: IO (Either SomeException a) }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 09:42:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 09:42:06 -0000 Subject: [GHC] #5722: GHC inlines class method forever In-Reply-To: <049.65fe5459cb96d02731459b7ea1777cc0@haskell.org> References: <049.65fe5459cb96d02731459b7ea1777cc0@haskell.org> Message-ID: <064.48756d21562baaddb501f068c12389e8@haskell.org> #5722: GHC inlines class method forever ---------------------------------------+----------------------------------- Reporter: benmachine | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by klao): * cc: klao@? (added) Comment: One aspect in which the #9235 example is different, is that it triggers the bug even with `-O0`. (I'm not sure if this is important or not.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 09:47:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 09:47:00 -0000 Subject: [GHC] #8441: Allow family instances in an hs-boot file In-Reply-To: <047.1fa915ff10b87e82918754b9e5d340d2@haskell.org> References: <047.1fa915ff10b87e82918754b9e5d340d2@haskell.org> Message-ID: <062.6c4cab8cdeb5ecf62922802dcaa911fb@haskell.org> #8441: Allow family instances in an hs-boot file -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): There is an oblique comment from chak in 2a8cdc3aee5997374273e27365f92c161aca8453 about the issue here: {{{ -- Check for no family instances ; unless (null boot_fam_insts) $ panic ("TcRnDriver.checkHiBootIface: Cannot handle family " ++ "instances in boot files yet...") -- FIXME: Why? The actual comparison is not hard, but what would -- be the equivalent to the dfun bindings returned for class -- instances? We can't easily equate tycons... }}} In the case of type class instances, a boot interface may export a number of dictionary functions which the source file we're currently typechecking may have references to. The names of these dictionary functions are not canonical, so unlike normal exported identifiers, we can't simply take an identifier from the boot file and hope it will point to the right place. Instead, what hi-boot checking currently does is add a pile of dfun bindings to the source being typechecked, rewriting all of the booted dictionary functions to the appropriate places. In the case of type/data families, the comment seems to reason as follows: instead of dictionary functions, the boot interface exports a file of type functions. However, these need to be equated with the real versions in the hs file. And then the comment claims we cannot easily equate tycons. One thing to note is that while the rewriting is necessary for recursive modules, it's unnecessary if we're just interested in comparing two hi files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 09:48:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 09:48:06 -0000 Subject: [GHC] #8441: Allow family instances in an hs-boot file In-Reply-To: <047.1fa915ff10b87e82918754b9e5d340d2@haskell.org> References: <047.1fa915ff10b87e82918754b9e5d340d2@haskell.org> Message-ID: <062.dc27eeaf325d636cc5868c38162071e4@haskell.org> #8441: Allow family instances in an hs-boot file -------------------------------------+------------------------------------ Reporter: goldfire | Owner: ezyang Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * owner: => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 12:44:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 12:44:50 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.28aa7cdb8d4e9fd904587f843218a190@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: #9186 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"aed1723f97e0539d5ab35222b180c1552a5f4cfc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="aed1723f97e0539d5ab35222b180c1552a5f4cfc" Revert "Fix obscure problem with using the system linker (#8935)" This reverts commit 2f8b4c9330b455d4cb31c186c747a7db12a69251. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:01:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:01:24 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.e23e4f144b646bef42ebfffcf17ce1c9@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Hello nomeata, are you still working on this? This is on the hotpath for Backpack implementation work so I will probably go ahead and implement this if you are not working on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:02:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:02:59 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.e1546fe9668c448afef435465fd40880@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * keywords: => backpack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:10:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:10:50 -0000 Subject: [GHC] #9245: In absence of recursive imports, hs-boot files not checked for consistency In-Reply-To: <045.3ecc2f7950efa9c4a06162798d78f5dc@haskell.org> References: <045.3ecc2f7950efa9c4a06162798d78f5dc@haskell.org> Message-ID: <060.f74002532de26883c63988d43eaa5f0c@haskell.org> #9245: In absence of recursive imports, hs-boot files not checked for consistency ---------------------------------------+----------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by ezyang): * keywords: => backpack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:12:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:12:22 -0000 Subject: [GHC] #8441: Allow family instances in an hs-boot file In-Reply-To: <047.1fa915ff10b87e82918754b9e5d340d2@haskell.org> References: <047.1fa915ff10b87e82918754b9e5d340d2@haskell.org> Message-ID: <062.8f3130e34891358027b227d7829a9d4e@haskell.org> #8441: Allow family instances in an hs-boot file -------------------------------------+------------------------------------ Reporter: goldfire | Owner: ezyang Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * keywords: => backpack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:18:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:18:54 -0000 Subject: [GHC] #703: all binaries built by ghc have executable stacks In-Reply-To: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> References: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> Message-ID: <060.51ac57ab49eb4b2128ce25f29377c4cc@haskell.org> #703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Changes (by ezyang): * milestone: 6.6.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:19:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:19:54 -0000 Subject: [GHC] #703: all binaries built by ghc have executable stacks In-Reply-To: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> References: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> Message-ID: <060.3f73a93797630b6e26d951649eab7448@haskell.org> #703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Changes (by ezyang): * type: merge => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:24:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:24:12 -0000 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> Message-ID: <066.6d143751e6457c241784e049a3167268@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * keywords: => backpack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:34:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:34:45 -0000 Subject: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module In-Reply-To: <046.ebf20f155e05760df4b4c62188044473@haskell.org> References: <046.ebf20f155e05760df4b4c62188044473@haskell.org> Message-ID: <061.157a62939ef1a9b0403bacc8e21476aa@haskell.org> #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module ----------------------------------------------+---------------------------- Reporter: skilpat | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.4.2 Resolution: | Keywords: backpack Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects valid program | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by ezyang): * keywords: recursive modules, boot files, double vision, double vision problem => backpack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:36:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:36:12 -0000 Subject: [GHC] #9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface In-Reply-To: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> References: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> Message-ID: <060.4d0cec4ac1cadba8001c7527675eaab7@haskell.org> #9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface -------------------------------------------------+------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | backpack Type of failure: Compile-time performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by ezyang): * keywords: => backpack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:37:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:37:23 -0000 Subject: [GHC] #2408: threadWaitRead on mingw32 threaded causes internal error In-Reply-To: <044.646a5d9cf31ef2594dbfe492fec77132@haskell.org> References: <044.646a5d9cf31ef2594dbfe492fec77132@haskell.org> Message-ID: <059.294b4e18cadc61d839f00eb00c32df6d@haskell.org> #2408: threadWaitRead on mingw32 threaded causes internal error -----------------------------------+--------------------------- Reporter: kirby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+--------------------------- Changes (by ezyang): * cc: hvr, ekmett (added) * milestone: 6.10.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:37:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:37:43 -0000 Subject: [GHC] #2595: Implement record update for existential and GADT data types In-Reply-To: <046.4aca36ddfd3abd8f80e6714ed9319183@haskell.org> References: <046.4aca36ddfd3abd8f80e6714ed9319183@haskell.org> Message-ID: <061.565f699359f9996a8bcab3be8f674130@haskell.org> #2595: Implement record update for existential and GADT data types -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: tc244 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * milestone: 6.12 branch => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:37:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:37:54 -0000 Subject: [GHC] #4139: Spurious non-exhaustive pattern match warnings are given using GADTs In-Reply-To: <046.a84202da85a5f9cbf5e28e3e31df006a@haskell.org> References: <046.a84202da85a5f9cbf5e28e3e31df006a@haskell.org> Message-ID: <061.ffb52cdbabfe4b4881c1d77ee54bdf3f@haskell.org> #4139: Spurious non-exhaustive pattern match warnings are given using GADTs -------------------------------------+------------------------------------- Reporter: blarsen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: GADTs, warnings, Operating System: Unknown/Multiple | pattern matching Type of failure: Incorrect | Architecture: Unknown/Multiple warning at compile-time | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #3927 -------------------------------------+------------------------------------- Changes (by ezyang): * milestone: 7.0.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:38:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:38:06 -0000 Subject: [GHC] #5051: Typechecker behaviour change In-Reply-To: <044.569620fef33303d8ae9785181226236d@haskell.org> References: <044.569620fef33303d8ae9785181226236d@haskell.org> Message-ID: <059.baff57e7b3fa7979a90118202c5d9094@haskell.org> #5051: Typechecker behaviour change -------------------------------------------------+------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: typecheck/should_compile/T5051 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by ezyang): * milestone: 7.2.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:38:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:38:17 -0000 Subject: [GHC] #5610: Improve "Unacceptable argument type in foreign declaration" error message In-Reply-To: <046.fdf192326307b04dbc38c6023f0d4891@haskell.org> References: <046.fdf192326307b04dbc38c6023f0d4891@haskell.org> Message-ID: <061.60f0185bf99284d3475995c2ddd913be@haskell.org> #5610: Improve "Unacceptable argument type in foreign declaration" error message -------------------------------------------------+------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.6.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by ezyang): * milestone: 7.4.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:57:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:57:01 -0000 Subject: [GHC] #9199: Wrong Template Haskell desugaring In-Reply-To: <046.13d98ebb5f95442f706ab8481ad8b12c@haskell.org> References: <046.13d98ebb5f95442f706ab8481ad8b12c@haskell.org> Message-ID: <061.b48ff785217e437b570ed59c6ae51107@haskell.org> #9199: Wrong Template Haskell desugaring -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T9199 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged into 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:57:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:57:16 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.f2657bbbe9779ac540c41096311842c8@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.3 Resolution: fixed | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: stranal/should_compile/T9208 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged into 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:57:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:57:24 -0000 Subject: [GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module In-Reply-To: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> References: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> Message-ID: <058.0b21eb750e284f649e241609fab378da@haskell.org> #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module -------------------------------------------------+------------------------- Reporter: bens | Owner: Type: bug | simonpj Priority: normal | Status: Component: Compiler | closed Resolution: fixed | Milestone: 7.8.3 Operating System: Unknown/Multiple | Version: 7.8.2 Type of failure: Compile-time crash | Keywords: Test Case: deriving/should_fail/T9071, | Architecture: T9071_2 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged into 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:57:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:57:31 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.c7c113cce392c95babb2f05a7e46d57b@haskell.org> #9160: Panic: Template variable unbound in rewrite rule -------------------------------------------------+------------------------- Reporter: mietek | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.3 Resolution: fixed | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time crash | Architecture: Test Case: | x86_64 (amd64) indexed_types/should_fail/T9160 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #4524 -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged into 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:58:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:58:18 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.06022c1c8c839531fd012124498ca713@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: stranal/should_compile/T9208 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: closed => merge Comment: Aw crap, I forgot to merge the last two changes to the testsuite as well to mark T9208 as broken. Those will be incoming soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 13:59:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 13:59:36 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.d449076300da9669e075be48cf4f85ca@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------ Reporter: simonpj | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): The interaction between a hypothetical `-XNoOrphanInstances`, Safety, and overlapping instances is subtle -- the flags have to be put potentially on different modules to get the Safety requirement to work out. For this reason and in order to avoid blunt instruments, I favor also deprecating !OverlappingInstances. For the bulk of you surprised by this mysterious `-XNoOrphanInstances`, it's an idea that Edward Kmett, Gershom Bazerman, and I cooked up a few months ago. More information in due course! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 14:49:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 14:49:05 -0000 Subject: [GHC] #8441: Allow family instances in an hs-boot file In-Reply-To: <047.1fa915ff10b87e82918754b9e5d340d2@haskell.org> References: <047.1fa915ff10b87e82918754b9e5d340d2@haskell.org> Message-ID: <062.7268f656f44f868abd2e942f582f4919@haskell.org> #8441: Allow family instances in an hs-boot file -------------------------------------+------------------------------------ Reporter: goldfire | Owner: ezyang Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Let me know if I can be of assistance in this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 15:52:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 15:52:07 -0000 Subject: [GHC] #9252: Generalize hs-boot files to be more like module signatures Message-ID: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> #9252: Generalize hs-boot files to be more like module signatures ------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: backpack | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Right now, `hs-boot` is used solely to support mutually recursive modules. However, as [wiki:Backpack Backpack] has shown, signatures are an essential part of separate modular development, and since hs-boot files are essentially module signatures, it would be good to move away from "hs- boot as a technical mechanism to make mutual recursion to work" to "hsig as a module signature useful for separate modular development and mutual recursion." Here are some of the things that this would entail: 1. Introduce hsig as a valid alternate file suffix to hs-boot (similarly have hisig for hi-boot; the plan being to eventually deprecate the hs-boot prefix) 2. Given an hsig file corresponding to a module in the current package database (but not from the currently being compiled package), check if the corresponding module implements the signature (this is the reverse of the current check we do for hs-boot files, which occurs when we typecheck the module, as opposed to the hs-boot file.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 15:59:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 15:59:50 -0000 Subject: [GHC] #9253: "internal error: evacuate(static): strange closure type 0" when running in QEMU Message-ID: <047.4e8e56fbd7ab758cd0cf0b782b39823c@haskell.org> #9253: "internal error: evacuate(static): strange closure type 0" when running in QEMU ------------------------------------+------------------------------------- Reporter: ocharles | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We're trying to use NixOS to automatically run our acceptance tests in a VM on commit, in order to guarantee system stability. However, we're periodically seeing our web server component, compiled with GHC 7.8.2 is failing to start up. When it fails, the error message is always: {{{ internal error: evacuate(static): strange closure type 0 (GHC version 7.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Happy to do more debugging on this, but I'll need to be pointed in the right direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 16:01:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 16:01:13 -0000 Subject: [GHC] #9253: "internal error: evacuate(static): strange closure type 0" when running in QEMU In-Reply-To: <047.4e8e56fbd7ab758cd0cf0b782b39823c@haskell.org> References: <047.4e8e56fbd7ab758cd0cf0b782b39823c@haskell.org> Message-ID: <062.18a2ff7706603c755600875b3b59182e@haskell.org> #9253: "internal error: evacuate(static): strange closure type 0" when running in QEMU -------------------------------------+------------------------------------ Reporter: ocharles | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ocharles): I should point out that the exact same code doesn't fail when we run it on bare metal, so it seems to be something specific to running in QEMU. This also doesn't always happen, but it certainly feels like it happens more often than not. We're building this executable with: {{{ ghc-options: -Wall -O2 -threaded -rtsopts }}} We run the server with: {{{ ${metronomeConfig.package}/bin/metronome-server -c ${config.services.fynder.configFile} +RTS -k1M }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 16:08:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 16:08:19 -0000 Subject: [GHC] #9253: "internal error: evacuate(static): strange closure type 0" when running in QEMU In-Reply-To: <047.4e8e56fbd7ab758cd0cf0b782b39823c@haskell.org> References: <047.4e8e56fbd7ab758cd0cf0b782b39823c@haskell.org> Message-ID: <062.f6467eeb3e0c6847c9d3ad7c1c09a00d@haskell.org> #9253: "internal error: evacuate(static): strange closure type 0" when running in QEMU -------------------------------------+------------------------------------ Reporter: ocharles | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ocharles): Here's the compiler flags that were used: {{ configure flags: --disable-split-objs --disable-library-profiling --enable-shared --enable-library-vanilla --enable-executable-dynamic --disable-tests -fsystemdLogging --ghc- option=-optl=-Wl,-rpath=/nix/store/blagiv17bwhqhnpqv6jbkyhd8i1dnig5-metronome-0.1.0/lib/ghc-7.8.2/metronome-0.1.0 Configuring metronome-0.1.0... }}} The full build log can be seen at http://hydra.fynder.io/build/86/log/raw -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 16:50:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 16:50:43 -0000 Subject: [GHC] #9254: Entered absent argument (again) Message-ID: <046.8007e83c84e154810aac28174a2424bb@haskell.org> #9254: Entered absent argument (again) ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider this program: {{{ {-# LANGUAGE MagicHash, UnboxedTuples #-} module Main where import GHC.Exts f :: (() -> (# Int#, () #)) -> () {-# NOINLINE f #-} -- Strictness signature was (7.8.2) -- -- I.e. calls k, but discards first component of result f k = case k () of (# _, r #) -> r g :: Int -> () g y = f (\n -> (# case y of I# y2 -> h (h (h (h (h (h (h y2)))))), n #)) -- RHS is big enough to force worker/wrapper {-# NOINLINE h #-} h :: Int# -> Int# h n = n +# 1# main = print (g 1) }}} You'll get {{{ bash$ ghc -O -o foo Foo.hs bash$ ./foo foo: Oops! Entered absent arg w_s4vl Int }}} Ugh! This is the bug underlying [https://github.com/bos/vector-binary- instances/issues/4 this bug report]. I know what is going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 16:58:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 16:58:12 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.7c365b792ec266e927a177dc7bfc47b7@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: stranal/should_compile/T9208 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by dfeuer): Wouldn't it be more correct to remove the assertion and try to come up with a better one in a future release than to ship with an invalid assertion? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 17:45:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 17:45:42 -0000 Subject: [GHC] #9255: Exception when DeriveFunctor fails Message-ID: <045.f4d80c94efbe072c5144f924e8cb1a7b@haskell.org> #9255: Exception when DeriveFunctor fails -----------------------------------+--------------------------------------- Reporter: twanvl | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- The following program {{{ {-# LANGUAGE DeriveFunctor #-} data Foo a = Foo data Bar a = Bar [Foo a] deriving (Functor) }}} Gives the error message {{{ foo.hs:5:13:ghc: panic! (the 'impossible' happened) (GHC version 7.8.1 for x86_64-unknown-linux): Prelude.(!!): index too large }}} While it should give {{{ foo.hs:4:13:No instance for (Functor Foo) }}} The use of `[]` in `[Foo a]` is not essential, it can be any type constructor that is an instance of Functor. Without the extra type constructor an error is correctly reported. The cause seems to be in the error message. If it wraps to the next line, then ghc dies with: {{{ foo-with-a-longer-filename.hs:5:13: No instance for (Functorghc: panic! (the 'impossible' happened) }}} When using stand alone deriving ghc does not crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 18:21:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 18:21:49 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.1081ce734bd4bdc73e19ebccc5e1ac44@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Not working on it here, so please do go ahead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 18:53:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 18:53:49 -0000 Subject: [GHC] #9255: Exception when DeriveFunctor fails In-Reply-To: <045.f4d80c94efbe072c5144f924e8cb1a7b@haskell.org> References: <045.f4d80c94efbe072c5144f924e8cb1a7b@haskell.org> Message-ID: <060.bc58964252ac27ae35eaacef6595795e@haskell.org> #9255: Exception when DeriveFunctor fails ---------------------------------------+----------------------------------- Reporter: twanvl | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. It's a duplicate of #9071. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 20:46:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 20:46:21 -0000 Subject: [GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module In-Reply-To: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> References: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> Message-ID: <058.ae2e82868eab3c6021cd6431b3bf4d86@haskell.org> #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module -------------------------------------------------+------------------------- Reporter: bens | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: deriving/should_fail/T9071, | Difficulty: T9071_2 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by rwbarton): * owner: simonpj => * status: closed => new * resolution: fixed => Comment: There's some leftover debugging output in compiler/typecheck/TcRnTypes.lhs. Reopening so that it can be fixed and merged into 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 20:53:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 20:53:29 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.ab2731736b9750db6b7150b6df10114a@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------ Reporter: simonpj | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by diatchki): I like the OVERLAPPING and OVERLAPPABLE idea, and I was going to have a stab at implementing it. I just thought it'd be easier to start by simply exposing what GHC does first, before changing more things. So, this, and updating the manual is on my TODO list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 21:12:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 21:12:08 -0000 Subject: [GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module In-Reply-To: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> References: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> Message-ID: <058.b2ad3a925a34b8724f6dc2ca82650817@haskell.org> #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module -------------------------------------------------+------------------------- Reporter: bens | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: deriving/should_fail/T9071, | Difficulty: T9071_2 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): Reid, thanks. Can you identify the "leftover debugging output" and/or offer a patch? Ta Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 21:29:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 21:29:08 -0000 Subject: [GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module In-Reply-To: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> References: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> Message-ID: <058.3fbed1f37a3b2e7011e27a240808b05f@haskell.org> #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module -------------------------------------------------+------------------------- Reporter: bens | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: deriving/should_fail/T9071, | Difficulty: T9071_2 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Reid Barton ): In [changeset:"c44da48c6d19b3d8cc0ba34328576683410f8ec2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c44da48c6d19b3d8cc0ba34328576683410f8ec2" Remove extraneous debugging output (#9071) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 21:29:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 21:29:56 -0000 Subject: [GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module In-Reply-To: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> References: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> Message-ID: <058.65f620b18532a0ba791873adc3bad44c@haskell.org> #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module -------------------------------------------------+------------------------- Reporter: bens | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: deriving/should_fail/T9071, | Difficulty: T9071_2 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by rwbarton): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 30 21:45:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jun 2014 21:45:10 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.4fbd690d9c78b39e1f6deb369951e989@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * owner: => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler