From ghc-devs at haskell.org Tue Mar 1 00:15:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 00:15:44 -0000 Subject: [GHC] #11624: Cannot declare hs-boot declaration if there is already a value in scope In-Reply-To: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> References: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> Message-ID: <060.5f7fb4ef35dc90983efe40e3236ef178@haskell.org> #11624: Cannot declare hs-boot declaration if there is already a value in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): BTW, it's pretty easy to work around this problem: do an explicit import of Prelude bringing into scope only the identifiers you need. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 00:28:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 00:28:45 -0000 Subject: [GHC] #11624: Cannot declare hs-boot declaration if there is already a value in scope In-Reply-To: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> References: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> Message-ID: <060.ebdc13521f7c8f8026932f4475c181c0@haskell.org> #11624: Cannot declare hs-boot declaration if there is already a value in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Just a hunch but I think it is highly likely this commit is the culprit: {{{ Commit 6ab5da9913e4f8a8dcc8bda3c77d4e896fd67352 Author: Richard Eisenberg Fri Apr 10 14:25:29 2015 Committer: Richard Eisenberg Fri Apr 24 13:53:02 2015 Rename role annotations w.r.t only local decls. Fix #10263. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 02:55:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 02:55:44 -0000 Subject: [GHC] #11624: Cannot declare hs-boot declaration if there is already a value in scope In-Reply-To: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> References: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> Message-ID: <060.5c625a112acf27c2ed91729caf18c140@haskell.org> #11624: Cannot declare hs-boot declaration if there is already a value in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1963 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D1963 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 05:14:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 05:14:38 -0000 Subject: [GHC] #10472: SigOf tests fail following renamer tidy-up In-Reply-To: <046.570456994550cf3c5b76ea8401f51edf@haskell.org> References: <046.570456994550cf3c5b76ea8401f51edf@haskell.org> Message-ID: <061.0714358201e6bfcb3e558dad6758e2a7@haskell.org> #10472: SigOf tests fail following renamer tidy-up -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): It turned out that some of the failures were not spurious, and could be tickled using `hs-boot`: #11624. But I'll leave this ticket open because fixing that ticket did not solve all of these failing test cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 05:14:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 05:14:49 -0000 Subject: [GHC] #10472: SigOf tests fail following renamer tidy-up In-Reply-To: <046.570456994550cf3c5b76ea8401f51edf@haskell.org> References: <046.570456994550cf3c5b76ea8401f51edf@haskell.org> Message-ID: <061.cbdc652b7278ed66da4820f99a2b0481@haskell.org> #10472: SigOf tests fail following renamer tidy-up -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11624 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * related: => #11624 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 05:15:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 05:15:02 -0000 Subject: [GHC] #11624: Cannot declare hs-boot declaration if there is already a value in scope In-Reply-To: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> References: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> Message-ID: <060.48aa942ba66f3b2807c8cd34d455f448@haskell.org> #11624: Cannot declare hs-boot declaration if there is already a value in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10472 | Differential Rev(s): Phab:D1963 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * related: => #10472 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 05:17:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 05:17:49 -0000 Subject: [GHC] #10472: SigOf tests fail following renamer tidy-up In-Reply-To: <046.570456994550cf3c5b76ea8401f51edf@haskell.org> References: <046.570456994550cf3c5b76ea8401f51edf@haskell.org> Message-ID: <061.0c04455c105098541964cd2a49fbf0fb@haskell.org> #10472: SigOf tests fail following renamer tidy-up -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11624 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate Comment: Actually, it can all be fixed by #11624, so I'm going to close this as a dupe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 08:58:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 08:58:44 -0000 Subject: [GHC] #10962: Improved arithmetic primops In-Reply-To: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> References: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> Message-ID: <065.3ecd92d086729a016ce9355e92b38bd2@haskell.org> #10962: Improved arithmetic primops -------------------------------------+------------------------------------- Reporter: nkaretnikov | Owner: nkaretnikov Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | wiki:ImprovedArithmeticPrimops | -------------------------------------+------------------------------------- Comment (by erikd): Sorry, to bring this up so late in the release cycle, but I have soem concerns about both the name and the type signature of this new function. Before this was added we had: {{{ plusWord2# :: Word# -> Word# -> (# Word#, Word# #) timesWord2# :: Word# -> Word# -> (# Word#, Word# #) quotRemWord#" :: Word# -> Word# -> (# Word#, Word# #) }}} and now we have added: {{{ subWordC# :: Word# -> Word# -> (# Word#, Int# #) }}} which has a name and a type signature that is wildly out of whack with the others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 09:55:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 09:55:39 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.d9568e93eddd62f8ddc225b5e17c4ecf@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Some of it is addressed by #11607, but this one: {{{ Prelude Data.Sequence> :t (\x -> do{return x}) (\x -> do{return x}) :: Monad m => a -> m a }}} remains as it is. Perhaps we should turn that into `pure x`, but it seems like a special case and could be surprising. I'm undecided here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 10:41:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 10:41:01 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.4a5b22253c9443a88d0bb3616cc3085a@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Ah -- so the meta-tyvars aren't making it to the real `TyCon`, only the `TcTyCon`? It's quite normal for `TcTyCon`s to have meta-tyvars. (Indeed, that's what they're for.) Yes if they are a bare meta-tyvar, but not if they are full polymorphic kind gotten from a CUSK. The whole point about being "complete" is that the signature is fully defined. We experimented with partially-defined signatures and backed off. Complete means complete, and that means no lurking unification variables. > But I'm missing some context. The ASSERT that's breaking is the check during substitutions. But which substitution? I don't see an obvious substitution in `getFamDeclInitialKind`. It happens during the immediately following `tc_lhs_type`; at an occurrence of `MComp` we find that it has a polymorphic kind and try to instantiate that kind. The instantiation fails with this error. (But it's just a canary in the mine; the real problem is that unification variable lurking in an allegedly-complete signature. So yes, (2) is the issue at hand. To go back to your example: {{{ data T (a :: Proxy k) }}} If we are to treat this as a CUSK (and I think we should) we must fix (at that very moment) the kind of `k`. Fixing it to `*` is fine, although its a kind-of-arbitrary choice. But fix it we must. I think the place may be in `kcHsTyVarBndrs`, which I do not fully understand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 10:56:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 10:56:18 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.30af95b1f68a1dd2672244dd19a4f165@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D854 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: D854 => Phab:D854 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 11:00:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 11:00:32 -0000 Subject: [GHC] #11610: Remove IEThingAll constructor from IE datatype In-Reply-To: <049.74bfb9870839f9195b618b2e2024bba7@haskell.org> References: <049.74bfb9870839f9195b618b2e2024bba7@haskell.org> Message-ID: <064.410a99305e411da0ed8df4578c49e8f9@haskell.org> #11610: Remove IEThingAll constructor from IE datatype -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah I see. So you propose to kill off `IEThingAll n` in favour of `IEThingWith n IEWildCard [] []`. Yes that seems fine. Better make certain that the behaviour is identical but it jolly well ought to be. Meanwhile, could you also add a comment with {{{ data IEWildcard = NoIEWildcard | IEWildcard Int deriving (Eq, Data, Typeable) }}} What is this `Int`? Comment plus example. (I think it may indicate where the single `...` occurs in the list perhaps? Ditto in {{{ data ImpExpSubSpec = ImpExpAbs | ImpExpAll | ImpExpList [Located RdrName] | ImpExpAllWith [Located (Maybe RdrName)] }}} what is this `Maybe` doing? Perhaps `Nothing` indicates `..`? Might you add commentary and an example to explain? Data types are such a golden golden opportunity for comments :-). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 11:05:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 11:05:01 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.0c1c8b1679813fdee205ba2111b24dc6@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm afraid I need more examples to understand these steps. Rather than do this on a ticket, would you like to start a wiki page to explain the problem, and the proposed solution, with examples complicated enough to demonstrate the need for each step. One tantalising point is that we already have a `FloatOut` pass for Core that will do much of this. Once I understand the problem better we can think about whether it could be useful. Thanks! PS: v busy until the ICFP deadline (2 wks) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 11:41:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 11:41:06 -0000 Subject: [GHC] #11662: Regression using NamedFieldPuns with qualified field names Message-ID: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> #11662: Regression using NamedFieldPuns with qualified field names -------------------------------------+------------------------------------- Reporter: hesselink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found a regression where code using the NamedFieldPuns extension and qualified field names doesn't compile with GHC 8 rc2, where it did with GHC 7.10. Minimal reproduction: {{{#!hs module Rec where data Rec = Rec { f :: Integer } -------------------- {-# LANGUAGE NamedFieldPuns #-} module Main where import Rec (Rec (Rec)) import qualified Rec g :: Rec -> Integer g (Rec { Rec.f }) = f }}} On GHC 8 this fails with: {{{ Main.hs:6:10: error: Qualified name in binding position: Rec.f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 11:48:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 11:48:30 -0000 Subject: [GHC] #11662: Regression using NamedFieldPuns with qualified field names In-Reply-To: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> References: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> Message-ID: <063.a812f4b20a0bb23a1d446f2c7e346fd4@haskell.org> #11662: Regression using NamedFieldPuns with qualified field names -------------------------------------+------------------------------------- Reporter: hesselink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hesselink): One more addition: I'm pretty sure now that this is supposed to work (and wasn't an accidental feature), since the documentation states {{{ A pun on a qualified field name is expanded by stripping off the module qualifier. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 12:22:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 12:22:21 -0000 Subject: [GHC] #11662: Regression using NamedFieldPuns with qualified field names In-Reply-To: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> References: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> Message-ID: <063.1e0697d0bd9144c92e7db84b7b64f026@haskell.org> #11662: Regression using NamedFieldPuns with qualified field names -------------------------------------+------------------------------------- Reporter: hesselink | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: adamgundry (added) * priority: normal => highest * component: Compiler => Compiler (Parser) * milestone: => 8.0.1 Comment: Indeed, it seems to me like this should work. It seems likely that this is due to the rework surrounding record selectors which accompanied `DuplicateRecordFields`. Ccing Adam. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 12:26:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 12:26:02 -0000 Subject: [GHC] #11662: Regression using NamedFieldPuns with qualified field names In-Reply-To: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> References: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> Message-ID: <063.393d22b9315cc4c4c4039f3d71f487cd@haskell.org> #11662: Regression using NamedFieldPuns with qualified field names -------------------------------------+------------------------------------- Reporter: hesselink | Owner: adamgundry Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: => adamgundry Comment: Sounds plausible. I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 14:07:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 14:07:18 -0000 Subject: [GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory In-Reply-To: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> References: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> Message-ID: <067.4d9854732483290bfe5961c3e0935917@haskell.org> #9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: mergeconflict | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mjmrotek): Replying to [comment:3 thomie]: > > Also, there is a safe foreign import of `rtsSupportsBoundThreads` in GHC.IO.FD (and also some other module(s) in base), which seems quite unnecessary considering `rtsSupportsBoundThreads` simply returns a constant. > > For a newcomer, to get acquainted with the patch submission process. I did this part in https://phabricator.haskell.org/D1964 , grepping through HEAD didn't show any more safe imports of `rtsSupportsBoundThreads`. I didn't touch anything related to `readRawBufferPtr`, `writeRawBufferPtr`, or `throwErrnoIfRetryMayBlock`, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 14:10:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 14:10:21 -0000 Subject: [GHC] #11661: Missing MonadFail instance for Q monad from TemplateHaskell In-Reply-To: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> References: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> Message-ID: <064.ace6046988b0fee3685569528e37ce26@haskell.org> #11661: Missing MonadFail instance for Q monad from TemplateHaskell -------------------------------------+------------------------------------- Reporter: PeterTrsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Yes... I have been wondering for some time already (which is the reason there is no `MonadFail` instance yet) how to properly define one given : {{{#!hs class Monad m => Quasi m where -- ... newtype Q a = Q { unQ :: forall m. Quasi m => m a } instance Monad Q where -- ... fail s = report True s >> Q (fail "Q monad failure") }}} Now obviously we can't {{{#!hs instance Fail.MonadFail Q where -- ... fail = Control.Monad.fail }}} as that would call `Q`'s inner `Monad(fail)`, whereas we'd need it to call `Q`'s inner `MonadFail(fail)` which would require changing `Quasi`'s superclass, and I'm not sure that's appropriate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 14:16:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 14:16:55 -0000 Subject: [GHC] #11661: Missing MonadFail instance for Q monad from TemplateHaskell In-Reply-To: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> References: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> Message-ID: <064.4d1b77b0f27dfd416c1e2e33197abc09@haskell.org> #11661: Missing MonadFail instance for Q monad from TemplateHaskell -------------------------------------+------------------------------------- Reporter: PeterTrsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Well, you needn't necessarily change the context of `Quasi`; you could also add the constraint to `Q`. That being said, I'm not sure whether this is much better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 14:19:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 14:19:42 -0000 Subject: [GHC] #11661: Missing MonadFail instance for Q monad from TemplateHaskell In-Reply-To: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> References: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> Message-ID: <064.73f95309cb51adada0efbe1d300eb76b@haskell.org> #11661: Missing MonadFail instance for Q monad from TemplateHaskell -------------------------------------+------------------------------------- Reporter: PeterTrsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: goldfire (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 14:22:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 14:22:39 -0000 Subject: [GHC] #11661: Missing MonadFail instance for Q monad from TemplateHaskell In-Reply-To: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> References: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> Message-ID: <064.eead7fb8605d57061521a4a4bc50a27b@haskell.org> #11661: Missing MonadFail instance for Q monad from TemplateHaskell -------------------------------------+------------------------------------- Reporter: PeterTrsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Btw, who is allowed to construct a `Q` value anyway? Are users of the `template-haskell` library allowed to, or is it only sensible for GHC to construct a Q value? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 14:57:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 14:57:03 -0000 Subject: [GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory In-Reply-To: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> References: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> Message-ID: <067.f4706f16cde59df4eea41c9ef8485552@haskell.org> #9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: mergeconflict | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Just to say, on the original problem, eliminating allocation from inner loops is a Good Goal. Sometimes it's hard (after all, GHC works largely with immutable values) but sometimes it's really quite accidental and easily eliminated. I don't have time to dig in here; but inlining this `throwErrNo` thing might be helpful. On the other hand it may duplicate a lot of code; maybe it's worth asking ''why'' it is allocating and seeing what might avoid that need. E.g. if it has a higher order argument, perhaps specialising it for the various distinct call sites might help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 15:03:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 15:03:37 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.8bd63ae6a5db6d33f38f2a3576e92416@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is making yet more sense. And it seems that you are proposing: * INVARIANT: The kind of a quantified type variable has no meta-tyvars. We already had that the quantified type variable itself must not be a meta-tyvar. But this invariant goes one step further, in that the set of variables reachable from a quantified tyvar must be devoid of meta-tyvars. Do you agree with this invariant? And, as for design, it seems you are proposing (forgetting about associated types for the moment): * Keep the syntactic definition of CUSK as it is (Note [Complete user- supplied kind signatures] in HsDecls). * When a declaration has a CUSK, default any remaining meta-tyvars after `getInitialKind`. * If a meta-tyvar is not defaultable, the program is erroneous. I'm quite dubious of this design for several reasons. First, this seems strange to users. For example: {{{ data T1 (a :: Proxy k) data T2 (a :: Proxy k) b }}} `T1` has a CUSK, according to our definition. Thus its `k` will be defaulted to kind `*`. `T2`, though, does not have a CUSK, and so `k` is not defaulted and has kind `k2`. Second, the design seems hard to implement without annoying users. For example: {{{ data T3 (x :: * -> *) data T4 (a :: T3 k) }}} `T4` has a CUSK, and `k` should clearly have kind `* -> *`. But we can't discover that until `kcTyClDecl`, which is too late. According to the last bullet above, we'll fail at defaulting `T4`'s `k`'s kind and issue an error, even though it's quite obvious what we should do. So, I must ask: why is it so necessary to have the INVARIANT at the top? I understand this requires expanding the in-scope set for the substitution at hand, but why is that problematic? I don't see what's so bad about a meta-tyvar in a quantified variable's kind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 15:22:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 15:22:39 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.1b59f12d03f3d028738fbb6ce3987c82@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > So, I must ask: why is it so necessary to have the INVARIANT at the top? What if `f :: forall k. forall (a :: kappa). blah`, where `kappa` is a kind meta-var. What if `kappa` was later instantiated to `k`? Now the type looks quite different. Indeed `kcHsTyVarBndrs` goes to some trouble to avoid this {{{ -- in the CUSK case, we want to default any un-kinded tyvars -- See Note [Complete user-supplied kind signatures] in HsDecls ; case hs_tvb of UserTyVar {} | cusk , not scoped -- don't default class tyvars -> discardResult $ unifyKind (Just (mkTyVarTy tv)) liftedTypeKind (tyVarKind tv) }}} For your T1/T2 example I'm not too bothered. CUSKs mean that the user has ''specified the complete kind''. If you want `k` to have some other kind than `*` you can specify that too (I hope). For T3/T4, note that `kdHsTyVarBndrs` calls `TcHsTyVarBndr_Scoped` which in turn calls `unifyKind` so I think you'll be fine. (BUt there is clearly a missing `solveEqualities` here! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 17:27:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 17:27:54 -0000 Subject: [GHC] #11643: Core lint error in simplifier when compiling Rules1 with -O -dcore-lint In-Reply-To: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> References: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> Message-ID: <060.8dd54936d104dc61bc904b18053190f7@haskell.org> #11643: Core lint error in simplifier when compiling Rules1 with -O -dcore-lint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/Rules1 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"57b4c5524fcbf02f61dfc8d9395906dc7f50f048/ghc" 57b4c552/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="57b4c5524fcbf02f61dfc8d9395906dc7f50f048" Don't complain about unused Rule binders This fixes Trac #11643. It's a corner case, now documented in Note [Linting rules] in CoreLint }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 17:31:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 17:31:23 -0000 Subject: [GHC] #11643: Core lint error in simplifier when compiling Rules1 with -O -dcore-lint In-Reply-To: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> References: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> Message-ID: <060.31d7f00a22cf53ef1084d128ae18f8b2@haskell.org> #11643: Core lint error in simplifier when compiling Rules1 with -O -dcore-lint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/Rules1 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think this is fixed. Can someone check and un-mark those tests? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 17:35:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 17:35:41 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.91038ed569a5ff1f74507dbb9fabf786@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11608 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => merge Comment: Here's the patch for the other three {{{ commit 3c29c770be7a8c7268dcb8d8624853428aa42071 Author: Simon Peyton Jones Date: Mon Feb 29 14:12:28 2016 +0000 Do not check synonym RHS for ambiguity With this patch we no longer check the RHS of a type synonym declaration for ambiguity. It only affects type synonyms with foralls on the RHS (which are rare in the first place), and it's arguably over-aggressive to check them for ambiguity. See TcValidity Note [When we don't check for ambiguity] This fixes the ASSERT failures in th T3100 typecheck/should_compile T3692 typecheck/should_fail T3592 }}} Just about worth merging. -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Tue Mar 1 17:38:14 2016 From: conal at conal.net (Conal Elliott) Date: Tue, 1 Mar 2016 09:38:14 -0800 Subject: GADTs and functional dependencies? Message-ID: Do GADTs and functional dependencies get along? I'm wondering why the following code doesn't type-check under GHC 7.10.3 and 8.1.20160224: > {-# OPTIONS_GHC -Wall #-} > {-# LANGUAGE GADTs, KindSignatures, MultiParamTypeClasses, FunctionalDependencies #-} > > module FundepGadt where > > class C a b | a -> b > > data G :: * -> * where > -- ... > GC :: C a b => G b -> G a > > instance Eq (G a) where > -- ... > GC b == GC b' = b == b' Error message: FundepGadt.hs:14:25: error: ? Couldn't match type 'b1? with 'b? 'b1? is a rigid type variable bound by a pattern with constructor: GC :: forall a b. C a b => G b -> G a, in an equation for '==? at FundepGadt.hs:14:12 'b? is a rigid type variable bound by a pattern with constructor: GC :: forall a b. C a b => G b -> G a, in an equation for '==? at FundepGadt.hs:14:3 Expected type: G b Actual type: G b1 ? In the second argument of '(==)?, namely 'b'? In the expression: b == b' In an equation for '==?: (GC b) == (GC b') = b == b' ? Relevant bindings include b' :: G b1 (bound at FundepGadt.hs:14:15) b :: G b (bound at FundepGadt.hs:14:6) I think the functional dependency does ensure that "b == b" is well-typed. In contrast, the following type-family version does type-check: > {-# OPTIONS_GHC -Wall #-} > {-# LANGUAGE GADTs, KindSignatures, TypeFamilies #-} > > module TyfamGadt where > > class C a where > type B a > > data G :: * -> * where > -- ... > GC :: C a => G (B a) -> G a > > instance Eq (G a) where > -- ... > GC b == GC b' = b == b' Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghc-devs at haskell.org Tue Mar 1 18:35:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 18:35:37 -0000 Subject: [GHC] #11662: Regression using NamedFieldPuns with qualified field names In-Reply-To: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> References: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> Message-ID: <063.d989b470f051d0ca28b6be1d11128a0f@haskell.org> #11662: Regression using NamedFieldPuns with qualified field names -------------------------------------+------------------------------------- Reporter: hesselink | Owner: adamgundry Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T11662 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1965 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: => ORF * status: new => patch * differential: => Phab:D1965 * testcase: => rename/should_compile/T11662 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 18:37:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 18:37:32 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.9196b961a661759b0403d914689b9380@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I just introduced a new section in StaticPointers#Localbindingsinthestaticform. Let me know if it is still not clear. -- Ticket URL: GHC The Glasgow Haskell Compiler From iavor.diatchki at gmail.com Tue Mar 1 18:47:07 2016 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 1 Mar 2016 10:47:07 -0800 Subject: GADTs and functional dependencies? In-Reply-To: References: Message-ID: Hello Conal, the implementation of fun-deps in GHC is quite limited, and they don't do what you'd expect with existential types (like in your example), type-signatures, or GADTs. Basically, GHC only uses fun-deps to fill-in types for unification variables, but it won't use them to reason about quantified variables. Here is an example that shows the problem, just using type signatures: > class F a b | a -> b where > f :: a -> b -> () > > instance F Bool Char where > f _ _ = () > > test :: F Bool a => a -> Char > test a = a GHC rejects the declaration for `test` because there it needs to prove that `a ~ Char`. Using the theory of fun-deps, the equality follows because from the fun-dep we know that: forall x y z. (F x y, F x z) => (y ~ z) Now, if we instantiate this axiom with `Bool`, `Char`, and `a`, we can prove that `Char ~ a` by combining the instance and the local assumption from the signature. Unfortunately, this is exactly the kind of reasoning GHC does not do. I am not 100% sure on why not, but at present GHC will basically do all the work to ensure that the fun-dep axiom for each class is valid (that's all the checking that instances are consistent with their fun-deps), but then it won't use that invariant when solving equalities. I hope this helps! -Iavor On Tue, Mar 1, 2016 at 9:38 AM, Conal Elliott wrote: > Do GADTs and functional dependencies get along? I'm wondering why the > following code doesn't type-check under GHC 7.10.3 and 8.1.20160224: > > > {-# OPTIONS_GHC -Wall #-} > > {-# LANGUAGE GADTs, KindSignatures, MultiParamTypeClasses, > FunctionalDependencies #-} > > > > module FundepGadt where > > > > class C a b | a -> b > > > > data G :: * -> * where > > -- ... > > GC :: C a b => G b -> G a > > > > instance Eq (G a) where > > -- ... > > GC b == GC b' = b == b' > > Error message: > > FundepGadt.hs:14:25: error: > ? Couldn't match type 'b1? with 'b? > 'b1? is a rigid type variable bound by > a pattern with constructor: GC :: forall a b. C a b => G b -> > G a, > in an equation for '==? > at FundepGadt.hs:14:12 > 'b? is a rigid type variable bound by > a pattern with constructor: GC :: forall a b. C a b => G b -> > G a, > in an equation for '==? > at FundepGadt.hs:14:3 > Expected type: G b > Actual type: G b1 > ? In the second argument of '(==)?, namely 'b'? > In the expression: b == b' > In an equation for '==?: (GC b) == (GC b') = b == b' > ? Relevant bindings include > b' :: G b1 (bound at FundepGadt.hs:14:15) > b :: G b (bound at FundepGadt.hs:14:6) > > I think the functional dependency does ensure that "b == b" is well-typed. > > In contrast, the following type-family version does type-check: > > > {-# OPTIONS_GHC -Wall #-} > > {-# LANGUAGE GADTs, KindSignatures, TypeFamilies #-} > > > > module TyfamGadt where > > > > class C a where > > type B a > > > > data G :: * -> * where > > -- ... > > GC :: C a => G (B a) -> G a > > > > instance Eq (G a) where > > -- ... > > GC b == GC b' = b == b' > > Thanks, - Conal > > _______________________________________________ > ghc-tickets mailing list > ghc-tickets at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghc-devs at haskell.org Tue Mar 1 19:10:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 19:10:20 -0000 Subject: [GHC] #11661: Missing MonadFail instance for Q monad from TemplateHaskell In-Reply-To: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> References: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> Message-ID: <064.6c34f5d9876403a553f07878c39901a7@haskell.org> #11661: Missing MonadFail instance for Q monad from TemplateHaskell -------------------------------------+------------------------------------- Reporter: PeterTrsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by quchen): The question is, what do we gain? It would not be clear why Quasi has a MonadFail superclass, and I cannot imagine many functions might want to make use of Q's `fail`. Are we in danger of breaking any code because `fail` is removed from `Monad`, does TH rely on its existence? Maybe we should fix those cases instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 19:29:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 19:29:08 -0000 Subject: [GHC] #11661: Missing MonadFail instance for Q monad from TemplateHaskell In-Reply-To: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> References: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> Message-ID: <064.3715507f07ffe1bbf257af9a1ed184c9@haskell.org> #11661: Missing MonadFail instance for Q monad from TemplateHaskell -------------------------------------+------------------------------------- Reporter: PeterTrsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): `fail :: String -> Q a` is the standard way for Template Haskell code to report a fatal error. (Say you are writing a quasiquoter for regular expressions, and the regular expression is ill-formed.) See http://hackage.haskell.org/package/template-haskell-2.10.0.0/docs /Language-Haskell-TH.html#v:reportError. `error :: String -> Q a` also works, sort of. But the error is reported differently by GHC ("Exception when trying to run compile-time code:"). `recover :: Q a -> Q a -> Q a` recovers from `fail`, but obviously not `error`. I don't know whether anyone actually uses `recover` though. I don't really understand all the issues around this `MonadFail` stuff but `Q`'s `fail` isn't something we should just sweep under the rug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 19:42:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 19:42:14 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.83e5809cdf464b6c978588cd5e1ba64b@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11523 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) Comment: I've [https://travis-ci.org/adamgundry/uom-plugin/jobs/112312216 run into this as well]. I'm attaching a trivial patch that fixes the bug and corrects a reference to a Note, but I don't know whether Richard's work will conflict with it or if a bigger change is in order. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 19:42:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 19:42:56 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.28515483ebff7bed560120661719c4a1@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11523 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * Attachment "T11401.patch" added. Patch against HEAD -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 20:25:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 20:25:33 -0000 Subject: [GHC] #11661: Missing MonadFail instance for Q monad from TemplateHaskell In-Reply-To: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> References: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> Message-ID: <064.e4bb147b4c1ceadd579bf6b31208677e@haskell.org> #11661: Missing MonadFail instance for Q monad from TemplateHaskell -------------------------------------+------------------------------------- Reporter: PeterTrsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by PeterTrsko): Seems that `fail` is "integral part" of the `Q` monad and `fail` is part of its contract with the user. The same goes for `Quasy` type class. See e.g. `qReport` and `qRecover`. In my opinion, the only way to correctly preserve the same semantics, under `MonadFailDesugaring`, is to put `MonadFail` as a superclass of `Quasy`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 20:51:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 20:51:29 -0000 Subject: [GHC] #11410: Quantification over unlifted type variable In-Reply-To: <047.8b584f70bae432ee9b28d295b1649fc4@haskell.org> References: <047.8b584f70bae432ee9b28d295b1649fc4@haskell.org> Message-ID: <062.336affbb8e8c6ad354aed2e61f0329a8@haskell.org> #11410: Quantification over unlifted type variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): What is the interaction between this ticket and #11473? Is //all// quantification over kind `#` bad, or is it only when it's quantified to the left of an arrow? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 21:39:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 21:39:12 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.1cdc95dc4f89b1941974ec856784bd34@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * Attachment "Test.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 1 21:41:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Mar 2016 21:41:22 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.29f3281f6575a3d874e1f937b17a1c2e@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Given the attached Test.hs, I run: {{{ ghc --make Test.hs -outputdir old -O1 -o test_old && test_old ghc --make Test.hs -outputdir new -O1 -DNEW -o test_new && test_new }}} The first prints SUCCESS (the catch worked, using {{{safeCatch1}}}). The second prints FAILURE (the catch failed, using {{{safeCatch2}}}). All tests carried out with GHC 8.0.0.20160205 on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 00:09:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 00:09:29 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.37bdc334da6fc3f534cf76674cdd919a@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Very helpful! I know what is happening. Everything works fine until `CorePrep`. At that point we have {{{ catch# (lazy (f x)) blah }}} Now `CorePrep` * Replaces `lazy e` by `e` * Converts to ANF, using `let` or `case` depending on whether the function is strict Unfortunately, that results in {{{ case f x of r -> catch# r blah }}} which is wrong of course. We need that `lazy` to defeat the call-by-value transformation too. So our fix is right; this is really a bug in the implementation of `lazy`. I don't have a fix for this yet, but we have some progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 00:12:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 00:12:44 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.80d303046bcefd049f0a2ccddcff4012@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1961 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See #11660 for a probably better approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 00:13:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 00:13:04 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.186d53b412731261c7dc8a3516453d95@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -4,1 +4,1 @@ - (Phab:D1961), there is now an inconsistency between these two. + (#11549, Phab:D1961), there is now an inconsistency between these two. New description: The `Type` pretty-printer has a fair amount of code in common with the pretty-printer for `IfaceType`. Moreover, both cases handle a number of special cases. With the introduction of `-fprint-explicit-runtime-reps` (#11549, Phab:D1961), there is now an inconsistency between these two. Let's resolve this inconsistency by eliminating the `Type` pretty-printer in favor of using the `IfaceType` printer. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 03:58:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 03:58:07 -0000 Subject: [GHC] #11663: GHC 8.0 behavior WRT scoped type variables changed Message-ID: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> #11663: GHC 8.0 behavior WRT scoped type variables changed -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Not sure if this was intentional or not. This compiles under GHC 8.0.0.20160221 {{{ module Main where import Control.Exception import System.IO main = writeFile "zzz" "hi" `catch` (\(e :: SomeException) -> return ()) }}} Run with an unwritable file named "zzz" in the directory, it ends without complaint. Run under GHC 7.10.3, it throws an error at compilation time: {{{ code/printPls.hs:8:19: Illegal type signature: ?SomeException? Perhaps you intended to use ScopedTypeVariables In a pattern type-signature }}} Did something intentionally change to make this compile out of the box? When I add: {{{ {-# LANGUAGE ScopedTypeVariables #-} }}} Both versions compile. This distinction holds in GHCi as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 03:58:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 03:58:35 -0000 Subject: [GHC] #11663: GHC 8.0 type assignment in arguments of lambda working without Scoped Type Variables (was: GHC 8.0 behavior WRT scoped type variables changed) In-Reply-To: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> References: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> Message-ID: <063.788ff3d216e30a6c82341c3f7d0aaf8a@haskell.org> #11663: GHC 8.0 type assignment in arguments of lambda working without Scoped Type Variables -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 04:14:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 04:14:50 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.de716be09c146c1ea909ba06633d36ca@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1961 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): But #11660 seems orthogonal to this -- the general idea that is described in this ticket and the implementation in Phab:D1961 would still need to exist even after #11660. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 08:30:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 08:30:52 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.a2d83acdbfd0d8f0b29449d0d98f31f2@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1961 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:6 goldfire]: > But #11660 seems orthogonal to this -- the general idea that is described in this ticket and the implementation in Phab:D1961 would still need to exist even after #11660. Well, the implementation in Phab:D1961 would move from `Type` to `IfaceType`, and might look a bit different there. That's all I meant -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 08:55:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 08:55:55 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.b8e6c59c57e235aa14c3363c84031e8e@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): Going back to imagining something more ambitious to tackle the original issue, how feasible would it be to take a class {{{#!hs class Foo i j | i -> j instance Foo Int Bool }}} and elaborate it into something like {{{#!hs class j ~ Foo_FD1 i => Foo i j where type Foo_FD1 i :: * instance Foo Int Bool where type Foo_FD1 Int = Bool }}} so that functional dependencies really would build a type family behind the scenes, and the class would carry explicit evidence? This would make it possible for given constraints involving fundeps to work properly, which they don't at present (as [https://mail.haskell.org/pipermail/ghc- devs/2016-March/011502.html Iavor points out]). Of course, we'd need to figure out how the user should be allowed to refer to such type families, and how the constraint solver should treat them. Moreover, this translation might break programs that are abusing fundeps (comment:16). But perhaps it would be worth exploring. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 08:56:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 08:56:07 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.0001b5b74abfd3e2ed3a0852306aabb2@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 08:57:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 08:57:04 -0000 Subject: [GHC] #11664: Core Lint failure when building warp-3.2.2 Message-ID: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> #11664: Core Lint failure when building warp-3.2.2 ---------------------------------------+--------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+--------------------------------- When building warp-3.2.2 with `-dcore-lint` the module Network.Wai.Handler.Warp.HTTP2.Worker fails to compile with Core Lint errors. Steps to reproduce (assuming that you have [http://haskellstack.org Stack] installed): 1. Download [https://hackage.haskell.org/package/warp-3.2.2/warp-3.2.2.tar.gz warp-3.2.2.tar.gz] from Hackage, extract it, and cd to that directory. 2. Run `echo "resolver: lts-5.5" > stack.yaml` and then `stack build --ghc-options -dcore-lint`. The text with exact error message is attached to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 08:57:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 08:57:27 -0000 Subject: [GHC] #11664: Core Lint failure when building warp-3.2.2 In-Reply-To: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> References: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> Message-ID: <069.fed3fd5a18c4cce9e8c839dc55265bc2@haskell.org> #11664: Core Lint failure when building warp-3.2.2 ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by anton.dessiatov): * Attachment "corelintfail.txt" added. Core lint failure text -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 09:21:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 09:21:58 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.dde8c4a7ea8520b11e68d29f83d804d3@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes I've often thought of doing this. An alternative, which no one has ever fleshed out, would be to extend System FC somehow to provide evidence for functional dependencies. But what Adam suggests here is more or less precisely that; the `Foo` class is a record that has `(j ~ Foo_FD1 i)` as one of its fields; that is, evidence that `(j ~ Foo_FD1 i)`. I worry a bit about how elaborate the translation might be, and whether error messages might mention these strange functions. An alternative is just to use the type-family approach in the first place. Hmm. Maybe we could use default declarations to make it even easier: {{{ class j ~ Foo_FD1 i => Foo i j where type Foo_FD1 i :: * type Foo_FD1 i = j instance Foo Int Bool where -- Nothing }}} This is currently rejected because `j` is not bound on the LHS of the default decl, but if we allowed it, then we'd get, well, precisely what we want. Oh, the idea doesn't work at all. Consider {{{ instance Foo a b => Foo [a] [b] where type Foo_FD1 [a] = [F a] -- This RHS is not so easy to generate! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 09:27:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 09:27:47 -0000 Subject: [GHC] #11664: Core Lint failure when building warp-3.2.2 In-Reply-To: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> References: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> Message-ID: <069.61ff2a335bf5a9b578ec9de023d54746@haskell.org> #11664: Core Lint failure when building warp-3.2.2 ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by simonpj): That looks bad. How can I build this with a particular specified GHC (not in my path), namely my development build. Is there a flag to stack to tell it to do that? Or can I just call cabal directly? I tried {{{ cabal configure --with-ghc=/home/simonpj/5builds/HEAD-3/inplace/bin/ghc- stage2 Resolving dependencies... Configuring warp-3.2.2... cabal: At least the following dependencies are missing: auto-update >=0.1.3 && <0.2, blaze-builder >=0.4, bytestring-builder -any, case-insensitive >=0.2, hashable -any, http-date -any, http-types >=0.8.5, http2 ==1.4.*, iproute >=1.3.1, network >=2.3, simple-sendfile >=0.2.7 && <0.3, stm >=2.3, streaming-commons >=0.1.10, text -any, unix-compat >=0.2, vault >=0.3, wai ==3.2.*, word8 -any }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 09:28:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 09:28:27 -0000 Subject: [GHC] #11664: Core Lint failure when building warp-3.2.2 In-Reply-To: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> References: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> Message-ID: <069.314abf1525c13e4991fd172761640005@haskell.org> #11664: Core Lint failure when building warp-3.2.2 ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by simonpj): Oh this is 7.10.3. Does the same thing happen with the 8.0 release candidate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 09:31:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 09:31:23 -0000 Subject: [GHC] #11664: Core Lint failure when building warp-3.2.2 In-Reply-To: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> References: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> Message-ID: <069.39077c2bd94add9900a853bdd4d75e44@haskell.org> #11664: Core Lint failure when building warp-3.2.2 ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by anton.dessiatov): I will check it now and comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 10:50:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 10:50:45 -0000 Subject: [GHC] #11664: Core Lint failure when building warp-3.2.2 In-Reply-To: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> References: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> Message-ID: <069.ad2211f9852242ade1d4b521f5bbf7dd@haskell.org> #11664: Core Lint failure when building warp-3.2.2 ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by anton.dessiatov): I (expectedly) failed to make stack work with lts-5.5 and GHC 8.0 rc2 so I resorted to using cabal. I have used cabal-install 1.22.8.0 built against 1.22.7.0 Cabal library by GHC 7.10.3 to build warp 3.2.2 with GHC 8.0 rc2. I have did the following (ensuring that correct GHC 8.0 rc2 is on my PATH and I'm in a directory with Warp 3.2.2 source code) {{{ cabal update cabal sandbox init cabal install --ghc-options -dcore-lint }}} This time it failed when building `attoparsec-0.13.0.1` (Data.Attoparsec.Text.Internal module). Now it says {{{ *** Core Lint errors : in result of SpecConstr *** : warning: In the type ?Buffer -> Pos -> More -> a_aNxE -> IResult Text r_aNxF? @ a_aNxE is out of scope }}} The full output is huge so I gzipped it (will post after submitting this message). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 10:51:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 10:51:42 -0000 Subject: [GHC] #11664: Core Lint failure when building warp-3.2.2 In-Reply-To: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> References: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> Message-ID: <069.fc5d3e7d5b2589a3b6a896d0ccc03617@haskell.org> #11664: Core Lint failure when building warp-3.2.2 ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by anton.dessiatov): * Attachment "attoparsec.out.gz" added. Output of cabal install attoparsec --ghc-options -dcorelint with GHC 8.0 rc 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 10:55:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 10:55:36 -0000 Subject: [GHC] #11664: Core Lint failure when building warp-3.2.2 In-Reply-To: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> References: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> Message-ID: <069.4ca2122a0de1cdef3fa7b25cb1fed20a@haskell.org> #11664: Core Lint failure when building warp-3.2.2 ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by bgamari): Simon, it's probably easiest to reproduce with cabal. Adding `--with-ghc` to the `cabal install` command mentioned in comment:4 should be sufficient. I have been able to reproduce with 7.10.3. Now trying with a recent 8.0 snapshot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 10:58:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 10:58:31 -0000 Subject: [GHC] #11664: Core Lint failure when building warp-3.2.2 In-Reply-To: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> References: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> Message-ID: <069.296c6cae7ad1b8cff36c50446a291326@haskell.org> #11664: Core Lint failure when building warp-3.2.2 ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by bgamari): I am unable to reproduce this with 23baff798aca5856650508ad0f7727045efe3680 (a quite recent commit on the `ghc-8.0` branch). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 11:00:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 11:00:00 -0000 Subject: [GHC] #11664: Core Lint failure when building warp-3.2.2 In-Reply-To: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> References: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> Message-ID: <069.bf60567b01e3df4f6a14b801ff457de6@haskell.org> #11664: Core Lint failure when building warp-3.2.2 ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by bgamari): Anton, do you suppose you could open another ticket for the attoparsec issue? It seems quite likely that this is a different issue and it will be helpful to treat them as such. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 11:06:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 11:06:02 -0000 Subject: [GHC] #11664: Core Lint failure when building warp-3.2.2 In-Reply-To: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> References: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> Message-ID: <069.3ecc1b814eacc448f57ccc63941bbae0@haskell.org> #11664: Core Lint failure when building warp-3.2.2 ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by anton.dessiatov): I will now check the `attoparsec` issue with `master` and create another ticket if it reproduces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 11:49:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 11:49:18 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.cc0bcf52b1debea7f7529d37da632889@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I quickly looked at this; unfortunately more `SOURCE` imports of `TyCoRep` is almost inevitable under this change. Currently `IfaceType` must import `TyCoRep` due to the conversion functions. Now we'll also need the inverse import in order to implement the `Type` pretty-printer in terms of the `IfaceType` printer. I suppose we could move the `IfaceType` conversion functions to `Type`, although this seems like it would be an odd break with how the other iface constructs are handled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 12:37:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 12:37:09 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.0ba65c15937048a0d67934d8a15c59ab@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm sure we can deal with that. Eg in `TyCoRep` put just {{{ instance Outputable Type where ppr = pprType }}} and then yes `{-# SOURCE #-}` import `IfaceType` which defines `pprType` and others. Import `IfactType` into `Type` and re-export the pretty- printing functions. But before worrying much let's check that it works at all! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 12:43:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 12:43:03 -0000 Subject: [GHC] #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure Message-ID: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure ---------------------------------------+--------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 11664 Differential Rev(s): | Wiki Page: ---------------------------------------+--------------------------------- You might also like to see #11664 for some history. I have tried using current `master` 57b4c5524fcbf02f61dfc8d9395906dc7f50f048 to build current `attoparsec-0.13.0.1` on Ubuntu Linux 15.10 x86_64. The build fails with Core Lint error {{{ : warning: In the type ?Buffer -> Pos -> More -> a_aOwS -> IResult Text r_aOwT? @ a_aOwS is out of scope }}} Attached comes full output of `cabal install attoparsec --with-ghc= --verbose --ghc-options -dcore-lint`. The output is huge (57k lines) so I gzipped it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 12:43:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 12:43:36 -0000 Subject: [GHC] #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure In-Reply-To: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> References: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> Message-ID: <069.e00848863da44cc713a4a52818cf7303@haskell.org> #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 11664 | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by anton.dessiatov): * Attachment "attoparsec.out.gz" added. Cabal output -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 12:45:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 12:45:33 -0000 Subject: [GHC] #11664: Core Lint failure when building warp-3.2.2 In-Reply-To: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> References: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> Message-ID: <069.cc4224b288123a89997b58654e727706@haskell.org> #11664: Core Lint failure when building warp-3.2.2 ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by anton.dessiatov): Current `master` 57b4c5524fcbf02f61dfc8d9395906dc7f50f048 also fails to build `attoparsec-0.13.0.1` with core lint failure. Created #11665 for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 12:47:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 12:47:21 -0000 Subject: [GHC] #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure In-Reply-To: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> References: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> Message-ID: <069.5f7cc8042571c66b20038df80034a590@haskell.org> #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 11664 | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by simonpj): When I try to reproduce this I fail at the first fence {{{ sh$ cabal configure --with-ghc=/home/simonpj/5builds/HEAD-4/inplace/bin /ghc-stage2 Resolving dependencies... Configuring attoparsec-0.13.0.1... cabal: At least the following dependencies are missing: scientific >=0.3.1 && <0.4, text >=1.1.1.3 sh$ cabal --version cabal-install version 1.23.0.0 compiled using version 1.23.1.0 of the Cabal library }}} Can anyone help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 12:49:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 12:49:36 -0000 Subject: [GHC] #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure In-Reply-To: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> References: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> Message-ID: <069.7b7dc4648001787552241c23c25134da@haskell.org> #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 11664 | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by anton.dessiatov): Could you try running `cabal install` in a sandbox instead of `configure`? I might be horribly wrong here but AFAIK cabal doesn't download and install dependencies when doing `configure`. Maybe there are other ways to force cabal install dependencies, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 13:36:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 13:36:23 -0000 Subject: [GHC] #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x Message-ID: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While working on a project, I have noticed that GHC 8 takes too long to run my test suite on CI server, see for example here: https://travis-ci.org/mrkkrp/zip/builds/113059190 GHC 8 finished in 370 [seconds](https://travis-ci.org/mrkkrp/zip/jobs/113059197#L599), while GHC 7.10.3 in [82 seconds](https://travis-ci.org/mrkkrp/zip/jobs/113059195#L608), 7.10.2 and 7.10.3 demonstrated similar results (77 seconds). There are minor differences in versions of libraries used, mainly those that are shipped with GHC, I read their changelogs and it seems like it's not likely that this sort of slow-down (? 4.5) happened because of one of those libraries. Note that due to the nature of the project I test it does fair amount of IO in temporary directories, I'll be happy to provide more information if you like. BTW, here is the test suite: https://github.com/mrkkrp/zip/blob/master/tests/Main.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 13:40:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 13:40:18 -0000 Subject: [GHC] #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x In-Reply-To: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> References: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> Message-ID: <060.4b8aaee08e60c30b1f23e44e805c6479@haskell.org> #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by mrkkrp: @@ -11,1 +11,1 @@ - and 7.10.3 demonstrated similar results (77 seconds). + and 7.10.1 demonstrated similar results (77 seconds). New description: While working on a project, I have noticed that GHC 8 takes too long to run my test suite on CI server, see for example here: https://travis-ci.org/mrkkrp/zip/builds/113059190 GHC 8 finished in 370 [seconds](https://travis-ci.org/mrkkrp/zip/jobs/113059197#L599), while GHC 7.10.3 in [82 seconds](https://travis-ci.org/mrkkrp/zip/jobs/113059195#L608), 7.10.2 and 7.10.1 demonstrated similar results (77 seconds). There are minor differences in versions of libraries used, mainly those that are shipped with GHC, I read their changelogs and it seems like it's not likely that this sort of slow-down (? 4.5) happened because of one of those libraries. Note that due to the nature of the project I test it does fair amount of IO in temporary directories, I'll be happy to provide more information if you like. BTW, here is the test suite: https://github.com/mrkkrp/zip/blob/master/tests/Main.hs -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 14:16:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 14:16:13 -0000 Subject: [GHC] #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure In-Reply-To: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> References: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> Message-ID: <069.4dd8f5e2e89a584f85a1c8ca5ca1c459@haskell.org> #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 11664 | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by simonpj): Terrific. I've nailed this one. It's an outright bug in `expandTypeSynoyms`. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 14:17:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 14:17:06 -0000 Subject: [GHC] #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x In-Reply-To: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> References: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> Message-ID: <060.77b09bf98dcf718b15392663a5d127ff@haskell.org> #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sounds bad. The more you can help us by digging into exactly what is taking longer, the easier it'll be to help. A 4.5x slowdown ought to be very easy to zero in on. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 14:55:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 14:55:43 -0000 Subject: [GHC] #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x In-Reply-To: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> References: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> Message-ID: <060.f5f4f5330eb83fcd5b9f23e8fee9a510@haskell.org> #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): don't put too much meaning into timings on travis. see this discussion https://mail.haskell.org/pipermail/haskell- cafe/2016-February/123260.html and data in ticket #10818 put "-j2" in your build scripts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 15:18:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 15:18:27 -0000 Subject: [GHC] #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x In-Reply-To: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> References: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> Message-ID: <060.c037df8caf07f567442e8d214fa7117e@haskell.org> #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mrkkrp): Replying to [comment:3 j.waldmann]: > don't put too much meaning into timings on travis. > > see this discussion https://mail.haskell.org/pipermail/haskell- cafe/2016-February/123260.html and data in ticket #10818 > > put "-j2" in your build scripts. Well, that ticket is about compilation time and mine is about performance of compiled code, I don't see how `-j2` can help here. While there are many things that can influence timing on Travis, there results are quite reproducible and now (test suite has grown bigger) GHC 7.10.x finishes successfully while 8.0.1 ends up with: > No output has been received in the last 10 minutes, this potentially > indicates a stalled build or something wrong with the build itself. This is really disappointing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 15:22:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 15:22:49 -0000 Subject: [GHC] #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure In-Reply-To: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> References: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> Message-ID: <069.d932e62bc4db1ef15099da1efd3587a2@haskell.org> #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 11664 | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"286dc021ef515d02453cd5e31774b852d3a1310f/ghc" 286dc021/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="286dc021ef515d02453cd5e31774b852d3a1310f" Fix an outright bug in expandTypeSynonyms The bug was in this code: go subst (TyConApp tc tys) | Just (tenv, rhs, tys') <- expandSynTyCon_maybe tc tys = let subst' = unionTCvSubst subst (mkTvSubstPrs tenv) in go subst' (mkAppTys rhs tys') This is wrong in two ways. * It is wrong to apply the expanded substitution to tys', * The unionTCvSubst is utterly wrong; after all, rhs is completely separate, and the union makes a non-idempotent substitution. It was the non-idempotency that gave the Lint failure in Trac #11665, when there was a type synonym whose RHS mentioned another type synonym, something like type T a b = a -> b type S x y = T y x It only affects SpecConstr because that's about the only place where expandTypeSyonym is called. I tried to trigger the failure with a simple test case, but failed, so I have not added a regression test. Fortunately the solution is very simple and solid. FWIW, the culprit was 674654, "Add kind equalities to GHC". }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 15:25:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 15:25:02 -0000 Subject: [GHC] #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure In-Reply-To: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> References: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> Message-ID: <069.c7ce8638797425d84e26b510ea81b220@haskell.org> #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure ------------------------------------+-------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 11664 | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by simonpj): * status: new => merge Comment: great bug, good to nail this one. Please merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 15:43:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 15:43:23 -0000 Subject: [GHC] #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure In-Reply-To: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> References: <054.e071140855f08cf5855892220cc7b8c9@haskell.org> Message-ID: <069.26b22889aee79bc9e5bf30fd2d13291c@haskell.org> #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure -------------------------------------+------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: 11664 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * failure: None/Unknown => Compile-time crash * resolution: => fixed * milestone: => 8.0.1 Comment: Merged as de6bbc6a201fc7c753d391d8b5ca5d4eca110bba. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 15:45:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 15:45:07 -0000 Subject: [GHC] #11664: Core Lint failure when building warp-3.2.2 In-Reply-To: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> References: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> Message-ID: <069.0eec642a6fffc3cd67a2efe834f04817@haskell.org> #11664: Core Lint failure when building warp-3.2.2 -------------------------------------+------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Compile-time crash * milestone: => 8.0.1 Comment: Looks like this is fixed in 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 15:45:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 15:45:38 -0000 Subject: [GHC] #11664: Core Lint failure when building warp-3.2.2 In-Reply-To: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> References: <054.a4ab6d8e405b6d534b915e56c798bd81@haskell.org> Message-ID: <069.36a3276f190466f29b801bf3f583c447@haskell.org> #11664: Core Lint failure when building warp-3.2.2 -------------------------------------+------------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 15:48:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 15:48:04 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.523d071adc61c41748264dd3debe24d2@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Using the rough elaboration scheme I mentioned above, isn't it just this? {{{#!hs instance Foo a b => Foo [a] [b] where type Foo_FD1 [a] = [Foo_FD1 a] }}} After all: {{{#!hs type Foo_FD1 [a] = [b] = [Foo_FD1 a] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 16:10:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 16:10:56 -0000 Subject: [GHC] #11667: Incorrect pattern synonym types in error messages Message-ID: <046.01f7d6134e84da2cd298573ade0572c4@haskell.org> #11667: Incorrect pattern synonym types in error messages -------------------------------------+------------------------------------- Reporter: rdragon | Owner: rdragon Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #11213 Differential Rev(s): Phab:D1967 | Wiki Page: -------------------------------------+------------------------------------- Here are some examples of incorrect pattern synonym types in error messages. **Example 1** {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Mod1 where pattern Pat :: Eq a => Maybe a pattern Pat <- Just 42 }}} This gives the error (note the missing `Eq a =>`): {{{ Mod1.hs:4:21: error: * Could not deduce (Num a) arising from the literal `42' from the context: Eq a bound by the type signature for pattern synonym `Pat': Maybe a at Mod1.hs:4:9-11 Possible fix: add (Num a) to the context of the type signature for pattern synonym `Pat': Maybe a * In the pattern: 42 In the pattern: Just 42 In the declaration for pattern synonym `Pat' }}} **Example 2** {{{#!hs {-# LANGUAGE PatternSynonyms, GADTs #-} module Mod1 where data T where MkT :: a -> T pattern Pat :: () => b ~ Bool => a -> b -> (b, T) pattern Pat x y = (y, MkT x) }}} We get the error (note the missing contexts and the incorrect quantification `forall b`, missing `a`): {{{ Mod1.hs:6:27: error: * Couldn't match type `b' with `Bool' arising from the "provided" constraints claimed by the signature of `Pat' `b' is a rigid type variable bound by the type signature for pattern synonym `Pat': forall b. a -> b -> (b, T) at Mod1.hs:5:16 * In the declaration for pattern synonym `Pat' * Relevant bindings include y :: b (bound at Mod1.hs:6:20) }}} **Example 3** {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Mod1 where pattern Pat :: Eq a => Show a => a -> Maybe a pattern Pat x <- Just x }}} We get the error: {{{ Mod1.hs:4:23: error: * Could not deduce (Show a) arising from the "provided" constraints claimed by the signature of `Pat' from the context: Eq a bound by the type signature for pattern synonym `Pat': a -> Maybe a at Mod1.hs:4:9-11 * In the declaration for pattern synonym `Pat' }}} Here we could perhaps remove the whole "from the context ... at Mod1.hs:4:9-11" part, as it doesn't make much sense to tell the user that we could not deduce a "provided" constraint from the "required" context. **Example 4** {{{#!hs {-# LANGUAGE PatternSynonyms, GADTs #-} module Mod1 where data T a where MkT :: (Num a, Show a) => a -> T a pattern Pat :: (Eq a) => (Show a) => T a pattern Pat = MkT 42 }}} This gives the error (note that the signature in the error is of the pattern synonym `Pat` when used in an expression context): {{{ Mod1.hs:6:15: error: * Could not deduce (Num a) arising from a use of `MkT' from the context: (Eq a, Show a) bound by the type signature for pattern synonym `Pat': (Eq a, Show a) => T a at Mod1.hs:6:1-20 Possible fix: add (Num a) to the context of the type signature for pattern synonym `Pat': (Eq a, Show a) => T a * In the expression: MkT 42 In an equation for `$bPat': $bPat = MkT 42 }}} The problems in these four examples are caused by the use of `SigSkol (PatSynCtxt n) (Check ty)` for representing pattern synonym types (and the types of bidirectional pattern synonyms when used in an expression context). A possible solution can be found in Phab:D1967. Simon notes the following: > Example 3 raises an interesting point we can debate once we have a ticket. Namely, is this ok? > {{{#!hs > pattern Pat :: Ix a => Ix a => a -> Maybe a > pattern Pat x <- Just x > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 16:16:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 16:16:46 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.9e5a6befe1fbc1513bd8f8cc43d87a1a@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:17 simonpj]: > > So, I must ask: why is it so necessary to have the INVARIANT at the top? > > What if `f :: forall k. forall (a :: kappa). blah`, where `kappa` is a kind meta-var. What if `kappa` was later instantiated to `k`? Now the type looks quite different. I'm not sure what you mean by "quite different". Yes, if we get `kappa := k`, then the type has more dependency, but what's so bad about that? > > Indeed `kcHsTyVarBndrs` goes to some trouble to avoid this > {{{ > -- in the CUSK case, we want to default any un-kinded tyvars > -- See Note [Complete user-supplied kind signatures] in HsDecls > ; case hs_tvb of > UserTyVar {} > | cusk > , not scoped -- don't default class tyvars > -> discardResult $ > unifyKind (Just (mkTyVarTy tv)) liftedTypeKind > (tyVarKind tv) > }}} This code is intended to deal with open data/type family declarations, which always have a CUSK, by fiat. It shouldn't trigger in any other case, because all other declaration forms require `KindedTyVar`s to make a CUSK. > For your T1/T2 example I'm not too bothered. CUSKs mean that the user has ''specified the complete kind''. If you want `k` to have some other kind than `*` you can specify that too (I hope). OK. > > For T3/T4, note that `kdHsTyVarBndrs` calls `TcHsTyVarBndr_Scoped` which in turn calls `unifyKind` so I think you'll be fine. (BUt there is clearly a missing `solveEqualities` here! Yes, I suppose that's true. But I don't spot a missing `solveEqualities` anywhere. Did you miss the call toward the top of `kcTyClGroup`? Bottom line here: I'm unconvinced about INVARIANT. But it does seem easy enough to implement "all declarations with CUSKs default all meta-tyvars", which solves the main problem here. And then we just punt on INVARIANT. In other words, I wish to address (1) from comment:14, which will then solve (2) on the way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 19:01:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 19:01:21 -0000 Subject: [GHC] #11618: Supporting echoing the C compiler invocation instead of the GHC invocation when building the RTS In-Reply-To: <047.24e0c6d5f3a78d3251b196d72b6dc0e8@haskell.org> References: <047.24e0c6d5f3a78d3251b196d72b6dc0e8@haskell.org> Message-ID: <062.0415c61c9cf9dded16752258e7de74b7@haskell.org> #11618: Supporting echoing the C compiler invocation instead of the GHC invocation when building the RTS -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: ide Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 19:06:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 19:06:35 -0000 Subject: [GHC] #11621: GHC doesn't see () as a Constraint in type family In-Reply-To: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> References: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> Message-ID: <066.bcaf095b14dac99fb04b78fd7ed885b6@haskell.org> #11621: GHC doesn't see () as a Constraint in type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * version: 8.1 => 7.10.1 * component: Compiler => Compiler (Type checker) @@ -5,1 +5,1 @@ - import Data.Kind + import GHC.Exts New description: {{{#!hs {-# LANGUAGE DataKinds, TypeOperators, KindSignatures, MultiParamTypeClasses, TypeFamilies #-} import GHC.Exts class NotFound type family F b where F 'False = (NotFound :: Constraint) F 'True = (() :: Constraint) }}} works fine. Removing all constraints and final line it works without any annotations and infers the type of `F :: Bool -> Constraint`: {{{#!hs type family F b where F 'False = NotFound }}} GHC seems determined that `() :: Type` unless explicitly told otherwise, I would like to be able to write: {{{#!hs type family F b where F 'False = NotFound F 'True = () }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 19:17:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 19:17:01 -0000 Subject: [GHC] #11626: type variable out of scope core lint error when compiling attoparsec In-Reply-To: <044.3b54a1a1868c7f532f99f416b8fae60d@haskell.org> References: <044.3b54a1a1868c7f532f99f416b8fae60d@haskell.org> Message-ID: <059.c2dddabbce0b6e10fbe540fbc2901253@haskell.org> #11626: type variable out of scope core lint error when compiling attoparsec -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11665 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #11665 Comment: Just fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 19:24:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 19:24:45 -0000 Subject: [GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc) In-Reply-To: <045.274c910606d60239cadf6f398a2dd711@haskell.org> References: <045.274c910606d60239cadf6f398a2dd711@haskell.org> Message-ID: <060.109dfe681f65dbcfa6ed87f7491cce4e@haskell.org> #11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: jme Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | perf/space_leaks/space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Nice find. I do wonder why arrays need to ever be shrunk for this example. The `Integer` only increases in size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 19:37:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 19:37:22 -0000 Subject: [GHC] #11668: SPEC has a runtime cost Message-ID: <046.e1cd9cfedab3c62d2fdad4e2ab3e91e0@haskell.org> #11668: SPEC has a runtime cost -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As far as I know, `SPEC` is merely intended to help the compiler identify calls for which constructor specialization may be help. Yet it's not erased! In fact, it has a runtime representation which we need to construct and pass around to so-marked calls. This likely isn't killing the performance of anyone's programs but surely we can do better than this. Really, the whole scheme of marking functions with `SPEC` (which as far as I know isn't even properly documented) seems quite odd. What is stopping us from simply attaching pragmas to equations? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 19:53:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 19:53:03 -0000 Subject: [GHC] #11668: SPEC has a runtime cost if constructor specialization isn't performed (was: SPEC has a runtime cost) In-Reply-To: <046.e1cd9cfedab3c62d2fdad4e2ab3e91e0@haskell.org> References: <046.e1cd9cfedab3c62d2fdad4e2ab3e91e0@haskell.org> Message-ID: <061.ed06e02a7eb38fce9f6a99bea5734629@haskell.org> #11668: SPEC has a runtime cost if constructor specialization isn't performed -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It seems that SPEC is correctly eliminated if `-fspec-constr` is used so this should only be a problem for code expecting constructor specialization that gets compiled with `-O1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 19:56:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 19:56:33 -0000 Subject: [GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc) In-Reply-To: <045.274c910606d60239cadf6f398a2dd711@haskell.org> References: <045.274c910606d60239cadf6f398a2dd711@haskell.org> Message-ID: <060.d7b61eb14696dd838602b6388c28f8bb@haskell.org> #11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: jme Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | perf/space_leaks/space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jme): Thanks. Although I didn't verify it, I believe the culprit is the `show`, which repeatedly calls `quotRemInteger` to divide the result into smaller chunks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 19:58:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 19:58:56 -0000 Subject: [GHC] #11312: GHC inlining primitive string literals can affect program output In-Reply-To: <050.6392f4ea96644f5394022cd373a55178@haskell.org> References: <050.6392f4ea96644f5394022cd373a55178@haskell.org> Message-ID: <065.4ef40533b793aa7486784e0564a0bedc@haskell.org> #11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by xnyhps): Fyi, the patch that I've been working on for #9577 already fixes this on Linux: the patch marks string literals as "mergeable" asm sections, so the assembler merges them and makes the addresses identical. I don't mean to say that introducing `String#` isn't an improvement. I'll try to have a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 20:45:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 20:45:11 -0000 Subject: [GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc) In-Reply-To: <045.274c910606d60239cadf6f398a2dd711@haskell.org> References: <045.274c910606d60239cadf6f398a2dd711@haskell.org> Message-ID: <060.d0c321e3282aabfcc2b11462999d71e5@haskell.org> #11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: jme Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | perf/space_leaks/space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jme): Actually, in `show`, it also possible for the `p*p` in `jsplitf` to trigger a segfault. If `p` is ''w'' words long, 2''w'' words are initially allocated for the result of the multiply. But if the most significant word turns out to be 0, the result is shrunk by a word. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 20:55:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 20:55:29 -0000 Subject: [GHC] #5296: Add explicit type applications In-Reply-To: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> References: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> Message-ID: <057.dba6c3e4f47eccf2ab47870c16406027@haskell.org> #5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/Vta{1,2} | typecheck/should_fail/VtaFail Blocked By: 1897 | Blocking: 10770 Related Tickets: #4466 | Differential Rev(s): Phab:D1681 Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): This might be a little too late, but I wanted to raise an about the relationship this has with AllowAmbiguousTypes. I haven't tried it out yet, but based on an earlier comment in this thread, I think that turning on VisibleTypeApplication will also turn on AllowAmbiguousTypes. I don't think that this is necessary, and I think that there are situation where it is detrimental the library users. Let's say that I have a `Rec` from `vinyl` and I'm using `rget` from `Data.Vinyl.Lens`. Today, if I have `myRec :: Rec Identity '[Char,Bool,Int]`, I can write `rget (Proxy :: Proxy Int) myRec` to get the `Int` value out. In the future, it may be desirable to write a function `rget2` that can take the argument by VisibleTypeApplication instead. So, we would call `rget2 @Int myRec` instead. Here's the issue that I'm getting at. What does an end user have to enable to be able to use `rget2`? At the definition site, in the case of `rget2`, we actually don't need AllowAmbiguousTypes, but let's pretend that we did (I should have picked a different example). When a user turns on VisibleTypeApplication to be able to use a function that will otherwise have ambiguous type variable instantiation, I don't think that they should get AllowAmbiguousTypes turned on as well. If I understand correctly, AllowAmbiguousTypes is only needed to define these functions, not to use them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 21:57:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 21:57:58 -0000 Subject: [GHC] #5296: Add explicit type applications In-Reply-To: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> References: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> Message-ID: <057.b2e1f0ad62a181d1e91c0718876f613f@haskell.org> #5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/Vta{1,2} | typecheck/should_fail/VtaFail Blocked By: 1897 | Blocking: 10770 Related Tickets: #4466 | Differential Rev(s): Phab:D1681 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It depends on what ambiguity means. In a language with visible type application, {{{ foo :: (Show a, Read a) => String -> String }}} can be called quite easily. Thus the ambiguity check seems unhelpful here. Thus the decision to have `TypeApplications` turn on `AllowAmbiguousTypes`. I do see what you're getting at. Perhaps this is the wrong design, and I'm happy to think about changing it (although it does seem a bit late). I will say that if you do want the ambiguity check, you can always use `NoAllowAmbiguousTypes`. If you wish to pursue the issue, I think a good next step is posting to ghc-devs to see what others think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 23:23:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 23:23:04 -0000 Subject: [GHC] #11668: SPEC has a runtime cost if constructor specialization isn't performed In-Reply-To: <046.e1cd9cfedab3c62d2fdad4e2ab3e91e0@haskell.org> References: <046.e1cd9cfedab3c62d2fdad4e2ab3e91e0@haskell.org> Message-ID: <061.51c720ef187fb0aba0ac7d9e0bb8d829@haskell.org> #11668: SPEC has a runtime cost if constructor specialization isn't performed -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See `Note [Forcing specialisation]` in `SpecConstr`. The whole `SPEC` or `ForceSpecConstr` business (to force specialisation) is very unsatisfactory. It's just awaiting some bright person to have a better idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 2 23:40:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Mar 2016 23:40:16 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.9824c9d4a0b94385680380ce894d3a3a@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I'm not sure what you mean by "quite different" Suppose you instantiate `f :: forall k. forall (a :: kappa). blah` at some call site. Make up a fresh meta-var for `k` and substitute. We won't substitute for `kappa` because it isn't `k`. Later we unify `kappa := k`. And now our earlier instantiation of `f`'s type is utterly wrong. Actually the real INVARIANT is probably this: * In any quantified type `forall a. blah`, all occurrences of `a` in `blah` must be manifest: not hidden inside meta-tyvars, especially if they have not been instantiated. There could in principle be some free meta-tyvars that we somehow know can never be filled in with the quantified type variable. But for top-level types or kinds this is never necessary. Anyway I agree with your plan. But > But I don't spot a missing `solveEqualities` anywhere. Did you miss the call toward the top of `kcTyClGroup`? I'm still looking at `kcHsTyVarBndrs`. It builds a polytype with `mkSpecForAllTys`. It does unification (inside the call to `tcHsTyVarBndr_Scoped`). I think we need to solve the equalities before we bind the type variables that are mentioned, don't we? Ugh -- that `kcHsTyVarBndrs` is horribly complicated. We should probably Skype but I'm out all Thurs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 3 08:46:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Mar 2016 08:46:04 -0000 Subject: [GHC] #11669: Incorrectly suggests RankNTypes for ill-formed type "forall a. Eq a. Int" Message-ID: <051.ef9fc6a373cf8eba53b7bf79d29ca288@haskell.org> #11669: Incorrectly suggests RankNTypes for ill-formed type "forall a. Eq a. Int" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ baldur at Loki:~$ ghci -ignore-dot-ghci GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help Prelude> let foo :: forall a. Eq a. Int; foo = undefined :1:20: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall . Prelude> :set -XRankNTypes Prelude> let foo :: forall a. Eq a. Int; foo = undefined :3:26: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall . Prelude> }}} also {{{ Prelude> :kind forall a. Eq a. Int :1:15: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall . }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 3 08:53:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Mar 2016 08:53:53 -0000 Subject: [GHC] #11670: Can't infer type Message-ID: <051.c0c820eeed6752ec1594c0814ddee3a0@haskell.org> #11670: Can't infer type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE InstanceSigs, PartialTypeSignatures #-} import Foreign.C.Types import Foreign.Storable import Foreign.Ptr data CTimeval = MkCTimeval CLong CLong peek :: Ptr CTimeval -> IO CTimeval peek ptr = do s <- peekElemOff (castPtr ptr) 0 :: _ _ mus <- peekElemOff (castPtr ptr) 1 return (MkCTimeval s mus) }}} Fails with {{{ baldur at Loki:~$ ghci -ignore-dot-ghci /tmp/tLcV.hs GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tLcV.hs, interpreted ) /tmp/tLcV.hs:11:10: error: ? No instance for (Storable t) Possible fix: add (Storable t) to the context of an expression type signature: IO t ? In a stmt of a 'do' block: s <- peekElemOff (castPtr ptr) 0 :: _ _ In the expression: do { s <- peekElemOff (castPtr ptr) 0 :: _ _; mus <- peekElemOff (castPtr ptr) 1; return (MkCTimeval s mus) } In an equation for ?peek?: peek ptr = do { s <- peekElemOff (castPtr ptr) 0 :: _ _; mus <- peekElemOff (castPtr ptr) 1; return (MkCTimeval s mus) } Failed, modules loaded: none. }}} while {{{#!hs {-# LANGUAGE InstanceSigs, PartialTypeSignatures #-} import Foreign.C.Types import Foreign.Storable import Foreign.Ptr data CTimeval = MkCTimeval CLong CLong peek :: Ptr CTimeval -> IO CTimeval peek ptr = do s <- peekElemOff (castPtr ptr) 0 :: _ CLong mus <- peekElemOff (castPtr ptr) 1 return (MkCTimeval s mus) }}} succeeds. Is this expected? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 3 08:56:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Mar 2016 08:56:13 -0000 Subject: [GHC] #11670: Can't infer type In-Reply-To: <051.c0c820eeed6752ec1594c0814ddee3a0@haskell.org> References: <051.c0c820eeed6752ec1594c0814ddee3a0@haskell.org> Message-ID: <066.b0f706bb7024ae226226d5165eb68db8@haskell.org> #11670: Can't infer type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This also fails: {{{#!hs peek :: Ptr CTimeval -> IO CTimeval peek ptr = do s :: CLong <- peekElemOff (castPtr ptr) 0 :: IO _ mus <- peekElemOff (castPtr ptr) 1 return (MkCTimeval (s :: CLong) mus) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 3 15:36:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Mar 2016 15:36:46 -0000 Subject: [GHC] #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x In-Reply-To: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> References: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> Message-ID: <060.77c51da2d152fca651ac6cb83c647c88@haskell.org> #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): For commit 4345f2d79e388a1f2f14c8440624f11445ea06a of the zip package, I get these timings on my local machine for "cabal test" {{{ 7.10.3 : 8 min 8.rc2 : 60 min }}} results (in dist/test/zip-0.1.0-tests.log) are identical except for the one line that contains the timing info. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 3 15:52:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Mar 2016 15:52:34 -0000 Subject: [GHC] #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x In-Reply-To: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> References: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> Message-ID: <060.743a5673eda1886e9353f2c7df112c08@haskell.org> #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Just to be clear: the slowdown is primarily at runtime, not compile time, correct? We're aware of and working on a few compile-time regressions (though none that should be this bad), but if this is at runtime, it may be a newly-discovered problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 3 15:54:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Mar 2016 15:54:08 -0000 Subject: [GHC] #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x In-Reply-To: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> References: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> Message-ID: <060.f8ff9c2c160e0ea10e3204d084567a27@haskell.org> #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): yes, my data (comment 5) is time for running the test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 3 16:03:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Mar 2016 16:03:14 -0000 Subject: [GHC] #11598: Cache coercion kinds and roles In-Reply-To: <047.56bbfff0d86db02c37b25ddc698d48a1@haskell.org> References: <047.56bbfff0d86db02c37b25ddc698d48a1@haskell.org> Message-ID: <062.2869a19ce3fe0d73c70c5d222f3d6abb@haskell.org> #11598: Cache coercion kinds and roles -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8095 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #8095 Comment: This will make #8095 much easier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 3 16:03:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Mar 2016 16:03:41 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.2cb5117c83879815fdfade047104280a@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321, #11598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * related: 5321 => 5321, #11598 Comment: Made easier by #11598. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 3 16:05:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Mar 2016 16:05:35 -0000 Subject: [GHC] #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x In-Reply-To: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> References: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> Message-ID: <060.0b3453ed794c3bba1b0a5b5c14831c99@haskell.org> #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mrkkrp): I will try to find time and profile tomorrow to find out what is taking so long. This package is quite fast with 7.10.3, just as fast as `zip` and `unzip` utilities. I think it's because of zlib bindings and conduits used. Just a wild guess: conduit uses rewrite rules and fusion, maybe something of this behaves differently with the new version of compiler? This is just an idea, I'm not an expert in this area. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 3 17:52:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Mar 2016 17:52:15 -0000 Subject: [GHC] #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x In-Reply-To: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> References: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> Message-ID: <060.2baa5ad16a2b917984a792576ea4da9a@haskell.org> #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: This is due to https://github.com/haskell/filepath/commit/dd13bb32b7b563248fa2bfa232891e05759d6506 and the generate-and-check strategy used in the `Arbitrary EntrySelector` instance (and maybe others). That will almost never work now for long paths that `Windows.isValid` recognizes more characters as invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 3 23:56:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Mar 2016 23:56:06 -0000 Subject: [GHC] #10961: Make it possible to purely use the parser In-Reply-To: <049.fcc8c76168c1ad7ed5e00c80467dcc18@haskell.org> References: <049.fcc8c76168c1ad7ed5e00c80467dcc18@haskell.org> Message-ID: <064.7a22e2a9fe7e28b2e97cf24fe0b5cc74@haskell.org> #10961: Make it possible to purely use the parser -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10143 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Makes sense. I didn't do much investigation about what needed to be pulled out. However, I think #10143 would be quite a bit more involved because SDocs are everywhere in the compiler. Make sure to post here what you discover even if you don't make much progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 00:15:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 00:15:31 -0000 Subject: [GHC] #10961: Make it possible to purely use the parser In-Reply-To: <049.fcc8c76168c1ad7ed5e00c80467dcc18@haskell.org> References: <049.fcc8c76168c1ad7ed5e00c80467dcc18@haskell.org> Message-ID: <064.9ea184365eb99c5f7e156e9ba0befaa1@haskell.org> #10961: Make it possible to purely use the parser -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10143 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dalaing): I'm now wondering if it would make sense to have the parser track some kind of warning-related values rather than convert them to SDocs, at least during the pure part. If the conversion to SDocs can be done after the parsing, that means users of the pure parsing interface have less structures to set up before they can do things. The alternative would be to further split up the pretty printing flags, so that the things needed for printing error handling are easily available (and potentially a default value can be exposed for ease of use). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 00:45:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 00:45:09 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels Message-ID: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program {{{#!hs {-# LANGUAGE OverloadedLabels, DataKinds, FlexibleInstances, MultiParamTypeClasses #-} import GHC.OverloadedLabels instance IsLabel "Three" Int where fromLabel _ = 3 test :: Int test = #Three main :: IO () main = print test }}} fails to compile in ghc 8.0 with a parse error (while it works as expected if we replace "Three" -> "three"). This may be a conscious design decision, but if not I figured I would ask if it would be possible to allow such labels starting with uppercase letters. I run into this when working on adding support for OverloadedLabels to the gobject-introspection bindings (autogenerated bindings for gtk, etc.), where it would be natural in a few places to write overloaded labels starting with a capital letter. Not hugely important, but sometimes aesthetically more pleasing (imho), and I am not aware of a good reason to forbid them. Perhaps there is one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 04:35:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 04:35:06 -0000 Subject: [GHC] #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x In-Reply-To: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> References: <045.1f54e5cdff2eac5ef71dabc98b5a04ba@haskell.org> Message-ID: <060.104f75147b4e032c457fb1fb7524eaa6@haskell.org> #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mrkkrp): I'm glad it's nothing serious. Sorry for annoyance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 06:21:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 06:21:42 -0000 Subject: [GHC] #10961: Make it possible to purely use the parser In-Reply-To: <049.fcc8c76168c1ad7ed5e00c80467dcc18@haskell.org> References: <049.fcc8c76168c1ad7ed5e00c80467dcc18@haskell.org> Message-ID: <064.88afb1b42032be8c637f99140b963a77@haskell.org> #10961: Make it possible to purely use the parser -------------------------------------+------------------------------------- Reporter: mpickering | Owner: dalaing Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10143 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dalaing): * owner: => dalaing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 09:12:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 09:12:06 -0000 Subject: [GHC] #11672: Poor error message Message-ID: <049.cc2f48c705b5aa7c4431fbd88245f608@haskell.org> #11672: Poor error message -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: ErrorMessages | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #11198 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://mail.haskell.org/pipermail/haskell-cafe/2016-February/123262.html Daniel D?az recently pointed out] a particularly terrible error message. Here's a reduced example: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} module BadError where import GHC.TypeLits import Data.Proxy f :: Proxy (a :: Symbol) -> Int f _ = f (Proxy :: Proxy (Int -> Bool)) }}} With GHC 8.0 RC2, this leads to the following error: {{{ ? Expected kind ?Proxy ((->) Int Bool)?, but ?Data.Proxy.Proxy :: Proxy (Int -> Bool)? has kind ?Proxy (Int -> Bool)? ? In the first argument of ?f?, namely ?(Proxy :: Proxy (Int -> Bool))? In the expression: f (Proxy :: Proxy (Int -> Bool)) In an equation for ?f?: f _ = f (Proxy :: Proxy (Int -> Bool)) }}} or with `-fprint-explicit-kinds -fprint-explicit-coercions`: {{{ ? Expected kind ?Proxy Symbol (((->) |> <*>_N -> <*>_N -> U(hole:{aCy}, *, Symbol)_N) Int Bool)?, but ?(Data.Proxy.Proxy) @ k_aCv @ t_aCw :: Proxy (Int -> Bool)? has kind ?Proxy * (Int -> Bool)? }}} As Iavor, Richard and I discussed, this message has at least three separate problems: * It says `kind` when it should say `type`. * `((->) Int Bool)` is printed instead of `Int -> Bool` (because there is a coercion hiding in the type). * The real error is the insoluble constraint `Symbol ~ *`, which is not reported at all! The first two should be fairly easy to fix. For the third, when reporting insoluble constraints, we should prefer to report those on which no other constraints depend. (In this case, the presence of `hole:{aCy}` in the constraint is an explicit dependency on the other constraint.) I'll try to take a look at this. It is no doubt related to #11198. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 09:13:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 09:13:54 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.e8b40d090a3ba91d5e31b46c6ac5ffdd@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | ErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: TypeInType => TypeInType, ErrorMessages * related: => #11672 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 09:20:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 09:20:41 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.f0bace2f2f6978a75de2f867dbda71ac@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) * keywords: => ORF * component: Compiler => Compiler (Parser) Comment: This is simply because overloaded labels are lexed similarly to variables after the initial `#`. I don't think there is a fundamental reason we couldn't permit uppercase letters here, it would just require a bit of lexer hacking. That said, the original motivation for overloaded labels came from record fields, where the initial letter must be lowercase. So I'm two minds as to whether this is worthwhile or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 09:55:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 09:55:34 -0000 Subject: [GHC] #11672: Poor error message In-Reply-To: <049.cc2f48c705b5aa7c4431fbd88245f608@haskell.org> References: <049.cc2f48c705b5aa7c4431fbd88245f608@haskell.org> Message-ID: <064.e916a1a7d5230a46554d3ced02066f20@haskell.org> #11672: Poor error message -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Keywords: Resolution: | ErrorMessages, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: ErrorMessages => ErrorMessages, TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 10:50:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 10:50:40 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.a597663122d81ed7f42e8dc7b03a1f40@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by inaki): Just to elaborate on my motivation for asking this: in bindings to C libraries (say gtk), due to the requirement of uniqueness of identifiers, one ends up with rather long identifiers for constants, which are typically represented by different constructors for a certain sum type. See for example: https://hackage.haskell.org/package/gtk-0.14.2/docs/Graphics-UI-Gtk- General-Enums.html#t:TreeViewColumnSizing It would be much more convenient to be able to say {{{#!hs treeViewColumnSetSizing tvc #Fixed }}} rather than the current, much more verbose {{{#!hs treeViewColumnSetSizing tvc TreeViewColumnFixed }}} The former is just as typesafe, but much more pleasant to read and use, I think, and here it is fairly natural to expect the overloaded label to start with uppercase. It can just as easily be made to work with lowercase, but I think that from the point of view of the user of the library the version starting with uppercase is more natural. (As a side remark: the above is still unnecessarily verbose, with further use of OverloadedLabels we can shorten it to {{{#!hs set tvc [#sizing := #Fixed] }}} which is close to Python levels of convenience, while being perfectly type safe. This already works well in the haskell-gi autogenerated bindings for gtk, only that I need to replace `#Fixed` -> `#fixed` due to the parser limitation.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 11:17:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 11:17:48 -0000 Subject: [GHC] #11673: Doesn't accept type Message-ID: <051.f0a0d492de5d557f9297fab77b565adb@haskell.org> #11673: Doesn't accept type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs import Data.Kind import qualified Control.Category as Cat newtype Transformer f g where Transform :: (forall i. f i ~> g i) -> Transformer f g type family (~>) :: k -> k -> Type where (~>) = (->) (~>) = Transformer instance Cat.Category ((~>) :: k -> k -> Type) => Cat.Category (Transformer :: (i -> k) -> (i -> k) -> Type) where id :: forall (f :: i -> k). Transformer f f id = Transform Cat.id }}} works, as well as omitting the instance signature: {{{#!hs id = Transform Cat.id }}} Implicitly quantifying `f` or omitting its kind signature result in the same error: {{{#!hs id :: Transformer f f id = Transform Cat.id -- ? Could not deduce (Cat.Category (~>)) -- arising from a use of ?Cat.id? -- from the context: Cat.Category (~>) -- bound by the instance declaration at /tmp/tX81.hs:(13,3)-(15,60) -- ? In the first argument of ?Transform?, namely ?Cat.id? -- In the expression: Transform Cat.id -- In an equation for ?id?: id = Transform Cat.id -- Compilation failed. }}} Should it compile -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 11:58:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 11:58:06 -0000 Subject: [GHC] #11674: GHC accepts overly general instance sigs Message-ID: <051.fc63b7f2c244844e09d59fbdbb2dfe98@haskell.org> #11674: GHC accepts overly general instance sigs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: InstanceSigs | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE InstanceSigs #-} data I a = MkI a instance Functor I where fmap :: (a -> b) -> f a -> f b fmap = undefined }}} is accepted when the type is too general, even things like: {{{#!hs fmap :: (a -> b) -> f a -> g b -- & fmap :: whoami }}} are accepted -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 12:03:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 12:03:08 -0000 Subject: [GHC] #11312: GHC inlining primitive string literals can affect program output In-Reply-To: <050.6392f4ea96644f5394022cd373a55178@haskell.org> References: <050.6392f4ea96644f5394022cd373a55178@haskell.org> Message-ID: <065.4f0abe6e144dbfd80a780ff0babc3728@haskell.org> #11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by xnyhps): I hacked around with this a bit, these are my findings: * `ByteArray#` is represented as `StgArrBytes`, which includes a 1 word header and 1 word to indicate the size and is word aligned. This may be very convenient for things that want to use static `ByteArray#`s, but for usual string literals it sounds quite wasteful: on x86-64 it would require 24 bytes of padding to store a one-character string, instead of 2 for a zero-terminated string. (The alignment changes of #9577 would conflict with this, but it should still be possible to mark the sections as mergeable.) Considering that, and the existence of `byteArrayContents#`, I think it would be preferable to introduce a new primitive type `String#` that is used ''only'' for string literals. * Whichever different type `""#` gets, bootstrapping the compiler becomes tricky: the template for both Alex and Happy defines `""#` literals. What makes it worse is that this means stage 1 and stage 2 need a different template. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 16:26:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 16:26:21 -0000 Subject: [GHC] #11675: Monomoprhic code makes ImpredicativeTypes infer an existential type Message-ID: <048.f4d64f615ee9833f5ef6cf0df32ba64e@haskell.org> #11675: Monomoprhic code makes ImpredicativeTypes infer an existential type -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I realise that ImpredicativeTypes is a problematic extension, but I have found something that looks like an outright bug -- no polymorphism involved: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} module Foo where foo :: IO (Maybe Int) foo = do pure $ case undefined :: Maybe String of Nothing -> Nothing Just _ -> (undefined :: Maybe Int) }}} Produces the following errors: {{{ foo.hs:7:3: error: ? Couldn't match type ?forall a. Maybe a? with ?Maybe Int? Expected type: IO (Maybe Int) Actual type: IO (forall a. Maybe a) ? In a stmt of a 'do' block: pure $ case undefined :: Maybe String of { Nothing -> Nothing Just _ -> (undefined :: Maybe Int) } In the expression: do { pure $ case undefined :: Maybe String of { Nothing -> Nothing Just _ -> (undefined :: Maybe Int) } } In an equation for ?foo?: foo = do { pure $ case undefined :: Maybe String of { Nothing -> Nothing Just _ -> (undefined :: Maybe Int) } } foo.hs:11:19: error: ? Couldn't match type ?a? with ?Int? ?a? is a rigid type variable bound by a type expected by the context: forall a. Maybe a at foo.hs:11:19 Expected type: forall a. Maybe a Actual type: Maybe Int ? In the expression: (undefined :: Maybe Int) In a case alternative: Just _ -> (undefined :: Maybe Int) In the second argument of ?($)?, namely ?case undefined :: Maybe String of { Nothing -> Nothing Just _ -> (undefined :: Maybe Int) }? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 17:16:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 17:16:23 -0000 Subject: [GHC] #11676: Preserve name of original function in worker name Message-ID: <046.9564de68fd6f249b5e9dd2c92248810c@haskell.org> #11676: Preserve name of original function in worker name -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently it's not uncommon to find workers named, e.g., `$wa` while perusing Core. When you find one of these you need to then go searching for its associated wrapper to discover which function the worker implements. Then you need to work hard to keep this piece of information in your mental state. This is unfortunate and makes reading Core unnecessarily hard. Why not name the worker of `thisIsAFunction` something like, e.g., `thisIsAFunction$wa`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 17:19:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 17:19:57 -0000 Subject: [GHC] #11676: Preserve name of original function in worker name In-Reply-To: <046.9564de68fd6f249b5e9dd2c92248810c@haskell.org> References: <046.9564de68fd6f249b5e9dd2c92248810c@haskell.org> Message-ID: <061.1f7dee122deec7d7f1c5c6d6389f582f@haskell.org> #11676: Preserve name of original function in worker name -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It is. The worker for `foo` is `$wfoo`. So the function was called `a` in this case. So the culprit is not worker/wrapper, but something else. At a guess, it's `Simplify.makeTrivialWithInfo` which could use a more informative `OccName`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 17:22:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 17:22:48 -0000 Subject: [GHC] #11676: Preserve name of original function in worker name In-Reply-To: <046.9564de68fd6f249b5e9dd2c92248810c@haskell.org> References: <046.9564de68fd6f249b5e9dd2c92248810c@haskell.org> Message-ID: <061.767f88d9a1bd1907f515d75fb5807a62@haskell.org> #11676: Preserve name of original function in worker name -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed I just noticed that the name should be derived while browsing the source. `makeTrivialWithInfo` sounds quite likely; thanks for that reference, it would have taken quite a while for me to find that myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 17:29:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 17:29:52 -0000 Subject: [GHC] #11674: GHC accepts overly general instance sigs In-Reply-To: <051.fc63b7f2c244844e09d59fbdbb2dfe98@haskell.org> References: <051.fc63b7f2c244844e09d59fbdbb2dfe98@haskell.org> Message-ID: <066.0f0e6429f00962d61abb1844471f3ab3@haskell.org> #11674: GHC accepts overly general instance sigs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: invalid | Keywords: InstanceSigs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: That's fine. It's equivalent to this {{{ instance Functor I where fmap = fmapI fmapI :: (a -> b) -> f a -> f b fmapI = undefined }}} So we check (a) that the defined function has the specified type, and (b) that a function of the specified type is acceptable in the instance decl. See 9.7.3.7 under http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#instance-declarations. If the documentation should be clearer, could you suggest alternative wording that would have made it clearer? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 17:38:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 17:38:55 -0000 Subject: [GHC] #11673: Doesn't accept type In-Reply-To: <051.f0a0d492de5d557f9297fab77b565adb@haskell.org> References: <051.f0a0d492de5d557f9297fab77b565adb@haskell.org> Message-ID: <066.4341d6308852299a6f27796c3bfe1fdf@haskell.org> #11673: Doesn't accept type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Well, if you write {{{ instance ... where id :: Transformer f f id = ... }}} then GHC tries to understand the signature you wrote. Since `Transformer` poly-kinded, what you get is the signature {{{ id :: forall i k. forall (f :: i -> k). Transformer f foo }}} But `Cat.id` doesn't have that type. So I think this is just what's expected. Can you suggest any improvement to the user manual that would make this clearer? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 17:41:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 17:41:59 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.253a7347056d24b6dd1744ef50b91ff2@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): Thanks for expanding on your use case! I think you've convinced me that overloaded labels can just as well be used for overloading constructors as overloading field names, and hence it makes sense to allow the initial uppercase letter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 22:12:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 22:12:32 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.e4feae97c408922f87585daa28c7a88e@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by inaki): Thinking more about this, I came up with a small worry: having such overloaded constructors makes it very tempting to ask if it is possible to pattern match on these overloaded constructors. Simply desugaring to `fromLabel ...` seems to preclude this from working. Just for fun, I tried to come up with a desugaring that allows for pattern matching too, but I encountered a parsing problem when trying to explicitly apply types in a pattern, the following is the closest I could get: {{{#!hs {-# LANGUAGE DataKinds, FlexibleInstances, MultiParamTypeClasses, PatternSynonyms, ViewPatterns, ScopedTypeVariables, KindSignatures, TypeApplications #-} import GHC.TypeLits class IsOverloadedPattern (tag :: Symbol) (a :: *) where checkOverloadedPattern :: a -> Bool buildOverloadedPattern :: a pattern OverloadedPattern :: forall tag a. IsOverloadedPattern (tag :: Symbol) a => a pattern OverloadedPattern <- ((checkOverloadedPattern @tag @a) -> True) where OverloadedPattern = buildOverloadedPattern @tag @a data Statement = Provable | Refutable instance IsOverloadedPattern "Truish" Statement where checkOverloadedPattern Provable = True checkOverloadedPattern Refutable = False buildOverloadedPattern = Provable {- -- We would like to write something like: test :: Statement -> Int test #Truish = 42 test _ = -1 -- desugaring to test :: Statement -> Int test (OverloadedPattern @"Truish") = 42 test _ = -1 -} test2 :: Statement -> Int test2 Provable = 42 test2 _ = -1 main :: IO () main = print (test2 (OverloadedPattern @"Truish")) }}} One may also worry how to pattern match on multi-parameter constructors, which is not supported by the construction above. Perhaps there is some clever way of making overloaded constructors work everywhere a normal constructor would work? I guess that if #8583 was implemented we could use that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 22:30:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 22:30:16 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.0225f23a72f5e94494cedf3efd33e8af@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by inaki): Ah, there is actually already #11350 open about the parse failure above. But even if the above works I am not sure how to use the construction above to deal with cases like `#Just True`, say (i.e. overloaded constructors that take arguments). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 23:28:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 23:28:22 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.e129c5451206326f4d179ec6c8c777c2@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): If you want these values to actually look like constructors then have you tried using pattern synonyms? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 4 23:44:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Mar 2016 23:44:00 -0000 Subject: [GHC] #11667: Incorrect pattern synonym types in error messages In-Reply-To: <046.01f7d6134e84da2cd298573ade0572c4@haskell.org> References: <046.01f7d6134e84da2cd298573ade0572c4@haskell.org> Message-ID: <061.f51826c036fc9e2f8b865472c003b4be@haskell.org> #11667: Incorrect pattern synonym types in error messages -------------------------------------+------------------------------------- Reporter: rdragon | Owner: rdragon Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11213 | Differential Rev(s): Phab:D1967 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 Comment: There is a detailed comment describing the errors before and after rdragon's proposed solution on Phab:D1967. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 00:14:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 00:14:24 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.e6d01986e9a4a65a3e00e94c86697b93@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by inaki): Replying to [comment:6 mpickering]: > If you want these values to actually look like constructors then have you tried using pattern synonyms? Yes, indeed, that is what I do now. (For context, this is for https://github.com/haskell-gi/haskell-gi , a set of autogenerated libraries for a number of libraries in the gtk ecosystem.) The following works beautifully: {{{#!hs {-# LANGUAGE DataKinds, FlexibleInstances, MultiParamTypeClasses, PatternSynonyms, ViewPatterns, ScopedTypeVariables, KindSignatures, TypeApplications #-} import GHC.TypeLits class IsOverloadedPattern (tag :: Symbol) (a :: *) where checkOverloadedPattern :: a -> Bool buildOverloadedPattern :: a pattern Truish :: IsOverloadedPattern "Truish" a => a pattern Truish <- ((checkOverloadedPattern @"Truish") -> True) where Truish = buildOverloadedPattern @"Truish" data Statement = Provable | Refutable instance IsOverloadedPattern "Truish" Statement where checkOverloadedPattern Provable = True checkOverloadedPattern Refutable = False buildOverloadedPattern = Provable test :: Statement -> Int test Truish = 42 test _ = -1 main :: IO () main = print (test Truish) }}} The problem is that this requires one pattern for each constructor one wants to overload in this way. Which are quite a few hundred/thousand for a large library like gtk (or glib, webkit, etc.). Not an issue in itself, but we cannot ask the user of the library to write them by hand, they should be automatically in the namespace when importing `GI.Gtk` or any other autogenerated binding. And we cannot bundle this with the library directly, since patterns with the same name may be easily generated by different autogenerated libraries, giving rise to name clashes. The way we solve it now is by asking the user of the library to run some command such that all possible such patterns, for all libraries used in the project, are generated in advance, and compiled into a single module. The resulting module should then be compiled as part of the users's project. Which works, but it is clunky. In similar situations (overloaded property names and overloaded signals) we can do away completely with this somewhat annoying "overloading module" by using OverloadedLabels, but I don't currently see a way of doing the same thing allowing to pattern match against the overloaded symbols. The construction in #comment:4 comes close, perhaps it can be made to work somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 00:29:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 00:29:45 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.1c4753abafbba3125b48624053468232@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by inaki): I should add one point: some of the possible constructors that we want to overload can be fairly generic words (`Nothing`, for instance, is one). Having the `#` character in front helps a lot in here, since it makes the distinction between `Nothing` (constructor of `Maybe a` type) and `#Nothing` (some pattern to be resolved depending on the usage location). So creating patterns explicitly easily leads to name clashes with ordinary constructors. To avoid this currently we add a final underscore (`Nothing` -> `Nothing_`), but this final underscore is easy to forget, and not that nice as a solution. Having a OverloadedLabels style solution would be much nicer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 03:38:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 03:38:59 -0000 Subject: [GHC] #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options Message-ID: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options -------------------------------------+------------------------------------- Reporter: malphunction | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: optimization | Operating System: Linux deoptimization | Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Look for this simple program: {{{#!hs: import Control.Monad import Data.Maybe -- import qualified Data.HashMap.Strict as M -- import qualified Data.Map.Lazy as M import qualified Data.Map.Strict as M -- import Control.DeepSeq -- import Control.Exception main :: IO () main = do putStrLn "Start" n <- read <$> getLine q <- read <$> getLine dict' <- M.fromList <$> replicateM n ((\(k:v:_) -> (k,v)) <$> words <$> getLine) -- dict <- evaluate $ force dict' let dict = dict' count <- length <$> catMaybes <$> replicateM q (flip M.lookup dict <$> getLine) print count }}} When compiled __without__ "-O2" it runs about 0.07 sec on my computer. But when compiled __with__ "-O2" it runs about 77 sec (1100 times slowly!). Look: compile and run without "-O2": {{{ % rm -rf ./mime_type mime_type.{o,hi} && ghc mime_type.hs -o mime_type && cat my_data.txt | time ./mime_type [1 of 1] Compiling Main ( mime_type.hs, mime_type.o ) Linking mime_type ... Start 4738 ./mime_type 0,06s user 0,01s system 97% cpu 0,069 total }}} And with "-O2": {{{ % rm -rf ./mime_type mime_type.{o,hi} && ghc -O2 mime_type.hs -o mime_type && cat my_data.txt | time ./mime_type [1 of 1] Compiling Main ( mime_type.hs, mime_type.o ) Linking mime_type ... Start 4738 ./mime_type 76,73s user 0,10s system 99% cpu 1:17,12 total }}} But when force `dict` variable (`dict <- evaluate $ force dict'`), it runs fast in both cases (with and without "-O2"). Also this bug is reproductable with "-O", "-O1" options. Also this bug is reproductable with GHC 7.10.2 and GHC 8.0.1-rc2 (The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204). Data file my_data.txt is attached. It has simple structure: * N, number of key-value pairs * K, number of keys for searching * N key-value pairs * K kes You can generate it with this Ruby script: {{{ #!/usr/bin/env ruyb lst = ('a'..'z').to_a N = 10000 K = 10000 File.open('my_data.txt', 'w') do |f| f.puts(N) f.puts(K) N.times do f.puts("#{lst.sample(3).join} #{lst.sample(5).join}") # f.puts("(\"#{lst.sample(3).join}\",\"#{lst.sample(5).join}\")") end K.times do f.puts("#{lst.sample(3).join}") end end }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 03:40:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 03:40:19 -0000 Subject: [GHC] #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options In-Reply-To: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> References: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> Message-ID: <066.a3f032f41bbe2be6e8cf8d4b38a02d1d@haskell.org> #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options -------------------------------------+------------------------------------- Reporter: malphunction | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: optimization | deoptimization Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by malphunction): * Attachment "my_data.txt" added. Test data -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 03:46:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 03:46:43 -0000 Subject: [GHC] #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options In-Reply-To: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> References: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> Message-ID: <066.1c3ed290918ad6a0226f96b547f1df4f@haskell.org> #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options -------------------------------------+------------------------------------- Reporter: malphunction | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: optimization | deoptimization Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by malphunction: @@ -77,1 +77,1 @@ - #!/usr/bin/env ruyb + #!/usr/bin/env ruby New description: Look for this simple program: {{{#!hs: import Control.Monad import Data.Maybe -- import qualified Data.HashMap.Strict as M -- import qualified Data.Map.Lazy as M import qualified Data.Map.Strict as M -- import Control.DeepSeq -- import Control.Exception main :: IO () main = do putStrLn "Start" n <- read <$> getLine q <- read <$> getLine dict' <- M.fromList <$> replicateM n ((\(k:v:_) -> (k,v)) <$> words <$> getLine) -- dict <- evaluate $ force dict' let dict = dict' count <- length <$> catMaybes <$> replicateM q (flip M.lookup dict <$> getLine) print count }}} When compiled __without__ "-O2" it runs about 0.07 sec on my computer. But when compiled __with__ "-O2" it runs about 77 sec (1100 times slowly!). Look: compile and run without "-O2": {{{ % rm -rf ./mime_type mime_type.{o,hi} && ghc mime_type.hs -o mime_type && cat my_data.txt | time ./mime_type [1 of 1] Compiling Main ( mime_type.hs, mime_type.o ) Linking mime_type ... Start 4738 ./mime_type 0,06s user 0,01s system 97% cpu 0,069 total }}} And with "-O2": {{{ % rm -rf ./mime_type mime_type.{o,hi} && ghc -O2 mime_type.hs -o mime_type && cat my_data.txt | time ./mime_type [1 of 1] Compiling Main ( mime_type.hs, mime_type.o ) Linking mime_type ... Start 4738 ./mime_type 76,73s user 0,10s system 99% cpu 1:17,12 total }}} But when force `dict` variable (`dict <- evaluate $ force dict'`), it runs fast in both cases (with and without "-O2"). Also this bug is reproductable with "-O", "-O1" options. Also this bug is reproductable with GHC 7.10.2 and GHC 8.0.1-rc2 (The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204). Data file my_data.txt is attached. It has simple structure: * N, number of key-value pairs * K, number of keys for searching * N key-value pairs * K kes You can generate it with this Ruby script: {{{ #!/usr/bin/env ruby lst = ('a'..'z').to_a N = 10000 K = 10000 File.open('my_data.txt', 'w') do |f| f.puts(N) f.puts(K) N.times do f.puts("#{lst.sample(3).join} #{lst.sample(5).join}") # f.puts("(\"#{lst.sample(3).join}\",\"#{lst.sample(5).join}\")") end K.times do f.puts("#{lst.sample(3).join}") end end }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 03:48:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 03:48:46 -0000 Subject: [GHC] #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options In-Reply-To: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> References: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> Message-ID: <066.7edb70fb87550f9d91a658b045757dd3@haskell.org> #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options -------------------------------------+------------------------------------- Reporter: malphunction | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: optimization | deoptimization Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by malphunction: @@ -66,0 +66,3 @@ + Also this bug is reproductable with .Strict and .Lazy versions; and with + Data.HashMap, .Strict and .Lazy + New description: Look for this simple program: {{{#!hs: import Control.Monad import Data.Maybe -- import qualified Data.HashMap.Strict as M -- import qualified Data.Map.Lazy as M import qualified Data.Map.Strict as M -- import Control.DeepSeq -- import Control.Exception main :: IO () main = do putStrLn "Start" n <- read <$> getLine q <- read <$> getLine dict' <- M.fromList <$> replicateM n ((\(k:v:_) -> (k,v)) <$> words <$> getLine) -- dict <- evaluate $ force dict' let dict = dict' count <- length <$> catMaybes <$> replicateM q (flip M.lookup dict <$> getLine) print count }}} When compiled __without__ "-O2" it runs about 0.07 sec on my computer. But when compiled __with__ "-O2" it runs about 77 sec (1100 times slowly!). Look: compile and run without "-O2": {{{ % rm -rf ./mime_type mime_type.{o,hi} && ghc mime_type.hs -o mime_type && cat my_data.txt | time ./mime_type [1 of 1] Compiling Main ( mime_type.hs, mime_type.o ) Linking mime_type ... Start 4738 ./mime_type 0,06s user 0,01s system 97% cpu 0,069 total }}} And with "-O2": {{{ % rm -rf ./mime_type mime_type.{o,hi} && ghc -O2 mime_type.hs -o mime_type && cat my_data.txt | time ./mime_type [1 of 1] Compiling Main ( mime_type.hs, mime_type.o ) Linking mime_type ... Start 4738 ./mime_type 76,73s user 0,10s system 99% cpu 1:17,12 total }}} But when force `dict` variable (`dict <- evaluate $ force dict'`), it runs fast in both cases (with and without "-O2"). Also this bug is reproductable with "-O", "-O1" options. Also this bug is reproductable with .Strict and .Lazy versions; and with Data.HashMap, .Strict and .Lazy Also this bug is reproductable with GHC 7.10.2 and GHC 8.0.1-rc2 (The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204). Data file my_data.txt is attached. It has simple structure: * N, number of key-value pairs * K, number of keys for searching * N key-value pairs * K kes You can generate it with this Ruby script: {{{ #!/usr/bin/env ruby lst = ('a'..'z').to_a N = 10000 K = 10000 File.open('my_data.txt', 'w') do |f| f.puts(N) f.puts(K) N.times do f.puts("#{lst.sample(3).join} #{lst.sample(5).join}") # f.puts("(\"#{lst.sample(3).join}\",\"#{lst.sample(5).join}\")") end K.times do f.puts("#{lst.sample(3).join}") end end }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 11:45:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 11:45:26 -0000 Subject: [GHC] #11678: runhaskell (and ghc, ghci) fail to run if HOME is not set Message-ID: <046.9c5274446945cc784560071347805372@haskell.org> #11678: runhaskell (and ghc, ghci) fail to run if HOME is not set -------------------------------------+------------------------------------- Reporter: crosser | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Steps to reproduce: {{{ $ env -i ghc HOME: getAppUserDataDirectory: does not exist (no environment variable) $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 }}} This may be not a big deal for the compiler and repl, but there are use cases to run `runhaskell` without HOME, e.g. I encountered this when running a cgi script under Apache. I think that the problem was introduced after 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 12:05:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 12:05:06 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.7083cdedccc4e3df3d08e60db8275032@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): A small status update: this is tricky! Replying to [comment:37 goldfire]: > In particular, GHC already does dependency analysis and chunking, and it would be terribly wrong not to have splicy things depend on everything else in the declaration group. I can't actually see that this is true for ''untyped'' splices! For ''typed'' splices I think it happens in the renamer, here: https://github.com/ghc/ghc/blob/master/compiler/rename/RnSplice.hs#L403 But I haven't found an equivalent for untyped splices. > The only problem, I believe, is that type-checking is held off until the whole group is renamed. (Splice action happens in the renamer.) It may or may not be hard to change that routing. Yes, this is indeed the case. In particular, renaming of the group happens first, here: https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcRnDriver.hs#L558 before type checking of the group's declarations happens later, here: https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcRnDriver.hs#L596 Since `reify` is called during renaming, it fails since the type environments do not contain the names in question. I'm a bit stuck as to how to proceed! Perhaps the obvious question is: is there a particular reason to run untyped splices in the renamer vs the typechecker? I assume we can't do proper dependency analysis until after renaming, so I'm not sure it's possible to do the dependency sorting 'before' renaming (such that we could rename/typecheck non-splicy declarations before splicy declarations). If we could run untyped splices in the typechecker i.e. after renaming and dependency analysis, I assume we would be able to refer to names earlier in the dependency ordering. Any thoughts/advice that may get me unstuck? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 13:03:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 13:03:36 -0000 Subject: [GHC] #11145: Template Haskell quotes of data instance GADTs is totally broken In-Reply-To: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> References: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> Message-ID: <062.86b510aa4186bdbc55e3b6827e19c987@haskell.org> #11145: Template Haskell quotes of data instance GADTs is totally broken -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bollmann): while this problem persists in `7.10.3`, it is not present in `HEAD` (aea1e5db...) anymore. In the latter, the raised error is: {{{ ghc-stage2 Fuggle.hs -XTemplateHaskell -ddump-splices [1 of 1] Compiling Fuggle ( Fuggle.hs, Fuggle.o ) Fuggle.hs:(9,1)-(10,44): Splicing declarations [d| data instance Fuggle Int (Maybe (a_ap6, b_ap7)) where MkFuggle_ap5 :: Fuggle Int (Maybe Bool) |] ======> data instance Fuggle Int (Maybe (a_a4RB, b_a4RC)) where MkFuggle_a4RA :: Fuggle Int (Maybe Bool) Fuggle.hs:9:1: error: ? Data constructor ?MkFuggle? returns type ?Fuggle Int (Maybe Bool)? instead of an instance of its parent type ?Fuggle Int (Maybe (a_a4RB, b_a4RC))? ? In the definition of data constructor ?MkFuggle? In the data instance declaration for ?Fuggle? }}} So it seems to have been fixed (I don't know whether it was Phab:D1465 or something else, though) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 13:07:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 13:07:26 -0000 Subject: [GHC] #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options In-Reply-To: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> References: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> Message-ID: <066.5cc00d4b6e877cb9d5606f8820928db6@haskell.org> #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options -------------------------------------+------------------------------------- Reporter: malphunction | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: optimization | deoptimization Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by malphunction): Update: if disable `-fenable-rewrite-rule` (i.e. `-O2 -fno-enable-rewrite- rule`), then compiled program runs fast! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 13:56:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 13:56:24 -0000 Subject: [GHC] #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options In-Reply-To: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> References: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> Message-ID: <066.a8cc37da002c3bc1d125b8f60af2d711@haskell.org> #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options -------------------------------------+------------------------------------- Reporter: malphunction | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: optimization | deoptimization Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks for the excellent description and testcase! The problem here is that GHC is inlining the definition of `dict` with `-O1`. This means that your transformed program looks like, {{{#!hs dict' <- replicateM n ((\(k:v:_) -> (k,v)) <$> words <$> getLine) count <- length <$> catMaybes <$> replicateM q (flip M.lookup (M.fromList dict) <$> getLine) }}} Meaning that the `Map` is being reconstructed with every line that is read. You can easily discourage GHC from performing this inlining by placing a bang on the `dict'` binding, {{{#!hs !dict' <- M.fromList <$> replicateM n ((\(k:v:_) -> (k,v)) <$> words <$> getLine) }}} You were accomplishing this same end with your `evaluate $ deepseq`, but more "forcefully". Indeed it is a bit unfortunate that GHC decides that this inlining is beneficial, but I'm not entirely sure how it could know otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 13:59:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 13:59:11 -0000 Subject: [GHC] #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options In-Reply-To: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> References: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> Message-ID: <066.0f8f3bdccc39a8f8beecd954e0abdca2@haskell.org> #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options -------------------------------------+------------------------------------- Reporter: malphunction | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: optimization | deoptimization Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, I concluded this by comparing the output of `-ddump-simpl -dsuppress-all` from the testcases compiled with `-O1` with and without the `evaluate $ deepseq`. The delta in the Core produced in these two cases is extremely small, {{{#!diff @@ -297,6 +302,16 @@ case $wa @ (String, String) ww1 (lvl3 `cast` ...) ipv4 of _ { (# ipv6, ipv7 #) -> case $sfromList @ [Char] ipv7 of dict' { __DEFAULT -> + case seq# + @ (Map String String) + @ RealWorld + (case $fNFDataMap_$crnf + @ [Char] @ [Char] ($sforce3 `cast` ...) ($sforce3 `cast` ...) dict' + of _ { () -> + dict' + }) + ipv6 + of _ { (# ipv8, ipv9 #) -> case readEither6 @ Int (run @ Int lvl2 ipv5) of _ { [] -> case error @@ -306,8 +321,8 @@ readEither4 of wild3 { }; - : x1 ds5 -> - case ds5 of _ { + : x1 ds6 -> + case ds6 of _ { [] -> case x1 of _ { I# ww3 -> case $wa @@ -316,25 +331,25 @@ ((\ (eta :: State# RealWorld) -> case wantReadableHandle_1 @ String hGetLine4 stdin (hGetLine2 `cast` ...) eta - of _ { (# ipv8, ipv9 #) -> - (# ipv8, $slookup1 @ [Char] ipv9 dict' #) + of _ { (# ipv10, ipv11 #) -> + (# ipv10, $slookup1 @ [Char] ipv11 ipv9 #) }) `cast` ...) - ipv6 - of _ { (# ipv8, ipv9 #) -> + ipv8 + of _ { (# ipv10, ipv11 #) -> hPutStr2 stdout - (case $wlenAcc @ [Char] (catMaybes1 @ String ipv9) 0# + (case $wlenAcc @ [Char] (catMaybes1 @ String ipv11) 0# of ww4 { __DEFAULT -> case $wshowSignedInt 0# ww4 ([] @ Char) of _ { (# ww6, ww7 #) -> : @ Char ww6 ww7 } }) True - ipv8 + ipv10 } }; - : ipv8 ipv9 -> + : ipv10 ipv11 -> case error @ 'PtrRepLifted @ Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 14:22:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 14:22:14 -0000 Subject: [GHC] #11679: Quasi-quoting syntax is ambiguous with list comprehensions Message-ID: <046.e4bc67337e38c6a1747904f615313ea3@haskell.org> #11679: Quasi-quoting syntax is ambiguous with list comprehensions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is an unfortunate ambiguity between list comprehension syntax and quasi-quotation. Consider the following with and without `-XQuasiQuotes` (noted [[https://github.com/haskell/haskell- mode/issues/1185#issuecomment-192624592|here]], {{{#!hs let x = [ v | v <- [1,2,3]] let x = [v| v <- [1,2,3]] }}} While the former is always a list comprehension, the latter is a quasi- quote when `-XQuasiQuotes` is enabled. The original quasi-quoting syntax required a dollar sign before the quoter, although this was dropped in 26f164e5759e9eca73deb0531ddec422d36a6924. 9ba922ee06b048774d7a82964867ff768a78126e suggests that the old dollar sign syntax is slated for eventual removal. Unfortunately, given it has been five years since the requirement for a dollar sign was dropped I suspect it's a bit late to revert to the previous syntax. This ticket is simply meant to document the fact that this ambiguity exists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 15:03:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 15:03:54 -0000 Subject: [GHC] #11678: runhaskell (and ghc, ghci) fail to run if HOME is not set In-Reply-To: <046.9c5274446945cc784560071347805372@haskell.org> References: <046.9c5274446945cc784560071347805372@haskell.org> Message-ID: <061.50b63cae86693b62727f076b402aa880@haskell.org> #11678: runhaskell (and ghc, ghci) fail to run if HOME is not set -------------------------------------+------------------------------------- Reporter: crosser | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1971 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1971 * milestone: => 8.0.1 Comment: This patch should at least help. There still make be the matter of how to deal with the user package database (which is in the default database list) being missing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 15:16:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 15:16:27 -0000 Subject: [GHC] #11678: runhaskell (and ghc, ghci) fail to run if HOME is not set In-Reply-To: <046.9c5274446945cc784560071347805372@haskell.org> References: <046.9c5274446945cc784560071347805372@haskell.org> Message-ID: <061.1943e0d378d2f00d5e7fe4f08095d253@haskell.org> #11678: runhaskell (and ghc, ghci) fail to run if HOME is not set -------------------------------------+------------------------------------- Reporter: crosser | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1971 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): ghc(i) already worked fine with `HOME=/` or some other nonsense value causing there to be no existent user package database. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 15:58:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 15:58:18 -0000 Subject: [GHC] #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH Message-ID: <042.98f1e89f02393a599dc5a3ef57e2d85f@haskell.org> #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH -------------------------------------+------------------------------------- Reporter: jme | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With GHC 8.x, compiling {{{#!hs {-# LANGUAGE TemplateHaskell #-} module A where import Language.Haskell.TH sep :: Q [Dec] sep = [d| x = () |] }}} and {{{#!hs {-# LANGUAGE TemplateHaskell #-} module B where import A f :: Int f = foo $(sep) foo :: Int foo = 3 }}} produces {{{ $ ghc-HEAD/inplace/bin/ghc-stage2 --version The Glorious Glasgow Haskell Compilation System, version 8.1.20160303 $ ghc-HEAD/inplace/bin/ghc-stage2 B.hs [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) B.hs:8:5: error: ? Variable not in scope: foo :: Int ? Perhaps you meant ?foo? (line 13) }}} The problem is that when the typechecker constructs the suggestion, it uses the currently available `GlobalRdrEnv` rather than the one in existence when the renamer determined that `foo` is unbound. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 17:41:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 17:41:36 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.f53d50b14efc3a681543386001da74eb@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by slyfox): I've also tried to build m68k crosscompiler (using https://wiki.debian.org/M68k/sbuildQEMU to test produced binaries) and noticed GHC has the issue similar to: http://bugs.python.org/issue17237 m68k aligns structs containing integers and pointers to 2 bytes (not 4 bytes). That makes StgClosure struct addresses look tagged even if they are not. An example of GHC's startup crash. Test checks if untagging macro works: {{{ Core was generated by `/tmp/a +RTS -Ds -Di -Dw -DG -Dg -Db -DS -Dt -Dp -Da -Dl -Dm -Dz -Dc -Dr'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 248 return (info->type != INVALID_OBJECT && info->type < N_CLOSURE_TYPES) ? rtsTrue : rtsFalse; (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e ) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (argc=0xf6ffebf0, argv=0xf6ffebf4, rts_config=...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (argc=1, argv=0xf6ffed54, main_closure=0x804b8f70 , rts_config=...) at rts/RtsMain.c:51 #6 0x80003c1c in main () }}} GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e ) One more thing to tweak. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 18:02:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 18:02:23 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.747a97b7f73312f28c7fc9258c1ceba7@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1973 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1973 Comment: Phab:D1973 performs carries out the changes proposed in comment:11; Phab:D1972 changes a few points in the IO system to use the strict `catchException`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 19:33:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 19:33:17 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.acf2091783edd49980a6c8ff1fa121ce@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by slyfox): Sent the patch for review addressing comment 16: Phab:D1974 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 20:13:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 20:13:39 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.bdb9bd98004758019ff562924f38f237@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 Comment: Replying to [comment:24 goldfire]: > I think we can have our cake and eat it too. Just use a new module name and then we can have `Data.Typeable.TypeRep` be different from `Data.Reflection.TypeRep`. (Of course, we can keep just one `Typeable`, happily.) This is an interesting idea; it would be great to be able to pull off this change without massive code breakage. That being said, to pick on the particular choice of names `Reflection` and `Typeable`: My only concern is that neither of these names suggest indexed or un-indexed other than the fact that `Data.Typeable` is currently unindexed. It would be nice to have a justification for these names for someone coming to the language without this historical context. Richard, can you think of a rationale here? I'm having trouble thinking of another name than `Reflection` that has a better story here. > I vastly prefer `TypeRep` and `TypeRepX` over `TTypeRep` and `TypeRep`. But I have no great reason for doing so. Right, I think I've also come around this view as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 20:15:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 20:15:12 -0000 Subject: [GHC] #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors In-Reply-To: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> References: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> Message-ID: <061.74cc44664a2f217679332b85213f64e9@haskell.org> #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Package system | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1892 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1f3d953e97f3c107f76d992bd087ed91f72d24e1/ghc" 1f3d953/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f3d953e97f3c107f76d992bd087ed91f72d24e1" users-guide: Mention #11558 in release notes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 20:15:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 20:15:12 -0000 Subject: [GHC] #4029: ghci leaks memory when loading a file In-Reply-To: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> References: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> Message-ID: <061.776338746df3b1a597d8d6a20eddd9a9@haskell.org> #4029: ghci leaks memory when loading a file -------------------------------------+------------------------------------- Reporter: blarsen | Owner: jme Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: GHCi | Version: Resolution: | Keywords: memory leak Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1950 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6ca9b15f77e58931953edb7c872b803cb261fce9/ghc" 6ca9b15/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6ca9b15f77e58931953edb7c872b803cb261fce9" GHCi: Fix load/reload space leaks (#4029) This patch addresses GHCi load/reload space leaks which could be fixed without adversely affecting performance. Test Plan: make test "TEST=T4029" Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D1950 GHC Trac Issues: #4029 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 20:15:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 20:15:12 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.144ef9d419ecee7e15c83e35f3f4e02e@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"120b9cdb31878ecee442c0a4bb9532a9d30c0c64/ghc" 120b9cdb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="120b9cdb31878ecee442c0a4bb9532a9d30c0c64" rts/timer: use timerfd_* on Linux instead of alarm signals Reviewers: erikd, simonmar, austin, bgamari Reviewed By: simonmar, bgamari Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D1947 GHC Trac Issues: #10840 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 20:15:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 20:15:12 -0000 Subject: [GHC] #11524: Something is amiss with quantification in pattern synonym type signatures In-Reply-To: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> References: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> Message-ID: <061.bc06e926a3659b45eb7f6b304a5634f7@haskell.org> #11524: Something is amiss with quantification in pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1879, Wiki Page: | Phab:D1896 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3801262e89957a0fceeec0c5683045cf327aac64/ghc" 3801262e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3801262e89957a0fceeec0c5683045cf327aac64" Fix printing of an `IfacePatSyn` Now the existentially quantified type variables are printed at the correct location when printing a pattern synonym type from an `IfacePatSyn`. The function `pprIfaceContextMaybe` has been removed as it is no longer needed. Fixes #11524. Reviewers: austin, goldfire, thomie, bgamari, mpickering Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1958 GHC Trac Issues: #11524 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 20:15:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 20:15:12 -0000 Subject: [GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory In-Reply-To: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> References: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> Message-ID: <067.112c6dad045119b45d5f9e8392e1bacb@haskell.org> #9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: mergeconflict | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1d6177b133f3a6ac28cc8a679807563cfca3c56a/ghc" 1d6177b1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1d6177b133f3a6ac28cc8a679807563cfca3c56a" Using unsafe foreign import for rtsSupportsBoundThreads (part of #9696) A safe import is unnecessary considering rtsSupportsBoundThreads simply returns a constant. This commit doesn't fix the main issue of ticket #9696 that "readRawBufferPtr and writeRawBufferPtr allocate memory". Reviewers: bgamari, austin, hvr Reviewed By: hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1964 GHC Trac Issues: #9696 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 20:15:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 20:15:12 -0000 Subject: [GHC] #11662: Regression using NamedFieldPuns with qualified field names In-Reply-To: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> References: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> Message-ID: <063.9c4da3c43df316af3dde70b4cbce2f25@haskell.org> #11662: Regression using NamedFieldPuns with qualified field names -------------------------------------+------------------------------------- Reporter: hesselink | Owner: adamgundry Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T11662 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1965 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bd681bceba535d0e67e8182964dc167877e4756d/ghc" bd681bce/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bd681bceba535d0e67e8182964dc167877e4756d" Drop module qualifier from punned record fields (#11662) A record pattern match, construction or update like `Rec { Mod.f }` should expand to `Rec { Mod.f = f }` rather than `Rec { Mod.f = Mod.f }`. Test Plan: New test rename/should_compile/T11662 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: hesselink, thomie Differential Revision: https://phabricator.haskell.org/D1965 GHC Trac Issues: #11662 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 20:24:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 20:24:32 -0000 Subject: [GHC] #4029: ghci leaks memory when loading a file In-Reply-To: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> References: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> Message-ID: <061.0e80dbc88b6faa898a68be26042082cb@haskell.org> #4029: ghci leaks memory when loading a file -------------------------------------+------------------------------------- Reporter: blarsen | Owner: jme Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: GHCi | Version: Resolution: fixed | Keywords: memory leak Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1950 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 6ae616f5be1db6da8bc0c5e36736a76cfea46844. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 20:25:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 20:25:16 -0000 Subject: [GHC] #11524: Something is amiss with quantification in pattern synonym type signatures In-Reply-To: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> References: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> Message-ID: <061.b4805e8530f334640543754b144ced90@haskell.org> #11524: Something is amiss with quantification in pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1879, Wiki Page: | Phab:D1896 -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.0` as fe7eb57c41739b199a77e460b22d6353b91a14c3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 20:26:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 20:26:03 -0000 Subject: [GHC] #11662: Regression using NamedFieldPuns with qualified field names In-Reply-To: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> References: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> Message-ID: <063.9b989c97c07dd58e2a18564c794e3306@haskell.org> #11662: Regression using NamedFieldPuns with qualified field names -------------------------------------+------------------------------------- Reporter: hesselink | Owner: adamgundry Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T11662 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1965 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 20:26:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 20:26:12 -0000 Subject: [GHC] #11524: Something is amiss with quantification in pattern synonym type signatures In-Reply-To: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> References: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> Message-ID: <061.22be4b2c592cb655592f6dd926e63c41@haskell.org> #11524: Something is amiss with quantification in pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1879, Wiki Page: | Phab:D1896 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 20:26:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 20:26:24 -0000 Subject: [GHC] #11662: Regression using NamedFieldPuns with qualified field names In-Reply-To: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> References: <048.f45a43c440c1f858ea43fa5b646d36d4@haskell.org> Message-ID: <063.b8bed65458a6c00fa3111d5e054b59d2@haskell.org> #11662: Regression using NamedFieldPuns with qualified field names -------------------------------------+------------------------------------- Reporter: hesselink | Owner: adamgundry Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Parser) | Resolution: fixed | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T11662 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1965 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as da69d6710f69bdb8b4864f354ab9b8bdcb0167e8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 21:34:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 21:34:53 -0000 Subject: [GHC] #11676: Preserve name of original function in worker name In-Reply-To: <046.9564de68fd6f249b5e9dd2c92248810c@haskell.org> References: <046.9564de68fd6f249b5e9dd2c92248810c@haskell.org> Message-ID: <061.4dec6f2638d778fc27ee963999d99aa5@haskell.org> #11676: Preserve name of original function in worker name -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1970 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1970 Comment: Phab:D1970 is an attempt at coercing `makeTrivialWithInfo` into generating more useful names. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 21:51:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 21:51:33 -0000 Subject: [GHC] #11681: ghc panic with TypeError Message-ID: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> #11681: ghc panic with TypeError -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When playing around with `TypeError` I got a ghc panic with the following code: {{{#!hs {-# LANGUAGE DataKinds, FlexibleContexts, TypeOperators, FlexibleInstances, UndecidableInstances #-} import GHC.TypeLits class C t where instance (TypeError (Text "A" :<>: {- Text -} "B")) => C t where main :: IO () main = return () }}} Compiling this results in {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160204 for x86_64-unknown-linux): fvProv falls into a hole {a1bh} }}} Commenting "in" the second `Text` removes the panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 22:12:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 22:12:49 -0000 Subject: [GHC] #11681: ghc panic with TypeError In-Reply-To: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> References: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> Message-ID: <059.c304929caf562f1b604ee1bce09d52fb@haskell.org> #11681: ghc panic with TypeError -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Compile-time crash * version: 7.10.3 => 8.0.1-rc2 * component: Compiler => Compiler (Type checker) * milestone: => 8.0.1 Comment: What GHC version were you attempting to compile with? I don't believe it could have been 7.10.3 given that `TypeError` was only introduced in 8.0.1. Unfortunately, I'm having trouble reproducing this with any of the 8.0.1 release candidates. In all cases I get, {{{#!hs $ ghc Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Test.hs:8:42: error: ? Expected kind ?ErrorMessage?, but ?"B"? has kind ?Symbol? ? In the second argument of ?:<>:?, namely ?"B"? In the first argument of ?TypeError?, namely ?Text "A" :<>: "B"? In the instance declaration for ?C t? }}} which appears to be the correct error. There have been a number of similar tickets which have been recently closed (e.g. #11563) with, [changeset:"b565830dda0994d5d67617039db3310f81e831c8/ghc" b565830d/ghc]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 22:13:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 22:13:41 -0000 Subject: [GHC] #11516: Panic, "falls into a hole" In-Reply-To: <051.f6bcca55b0b02654ebc7a8da6d28be6c@haskell.org> References: <051.f6bcca55b0b02654ebc7a8da6d28be6c@haskell.org> Message-ID: <066.efc64b754db5257841b4a012b1655a18@haskell.org> #11516: Panic, "falls into a hole" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | polykinds/T11516 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.2.1 => 8.0.2 Comment: Merged to `ghc-8.0` as d0010d749f80b405f991e88e0e953a21d54a744d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 22:21:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 22:21:00 -0000 Subject: [GHC] #11681: ghc panic with TypeError In-Reply-To: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> References: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> Message-ID: <059.8f2e4fa188cec64184fb24a117dabaa3@haskell.org> #11681: ghc panic with TypeError -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by inaki): Sorry, I forgot to change the version field! I am testing with the latest ghc version available in fedora, it is tagged as `8.0.0.20160204` (so around one month old version, seems like). If it doesn't happen with the release candidates it is probably safe to assume that it got fixed in the meantime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 22:28:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 22:28:35 -0000 Subject: [GHC] #11681: ghc panic with TypeError In-Reply-To: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> References: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> Message-ID: <059.7bc9a48656e228be0de18509a0d9c0af@haskell.org> #11681: ghc panic with TypeError -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, yes, I should have noticed that in the GHC output in your description. That is -rc2. I am quite confused in that case as I can't seem to reproduce this with -rc2. Very perplexing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 22:42:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 22:42:21 -0000 Subject: [GHC] #11681: ghc panic with TypeError In-Reply-To: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> References: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> Message-ID: <059.04dc0b5c9de0399f5d3748cca1530fd4@haskell.org> #11681: ghc panic with TypeError -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by inaki): Replying to [comment:3 bgamari]: > Ahh, yes, I should have noticed that in the GHC output in your description. That is -rc2. > > I am quite confused in that case as I can't seem to reproduce this with -rc2. Very perplexing. Weird. I will keep an eye on this then, as soon as there is a new version available in fedora I will check and report whether it works or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 5 23:52:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Mar 2016 23:52:24 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.019a0924956afd05b11f766cf82396ec@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by slyfox): Sent slightly tweaked 0001-c-codegen-split-external-symbol-prototypes- EF_.patch for review as Phab:D1975 With both Phab:D1974 and Phab:D1975 I get hello world working on qemu-m68k in vanilla -dynamic and -prof modes. Don't know about ghc itself as my emulator can't handle generated code yet: $ inplace/bin/ghc-stage2 --make /tmp/a.hs /home/slyfox/dev/git/qemu-m68k/tcg/tcg.c:1774: tcg fatal error -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 01:19:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 01:19:39 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.15d73d6b3869f4c7eb7a79ae9fcdf89e@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by glaubitz): Replying to [comment:18 slyfox]: > With both Phab:D1974 and Phab:D1975 > I get hello world working on qemu-m68k in vanilla -dynamic and -prof modes. Wow, I am very excited to hear this! Thanks a lot for investing your time into fixing this. Also, I was very happy to see another bug in qemu-m68k being squashed in the process. Looking forward to test the changes once they have been merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 01:28:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 01:28:38 -0000 Subject: [GHC] #11682: :main doesn't use a bound thread Message-ID: <044.c6683bf737f3b4711653e56c257d3749@haskell.org> #11682: :main doesn't use a bound thread -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here is a short program: {{{ import Control.Concurrent main = do bound <- isCurrentThreadBound print (bound == rtsSupportsBoundThreads) }}} When compiled (with or without {{{-threaded}}}), it prints {{{True}}}. When executed via {{{runhaskell}}} or via ghci's {{{:main}}} command, it prints {{{False}}}. It would be nicer if it printed {{{True}}} in all of these cases, in particular to ease interactive development of GUI code and the like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 09:27:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 09:27:48 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.dcde4d1c47cf367bc48d661c52d7c8c7@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:33 RyanGlScott]: > Well, if people find this objectionable, I suppose we also need to review #10104, since that also resulted in a change in `Show` output. There's a big difference though: #2530 wants to fix a deliberate deviation (i.e. many people here consider `{}` binding tighter than function application to be a design-flaw) from the Haskell Report. Those additional brackets are harmless and don't harm the expectation of 'Show' resulting in an expression that parses back to the original. On the other hand, #10104 covers an area outside the Haskell Report (`-XMagicHash`) and more importantly fixes the actual problem that `show (MkT 3#)` results in `MkT 3` which can't be parsed back to the original due to a kind-error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 09:53:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 09:53:29 -0000 Subject: [GHC] #2: rewrite rules, forall, no -fglasgow-exts In-Reply-To: <045.06ea7a403df37fa1d474136f4bf6bb53@haskell.org> References: <045.06ea7a403df37fa1d474136f4bf6bb53@haskell.org> Message-ID: <060.9efca6445515e29a756b9bd78f52896b@haskell.org> #2: rewrite rules, forall, no -fglasgow-exts --------------------------------+---------------------- Reporter: nobody | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: None Resolution: Fixed | Keywords: --------------------------------+---------------------- Comment (by Sergei Trofimovich ): In [changeset:"ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3/ghc" ade1a461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3" Fix minimum alignment for StgClosure (Trac #11395) The bug is observed on m68k-linux target as crash in RTS: -- a.hs: main = print 43 $ inplace/bin/ghc-stage1 --make -debug a.hs $ ./a Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR ( p=0x805aac6e ) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (...) at rts/RtsMain.c:51 #6 0x80003c1c in main () GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e ) I've added compiler hint for static StgClosure objects to align closures at least by their natural alignment (what GHC assumes). See Note [StgWord alignment]. Signed-off-by: Sergei Trofimovich Test Plan: ran basic test on m68k qemu, it got past ASSERTs Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1974 GHC Trac Issues: #11395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 09:53:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 09:53:29 -0000 Subject: [GHC] #1: Implicit parameters cause strange behavi In-Reply-To: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> References: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> Message-ID: <060.3f3d5d2dd8a132c4ec1d565b7d2cde25@haskell.org> #1: Implicit parameters cause strange behavi -----------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.0 Resolution: Fixed | Keywords: -----------------------+-------------------- Comment (by Sergei Trofimovich ): In [changeset:"ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3/ghc" ade1a461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3" Fix minimum alignment for StgClosure (Trac #11395) The bug is observed on m68k-linux target as crash in RTS: -- a.hs: main = print 43 $ inplace/bin/ghc-stage1 --make -debug a.hs $ ./a Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR ( p=0x805aac6e ) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (...) at rts/RtsMain.c:51 #6 0x80003c1c in main () GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e ) I've added compiler hint for static StgClosure objects to align closures at least by their natural alignment (what GHC assumes). See Note [StgWord alignment]. Signed-off-by: Sergei Trofimovich Test Plan: ran basic test on m68k qemu, it got past ASSERTs Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1974 GHC Trac Issues: #11395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 09:53:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 09:53:29 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.70c77d1ec5410d9b37a98fead5d6e01b@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by Sergei Trofimovich ): In [changeset:"ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3/ghc" ade1a461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3" Fix minimum alignment for StgClosure (Trac #11395) The bug is observed on m68k-linux target as crash in RTS: -- a.hs: main = print 43 $ inplace/bin/ghc-stage1 --make -debug a.hs $ ./a Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR ( p=0x805aac6e ) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (...) at rts/RtsMain.c:51 #6 0x80003c1c in main () GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e ) I've added compiler hint for static StgClosure objects to align closures at least by their natural alignment (what GHC assumes). See Note [StgWord alignment]. Signed-off-by: Sergei Trofimovich Test Plan: ran basic test on m68k qemu, it got past ASSERTs Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1974 GHC Trac Issues: #11395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 09:53:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 09:53:30 -0000 Subject: [GHC] #4: -fext-core -fno-core behaves funny In-Reply-To: <045.ae3f8b0e845fade77535d5ec02817b6a@haskell.org> References: <045.ae3f8b0e845fade77535d5ec02817b6a@haskell.org> Message-ID: <060.6c8481f9970c45d5cf7a2265a00a2d7b@haskell.org> #4: -fext-core -fno-core behaves funny ---------------------+-------------------- Reporter: josefs | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: None Resolution: Fixed | Keywords: ---------------------+-------------------- Comment (by Sergei Trofimovich ): In [changeset:"ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3/ghc" ade1a461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3" Fix minimum alignment for StgClosure (Trac #11395) The bug is observed on m68k-linux target as crash in RTS: -- a.hs: main = print 43 $ inplace/bin/ghc-stage1 --make -debug a.hs $ ./a Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR ( p=0x805aac6e ) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (...) at rts/RtsMain.c:51 #6 0x80003c1c in main () GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e ) I've added compiler hint for static StgClosure objects to align closures at least by their natural alignment (what GHC assumes). See Note [StgWord alignment]. Signed-off-by: Sergei Trofimovich Test Plan: ran basic test on m68k qemu, it got past ASSERTs Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1974 GHC Trac Issues: #11395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 09:53:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 09:53:30 -0000 Subject: [GHC] #5: fails if library has main() In-Reply-To: <045.5aafe47c7b47732eda828244576abf66@haskell.org> References: <045.5aafe47c7b47732eda828244576abf66@haskell.org> Message-ID: <060.b5faab4fc00f6db4c5a07a7eefc7f1be@haskell.org> #5: fails if library has main() -----------------------+---------------------- Reporter: cwitty | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 5.02 Resolution: Wont Fix | Keywords: -----------------------+---------------------- Comment (by Sergei Trofimovich ): In [changeset:"ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3/ghc" ade1a461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3" Fix minimum alignment for StgClosure (Trac #11395) The bug is observed on m68k-linux target as crash in RTS: -- a.hs: main = print 43 $ inplace/bin/ghc-stage1 --make -debug a.hs $ ./a Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR ( p=0x805aac6e ) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (...) at rts/RtsMain.c:51 #6 0x80003c1c in main () GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e ) I've added compiler hint for static StgClosure objects to align closures at least by their natural alignment (what GHC assumes). See Note [StgWord alignment]. Signed-off-by: Sergei Trofimovich Test Plan: ran basic test on m68k qemu, it got past ASSERTs Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1974 GHC Trac Issues: #11395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 09:53:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 09:53:30 -0000 Subject: [GHC] #6: Debugging info confuses runtime linker In-Reply-To: <047.f0ad9cac1869b4c4c3b4613e6dbb6f53@haskell.org> References: <047.f0ad9cac1869b4c4c3b4613e6dbb6f53@haskell.org> Message-ID: <062.404ea0ed7ca77a246c8a022ccb1c0422@haskell.org> #6: Debugging info confuses runtime linker -----------------------------+--------------------- Reporter: simonmar | Owner: sewardj Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 5.02 Resolution: Fixed | Keywords: -----------------------------+--------------------- Comment (by Sergei Trofimovich ): In [changeset:"ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3/ghc" ade1a461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3" Fix minimum alignment for StgClosure (Trac #11395) The bug is observed on m68k-linux target as crash in RTS: -- a.hs: main = print 43 $ inplace/bin/ghc-stage1 --make -debug a.hs $ ./a Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR ( p=0x805aac6e ) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (...) at rts/RtsMain.c:51 #6 0x80003c1c in main () GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e ) I've added compiler hint for static StgClosure objects to align closures at least by their natural alignment (what GHC assumes). See Note [StgWord alignment]. Signed-off-by: Sergei Trofimovich Test Plan: ran basic test on m68k qemu, it got past ASSERTs Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1974 GHC Trac Issues: #11395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 09:53:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 09:53:30 -0000 Subject: [GHC] #3: DiffArray should be instance of Show In-Reply-To: <047.3d7bfcea6c6c5eaaf4a369a972367c38@haskell.org> References: <047.3d7bfcea6c6c5eaaf4a369a972367c38@haskell.org> Message-ID: <062.fd46732a9a74f77612bf904a4c159552@haskell.org> #3: DiffArray should be instance of Show --------------------------+-------------------- Reporter: magunter | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: hslibs/lang | Version: 5.0 Resolution: Fixed | Keywords: --------------------------+-------------------- Comment (by Sergei Trofimovich ): In [changeset:"ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3/ghc" ade1a461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3" Fix minimum alignment for StgClosure (Trac #11395) The bug is observed on m68k-linux target as crash in RTS: -- a.hs: main = print 43 $ inplace/bin/ghc-stage1 --make -debug a.hs $ ./a Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR ( p=0x805aac6e ) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (...) at rts/RtsMain.c:51 #6 0x80003c1c in main () GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e ) I've added compiler hint for static StgClosure objects to align closures at least by their natural alignment (what GHC assumes). See Note [StgWord alignment]. Signed-off-by: Sergei Trofimovich Test Plan: ran basic test on m68k qemu, it got past ASSERTs Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1974 GHC Trac Issues: #11395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 10:22:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 10:22:01 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.d25ab64447bbf1f497ad31125c7c2783@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 17:21:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 17:21:31 -0000 Subject: [GHC] #11683: compiled files don't load in ghci Message-ID: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org> #11683: compiled files don't load in ghci -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- compiled files don't load in ghci {{{ ghc -DYNAMIC bug.hs [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug ... bash-3.2$ ghci -ignore-dot-ghci GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help Prelude> Prelude> :load bug [1 of 1] Compiling Main ( bug.hs, interpreted ) Ok, modules loaded: Main. *Main> :show modules Main ( bug.hs, interpreted ) *Main> }}} According to the doc, file:///usr/local/share/doc/ghc-8.0.0.20160204/html/users_guide/ghci.html #loading-compiled-code, this should work: {{{ Note the -dynamic flag to GHC: GHCi uses dynamically-linked object code (if you are on a platform that supports it), and so in order to use compiled code with GHCi it must be compiled for dynamic linking. }}} Similarly https://ghc.haskell.org/trac/ghc/ticket/8736#comment:4 says the same thing: {{{ if you say :load Foo in GHCi Foo was compiled with -dynamic: loads Foo.o }}} Interestingly -fobject-code does work: {{{ ghci -ignore-dot-ghci -fobject-code GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help Prelude> :load bug [1 of 1] Compiling Main ( bug.hs, bug.o ) Ok, modules loaded: Main. Prelude Main> }}} Unfortunately when I do {{{ ghci -v -ignore-dot-ghci -fobject-code }}} I don't see why it works. It doesn't seem to use just ghc to compile , it also uses gcc, see attached file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 17:25:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 17:25:18 -0000 Subject: [GHC] #11683: compiled files don't load in ghci In-Reply-To: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org> References: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org> Message-ID: <060.7540511e8a51d41d0abb5f177eeab09b@haskell.org> #11683: compiled files don't load in ghci -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * Attachment "ghci-dashv-bug.txt" added. ghci -ignore-dot-ghci -fobject-code -v -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 17:34:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 17:34:26 -0000 Subject: [GHC] #11683: compiled files don't load in ghci In-Reply-To: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org> References: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org> Message-ID: <060.b468b7072692f595f1bb719acd216d91@haskell.org> #11683: compiled files don't load in ghci -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): `-DYNAMIC` is not the same as `-dynamic`. (`-DYNAMIC` defines the C preprocessor symbol `YNAMIC`.) Does it work for you if you run `ghc -dynamic bug.hs`? It seems to work correctly for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 17:36:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 17:36:55 -0000 Subject: [GHC] #11683: compiled files don't load in ghci In-Reply-To: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org> References: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org> Message-ID: <060.e0a63e4c6706770cf3339793a8f2e3bb@haskell.org> #11683: compiled files don't load in ghci -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by George: @@ -55,0 +55,67 @@ + {{{ + ghc --version + The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204 + bash-3.2$ ghc --info + [("Project name","The Glorious Glasgow Haskell Compilation System") + ,("GCC extra via C opts"," -fwrapv -fno-builtin") + ,("C compiler command","/usr/bin/gcc") + ,("C compiler flags"," -m64 -fno-stack-protector") + ,("C compiler link flags"," -m64") + ,("Haskell CPP command","/usr/bin/gcc") + ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token -Wno- + unicode -Wno-trigraphs") + ,("ld command","/usr/bin/ld") + ,("ld flags"," -arch x86_64") + ,("ld supports compact unwind","YES") + ,("ld supports build-id","NO") + ,("ld supports filelist","YES") + ,("ld is GNU ld","NO") + ,("ar command","/usr/bin/ar") + ,("ar flags","clqs") + ,("ar supports at file","NO") + ,("touch command","touch") + ,("dllwrap command","/bin/false") + ,("windres command","/bin/false") + ,("libtool command","libtool") + ,("perl command","/usr/bin/perl") + ,("cross compiling","NO") + ,("target os","OSDarwin") + ,("target arch","ArchX86_64") + ,("target word size","8") + ,("target has GNU nonexec stack","False") + ,("target has .ident directive","True") + ,("target has subsections via symbols","True") + ,("Unregisterised","NO") + ,("LLVM llc command","/usr/local/bin/llc-3.7") + ,("LLVM opt command","/usr/local/bin/opt-3.7") + ,("Project version","8.0.0.20160204") + ,("Project Git commit id","e2230228906a1c0fa1f86a0c1aa18d87de3cc49d") + ,("Booter version","7.10.2") + ,("Stage","2") + ,("Build platform","x86_64-apple-darwin") + ,("Host platform","x86_64-apple-darwin") + ,("Target platform","x86_64-apple-darwin") + ,("Have interpreter","YES") + ,("Object splitting supported","YES") + ,("Have native code generator","YES") + ,("Support SMP","YES") + ,("Tables next to code","YES") + ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn + thr_debug_dyn l_dyn thr_l_dyn") + ,("RTS expects libdw","NO") + ,("Support dynamic-too","YES") + ,("Support parallel --make","YES") + ,("Support reexported-modules","YES") + ,("Support thinning and renaming package flags","YES") + ,("Requires unified installed package IDs","YES") + ,("Uses package keys","YES") + ,("Uses unit IDs","YES") + ,("Dynamic by default","NO") + ,("GHC Dynamic","YES") + ,("GHC Profiled","NO") + ,("Leading underscore","YES") + ,("Debug on","False") + ,("LibDir","/usr/local/lib/ghc-8.0.0.20160204") + ,("Global Package DB","/usr/local/lib/ghc-8.0.0.20160204/package.conf.d") + ] + }}} New description: compiled files don't load in ghci {{{ ghc -DYNAMIC bug.hs [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug ... bash-3.2$ ghci -ignore-dot-ghci GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help Prelude> Prelude> :load bug [1 of 1] Compiling Main ( bug.hs, interpreted ) Ok, modules loaded: Main. *Main> :show modules Main ( bug.hs, interpreted ) *Main> }}} According to the doc, file:///usr/local/share/doc/ghc-8.0.0.20160204/html/users_guide/ghci.html #loading-compiled-code, this should work: {{{ Note the -dynamic flag to GHC: GHCi uses dynamically-linked object code (if you are on a platform that supports it), and so in order to use compiled code with GHCi it must be compiled for dynamic linking. }}} Similarly https://ghc.haskell.org/trac/ghc/ticket/8736#comment:4 says the same thing: {{{ if you say :load Foo in GHCi Foo was compiled with -dynamic: loads Foo.o }}} Interestingly -fobject-code does work: {{{ ghci -ignore-dot-ghci -fobject-code GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help Prelude> :load bug [1 of 1] Compiling Main ( bug.hs, bug.o ) Ok, modules loaded: Main. Prelude Main> }}} Unfortunately when I do {{{ ghci -v -ignore-dot-ghci -fobject-code }}} I don't see why it works. It doesn't seem to use just ghc to compile , it also uses gcc, see attached file. {{{ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204 bash-3.2$ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token -Wno- unicode -Wno-trigraphs") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","/usr/local/bin/llc-3.7") ,("LLVM opt command","/usr/local/bin/opt-3.7") ,("Project version","8.0.0.20160204") ,("Project Git commit id","e2230228906a1c0fa1f86a0c1aa18d87de3cc49d") ,("Booter version","7.10.2") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("GHC Profiled","NO") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-8.0.0.20160204") ,("Global Package DB","/usr/local/lib/ghc-8.0.0.20160204/package.conf.d") ] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 17:38:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 17:38:27 -0000 Subject: [GHC] #11683: compiled files don't load in ghci In-Reply-To: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org> References: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org> Message-ID: <060.be065e380e672a5ad17fb6830bf74471@haskell.org> #11683: compiled files don't load in ghci -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by George: @@ -48,1 +48,1 @@ - Unfortunately when I do + Unfortunately when I add -v I don't see why it works. @@ -53,2 +53,2 @@ - I don't see why it works. It doesn't seem to use just ghc to compile , it - also uses gcc, see attached file. + It doesn't seem to use just ghc to compile , it also uses gcc, see + attached file. New description: compiled files don't load in ghci {{{ ghc -DYNAMIC bug.hs [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug ... bash-3.2$ ghci -ignore-dot-ghci GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help Prelude> Prelude> :load bug [1 of 1] Compiling Main ( bug.hs, interpreted ) Ok, modules loaded: Main. *Main> :show modules Main ( bug.hs, interpreted ) *Main> }}} According to the doc, file:///usr/local/share/doc/ghc-8.0.0.20160204/html/users_guide/ghci.html #loading-compiled-code, this should work: {{{ Note the -dynamic flag to GHC: GHCi uses dynamically-linked object code (if you are on a platform that supports it), and so in order to use compiled code with GHCi it must be compiled for dynamic linking. }}} Similarly https://ghc.haskell.org/trac/ghc/ticket/8736#comment:4 says the same thing: {{{ if you say :load Foo in GHCi Foo was compiled with -dynamic: loads Foo.o }}} Interestingly -fobject-code does work: {{{ ghci -ignore-dot-ghci -fobject-code GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help Prelude> :load bug [1 of 1] Compiling Main ( bug.hs, bug.o ) Ok, modules loaded: Main. Prelude Main> }}} Unfortunately when I add -v I don't see why it works. {{{ ghci -v -ignore-dot-ghci -fobject-code }}} It doesn't seem to use just ghc to compile , it also uses gcc, see attached file. {{{ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204 bash-3.2$ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token -Wno- unicode -Wno-trigraphs") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","/usr/local/bin/llc-3.7") ,("LLVM opt command","/usr/local/bin/opt-3.7") ,("Project version","8.0.0.20160204") ,("Project Git commit id","e2230228906a1c0fa1f86a0c1aa18d87de3cc49d") ,("Booter version","7.10.2") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("GHC Profiled","NO") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-8.0.0.20160204") ,("Global Package DB","/usr/local/lib/ghc-8.0.0.20160204/package.conf.d") ] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 17:43:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 17:43:18 -0000 Subject: [GHC] #11683: compiled files don't load in ghci In-Reply-To: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org> References: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org> Message-ID: <060.585c7841999cbb5f17d2d458681e0b95@haskell.org> #11683: compiled files don't load in ghci -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Sorry! My error as you kindly pointed out Thanks, sorry for the noise Replying to [comment:1 rwbarton]: > `-DYNAMIC` is not the same as `-dynamic`. (`-DYNAMIC` defines the C preprocessor symbol `YNAMIC`.) Does it work for you if you run `ghc -dynamic bug.hs`? It seems to work correctly for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 17:43:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 17:43:58 -0000 Subject: [GHC] #11683: compiled files don't load in ghci In-Reply-To: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org> References: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org> Message-ID: <060.b2ee96839b8ccecfcb4283d6f3c1c1fd@haskell.org> #11683: compiled files don't load in ghci -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 19:53:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 19:53:46 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.a0be47e0259148c6099eda499ab7d627@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): > Thinking more about this, I came up with a small worry: having such overloaded constructors makes it very tempting to ask if it is possible to pattern match on these overloaded constructors. Interesting point! Various people have been telling me I should think about overloaded constructors, and perhaps I should have done so before now... I played around with your example a bit and came up with the following construction, which isn't the most beautiful but works in GHC 8.0 (so in particular, I've lowercased the label names): {{{#!hs {-# LANGUAGE DataKinds, FlexibleInstances, MultiParamTypeClasses, ViewPatterns, ScopedTypeVariables, KindSignatures, TypeApplications, OverloadedLabels, TypeFamilies, FunctionalDependencies #-} import GHC.TypeLits import GHC.OverloadedLabels data Statement = Provable | Refutable deriving Show class IsPattern (tag :: Symbol) a r | tag a -> r where checkPattern :: a -> Maybe r instance IsPattern tag a r => IsLabel tag (a -> Maybe r) where fromLabel _ = checkPattern @tag instance IsPattern "truish" Statement () where checkPattern Provable = Just () checkPattern Refutable = Nothing instance IsLabel "truish" Statement where fromLabel _ = Provable test :: Statement -> Int test (#truish -> Just ()) = 42 test _ = -1 x = test #truish }}} This extends to constructors with arguments, after a fashion: {{{#!hs instance IsPattern "truthiness" Statement (Int, Bool) where checkPattern Provable = Just (42, True) checkPattern Refutable = Nothing instance a ~ (Int, Bool) => IsLabel "truthiness" (a -> Statement) where fromLabel _ (42, True) = Provable fromLabel _ _ = Refutable test2 :: Statement -> Int test2 (#truthiness -> Just (k, _)) = k test2 _ = -1 y = test2 (#truthiness (42, True)) }}} A potential problem here is that the required `IsLabel` instances might conflict with "record field selector" instances. I suppose one way of dealing with that might be to desugar `#Foo` using a different class to `#foo`, but otherwise similarly. Though perhaps we should come up with a special desugaring for `#Foo` that works in patterns, as you suggest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 20:26:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 20:26:52 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.4541d7ac77db2ef2d82cd258be5c4e59@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9043 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): From IRC: erikd, I think the best bet is to just examine the Cmm, look for procs whose entry blocks are self-referential and rewrite them, inserting an auxiliary block it's a bit of a hack, but I suspect it is a fix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 22:25:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 22:25:38 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.48a1e90a5401aef41ec52fe6834c897d@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by slyfox): Filed https://github.com/vivier/qemu-m68k/issues/6 for possible qemu limitation to handle complex memory loads. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 23:27:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 23:27:31 -0000 Subject: [GHC] #10296: Segfaults when using dynamic wrappers and concurrency In-Reply-To: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> References: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> Message-ID: <061.95fe0bae3221ee0b628eafb514f8ee46@haskell.org> #10296: Segfaults when using dynamic wrappers and concurrency -------------------------------------+------------------------------------- Reporter: bitonic | Owner: jme Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jme): * owner: => jme * cc: jme (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 23:40:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 23:40:32 -0000 Subject: [GHC] #11684: Fix tests with Clang Message-ID: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Configuring GHC with `--with-gcc=clang` and then running the tests currently causes over 100 test failues. The vast majority are due to stderr differences due to Clang producing more warnings, specifically `warning: argument unused during compilation`. The obvious solution would be to filter these out in the testsuite runner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 6 23:49:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Mar 2016 23:49:16 -0000 Subject: [GHC] #11684: Fix tests with Clang In-Reply-To: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> References: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> Message-ID: <059.21789317949de9bb28882c7140d85ba8@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Apparently there is also a Clang specific `-Qunused-arguments` that disables this warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 00:39:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 00:39:47 -0000 Subject: [GHC] #11593: Template Haskell: Add a way to get names that are neither capturable nor capturing. In-Reply-To: <047.507e61696acbd5d73fd43e115fb3392c@haskell.org> References: <047.507e61696acbd5d73fd43e115fb3392c@haskell.org> Message-ID: <062.307fda74ac513b3e8e2a1197e7fa39ae@haskell.org> #11593: Template Haskell: Add a way to get names that are neither capturable nor capturing. -------------------------------------+------------------------------------- Reporter: cgibbard | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: | yhjulwwiefzojcbxybbruweejw Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * cc: mgsloan@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 00:45:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 00:45:05 -0000 Subject: [GHC] #9699: TH function to list names in scope In-Reply-To: <050.e1a7513209ad9375a0ec4688679fe797@haskell.org> References: <050.e1a7513209ad9375a0ec4688679fe797@haskell.org> Message-ID: <065.3bda990751d1d7b49709a271fa198fc1@haskell.org> #9699: TH function to list names in scope -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * cc: mgsloan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 00:46:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 00:46:08 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.8649d5e30a91af228d0437d953be2eed@haskell.org> #8406: Invalid object in isRetainer() or Segfault -----------------------------------+-------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 00:46:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 00:46:44 -0000 Subject: [GHC] #10572: Type signatures are not implicitly quantified over TH type variables In-Reply-To: <045.ba132a89df5c5be9ce7705320ad52764@haskell.org> References: <045.ba132a89df5c5be9ce7705320ad52764@haskell.org> Message-ID: <060.456e6a4bc6619afab7069dffc6da7fb7@haskell.org> #10572: Type signatures are not implicitly quantified over TH type variables -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * cc: mgsloan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 02:40:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 02:40:08 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.4a86cd4857e90f71ddec1f9581f46eaf@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): We could have `Data.Typeable.Indexed`, but then when the un-indexed version is deprecated and gone, we'll be left with an awkward module name. I think it will be straightforward enough to deprecate `Data.Typeable` and have a comment (appearing in Haddock too, of course) that `Data.Reflection` is the new module name. (The need to rename aside, I think `Data.Reflection` is superior to `Data.Typeable`.) Very sadly, `Data.Reflection` is taken, by the `reflection` package, which is in active use. `GHC.Reflection`? (Aside: is there a concrete rule separating out `GHC.` modules from `Data.` ones? And should my new `Data.Kind` really be `GHC.Kind`?) Or perhaps we start a new top-level module prefix and go with `Type.Reflection`. Maybe someday `Data.Type.Equality` and friends will lose the `Data` part, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 02:45:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 02:45:32 -0000 Subject: [GHC] #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH In-Reply-To: <042.98f1e89f02393a599dc5a3ef57e2d85f@haskell.org> References: <042.98f1e89f02393a599dc5a3ef57e2d85f@haskell.org> Message-ID: <057.f9739f79cff32a9942ee37c287c72c04@haskell.org> #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH -------------------------------------+------------------------------------- Reporter: jme | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler => Template Haskell Comment: Yes, that is quite silly. Since it seems you have poked around in the code to understand what is going on here, might you submit a patch for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 02:46:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 02:46:01 -0000 Subject: [GHC] #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH In-Reply-To: <042.98f1e89f02393a599dc5a3ef57e2d85f@haskell.org> References: <042.98f1e89f02393a599dc5a3ef57e2d85f@haskell.org> Message-ID: <057.ae10dd6ab3db7eecd07cd1548e656c44@haskell.org> #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH -------------------------------------+------------------------------------- Reporter: jme | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ideally -- if this mistake can be easily detected -- some information about how top-level splices break up a file would be helpful. This (documented) trap catches many. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 03:10:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 03:10:38 -0000 Subject: [GHC] #11679: Quasi-quoting syntax is ambiguous with list comprehensions In-Reply-To: <046.e4bc67337e38c6a1747904f615313ea3@haskell.org> References: <046.e4bc67337e38c6a1747904f615313ea3@haskell.org> Message-ID: <061.0bdca091491517342118a3b3723d1b24@haskell.org> #11679: Quasi-quoting syntax is ambiguous with list comprehensions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Instead of putting this in a ticket when there is no plan to fix the problem, shouldn't this just be added to the infelicities/stolen syntax part of the manual? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 03:13:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 03:13:56 -0000 Subject: [GHC] #11145: Template Haskell quotes of data instance GADTs is totally broken In-Reply-To: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> References: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> Message-ID: <062.3a4ed7eb11e3a4da5f22537bf9de8334@haskell.org> #11145: Template Haskell quotes of data instance GADTs is totally broken -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Thanks for checking! Now all we need is a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 03:55:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 03:55:16 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.7baccc7a708fe5d957364dc1b0e9c6c9@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:38 owst]: > Replying to [comment:37 goldfire]: > > In particular, GHC already does dependency analysis and chunking, and it would be terribly wrong not to have splicy things depend on everything else in the declaration group. > > I can't actually see that this is true for ''untyped'' splices! I was referring to [https://github.com/ghc/ghc/blob/master/compiler/rename/RnBinds.hs#L293 this], which is about dependency analysis on bindings in general, not on splices. > > Perhaps the obvious question is: is there a particular reason to run untyped splices in the renamer vs the typechecker? See [wiki:TemplateHaskell/BlogPostChanges]. Splices used to be run in the typechecker. But that caused #4364. And, sadly, I don't know a way to solve #4364 and the current ticket. The plan from comment:32 implicitly assumes that deciding that two declarations are mutually recursive is a conservative choice, and so we can do it even when we're not sure that the declarations are indeed mutually recursive. But #4364 shows us that this is not the case -- mutual recursion is ''not'' conservative for type declarations. And it isn't really for term declarations either: when declarations are mutually recursive, type generalization happens ''after'' checking the whole group, and so making more definitions think that they are mutually recursive potentially reduces that level of polymorphism (don't have an example of this intricate interaction to hand, I'm afraid). So we seem to be a bit stuck: * Properly checking for mutual recursion requires that splices be run in the renamer. * The use of `reify` as proposed here requires that splices be run in the typechecker. We clearly can't have both. (Note that running the splices twice or something silly like that doesn't solve the problem, as the `reify` calls in the first run will fail.) I'm quite loathe to introduce something like `$$$(...)` to mean an-untyped-splice-that-runs-in-the-typechecker. But I could see having a `-frun-splices-in-typechecker` flag that solves this ticket but breaks #4364; users would just choose which behavior they prefer. (Yes, yes, I know: it would be nice to control this per-splice. Perhaps that would be better.) The downside to this approach is that it means duplicating much of the infrastructure that runs the splices. How bad a burden is this? Hard to know without implementing it. One potential problem: we really can't run ''pattern'' splices during type-checking, as they bring names into scope. So they would be exempted from the new behavior, beguiling users into perpetuity. (Red herring alert: Much of [wiki:TemplateHaskell/BlogPostChanges#Toostronglytyped] talks about the need to run ''quotes'' in the renamer. Anything discussed here would not change that behavior. This is only about ''splices''.) I'm increasingly worried about the power-to-weight ratio of this proposal. Recall that "weight" has two distinct components: 1. The amount of code (both lines and complexity) that this brings, which must be maintained forever. 2. The amount of cognitive burden this feature places on users trying to understand Template Haskell, which would now have two different modes of operation, both with very subtle, hard-to-predict consequences. I'm certainly not saying "no" to the proposal. But I, personally, would need convincing before agreeing to merge. A rising chorus of voices saying "I need this feature in order to use Haskell more successfully for my business or research" tends to be quite convincing. Or perhaps I've entirely mischaracterized the problem and there is an easier way to do all this. That would make me happy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 05:03:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 05:03:35 -0000 Subject: [GHC] #11675: Monomoprhic code makes ImpredicativeTypes infer an existential type In-Reply-To: <048.f4d64f615ee9833f5ef6cf0df32ba64e@haskell.org> References: <048.f4d64f615ee9833f5ef6cf0df32ba64e@haskell.org> Message-ID: <063.0aad92d0b602a4113039e756035240b4@haskell.org> #11675: Monomoprhic code makes ImpredicativeTypes infer an existential type -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: Yes, there is an outright bug: your module includes `{-# LANGUAGE ImpredicativeTypes #-}`. GHC's behavior is according to published typing rules, such as those in my recent [http://www.seas.upenn.edu/~sweirich/papers/esop2016-typeapp.pdf paper] on the subject. The problem is that nothing encourages GHC to instantiate the expression `Nothing` in your first case branch, and so GHC doesn't. If you add a type annotation there (or a visible type application) the problem should go away. (But I can't test this at the moment -- sorry.) It is regrettable that `ImpredicativeTypes` is not conservative over Haskell98, but the extension is known to be quite broken and is hopefully getting an overhaul soon. See ImpredicativePolymorphism. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 05:11:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 05:11:29 -0000 Subject: [GHC] #11663: GHC 8.0 type assignment in arguments of lambda working without Scoped Type Variables In-Reply-To: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> References: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> Message-ID: <063.3a46e4c58a50605725ca531eb09b6269@haskell.org> #11663: GHC 8.0 type assignment in arguments of lambda working without Scoped Type Variables -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Although this smells vaguely related to my work on GHC 8, I don't actually believe it is. Is there anyone else who knows about this change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 05:14:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 05:14:10 -0000 Subject: [GHC] #11410: Quantification over unlifted type variable In-Reply-To: <047.8b584f70bae432ee9b28d295b1649fc4@haskell.org> References: <047.8b584f70bae432ee9b28d295b1649fc4@haskell.org> Message-ID: <062.3cd96617bf6da330dd27470dfb893372@haskell.org> #11410: Quantification over unlifted type variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: invalid | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: Actually, my problem with the original code is related to the problem fixed by the addition of `RuntimeRep`. So I'm going to close this ticket as invalid, as there's no real problem here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 05:19:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 05:19:14 -0000 Subject: [GHC] #11661: Missing MonadFail instance for Q monad from TemplateHaskell In-Reply-To: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> References: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> Message-ID: <064.488440e07e119967f18aa26805961609@haskell.org> #11661: Missing MonadFail instance for Q monad from TemplateHaskell -------------------------------------+------------------------------------- Reporter: PeterTrsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I use `fail` in the `Q` monad and `recover` (in singletons). They are useful. I think adding a `MonadFail` superclass is the right way to go. User- defined instances of `Quasi` are rare. And TH generally undergoes quite a bit of churn between releases, so we certainly don't need to worry about the 3-release stability policy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 05:22:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 05:22:15 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.6474f8ec575e6e50443affb606291f73@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11523 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I actually have a patch for this locally, but it's queued behind something larger. Thanks for taking a look, though! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 07:36:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 07:36:11 -0000 Subject: [GHC] #11145: Template Haskell quotes of data instance GADTs is totally broken In-Reply-To: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> References: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> Message-ID: <062.fe1084d84578faafbc0216a8f36bf371@haskell.org> #11145: Template Haskell quotes of data instance GADTs is totally broken -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollmann): * owner: => bollmann Comment: ok, I will add the regression test from above in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 08:01:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 08:01:38 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.b0bf6fd8e8a6c05939306b22e4b05187@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11523 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): Thanks, I suspected as much which was why I didn't put this on Phab. The patch was mostly to unblock testing one of my projects, and I thought I should stick it here in case it could do the same for anyone else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 08:20:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 08:20:21 -0000 Subject: [GHC] #11145: Template Haskell quotes of data instance GADTs is totally broken In-Reply-To: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> References: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> Message-ID: <062.1347e50f27914f162f556a6161d1712b@haskell.org> #11145: Template Haskell quotes of data instance GADTs is totally broken -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bollmann Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1978 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollmann): * status: new => patch * differential: => Phab:D1978 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 08:47:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 08:47:24 -0000 Subject: [GHC] #11685: undefined symbol: DataziSafeStore_zdszdfApplicativeNoLoggingTzuzdszdfMonadResourceT_closure Message-ID: <048.865d22267d4177ab8c280d1937378011@haskell.org> #11685: undefined symbol: DataziSafeStore_zdszdfApplicativeNoLoggingTzuzdszdfMonadResourceT_closure -------------------------------------+------------------------------------- Reporter: martinvlk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, when compiling a program I get this message: ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc4185_0/libghc_82.so: undefined symbol: DataziSafeStore_zdszdfApplicativeNoLoggingTzuzdszdfMonadResourceT_closure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug The same program compiled fine before, not sure what might be causing it.. happy to provide more info if you tell me what will help. Martin -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 08:51:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 08:51:20 -0000 Subject: [GHC] #11685: undefined symbol: DataziSafeStore_zdszdfApplicativeNoLoggingTzuzdszdfMonadResourceT_closure In-Reply-To: <048.865d22267d4177ab8c280d1937378011@haskell.org> References: <048.865d22267d4177ab8c280d1937378011@haskell.org> Message-ID: <063.c34729c4ad3c7611cdc5bf8abc64327a@haskell.org> #11685: undefined symbol: DataziSafeStore_zdszdfApplicativeNoLoggingTzuzdszdfMonadResourceT_closure -------------------------------------+------------------------------------- Reporter: martinvlk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by martinvlk): Here is a list of pragmas we are using in the file where it crashed: {{{#!hs {-# LANGUAGE EmptyDataDecls #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE QuasiQuotes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DeriveGeneric #-} }}} and also it's worth mentioning the code is using the DB access library "peristent". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 09:02:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 09:02:52 -0000 Subject: [GHC] #11685: undefined symbol: DataziSafeStore_zdszdfApplicativeNoLoggingTzuzdszdfMonadResourceT_closure In-Reply-To: <048.865d22267d4177ab8c280d1937378011@haskell.org> References: <048.865d22267d4177ab8c280d1937378011@haskell.org> Message-ID: <063.399202733262b6ce74472f159ec45b61@haskell.org> #11685: undefined symbol: DataziSafeStore_zdszdfApplicativeNoLoggingTzuzdszdfMonadResourceT_closure -------------------------------------+------------------------------------- Reporter: martinvlk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by martinvlk): Well, the problem went away after doing a clean build (stack clean...). So not sure it this counts as a GHC bug or not. Martin -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 09:27:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 09:27:49 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.b40c5757180a2f7c9fc5789f5687ba1b@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I quite like `Type.Reflection`. But it's not unthinkable to have a module name clash between packages, particularly if they are not widely used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 09:35:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 09:35:43 -0000 Subject: [GHC] #11663: GHC 8.0 type assignment in arguments of lambda working without Scoped Type Variables In-Reply-To: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> References: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> Message-ID: <063.e54282d23c618769a6a9958a2c0c07ec@haskell.org> #11663: GHC 8.0 type assignment in arguments of lambda working without Scoped Type Variables -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have no idea. It should really be rejected without language extensions. If someone would like to poke around and see where the missing test is, it'd be great. Can't be hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 10:38:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 10:38:58 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.05987bc1cb294f529d6fa0732f4b6603@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): There are two things going on here * Allowing uppper-case names for overloaded labels. This sounds plausible to me, although I have not thought through the consequences. * Some form of overloading for pattern matching, building on pattern synonyms. Certainly sounds interesting, but should really have its own ticket and wiki page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 10:56:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 10:56:57 -0000 Subject: [GHC] #11684: Fix tests with Clang In-Reply-To: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> References: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> Message-ID: <059.e46056cd92e1fa6442c72f4e96bdfd18@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): If I hack `aclocal.m4` to add `-Qunused-arguments` so that it end up in the `settings` file then do `./configure --with-gcc=clang` and build, the the stage0 fails building `ghc-cabal` because GCC doesn't understand `-Qunused-arguments`. @thomie should the stage0 C compiler be using the CFLAGs from the `settings` file? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 11:38:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 11:38:29 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.efe886f6e89bc6cd8bf682d42d3e2f9e@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed, I have also wondered about `Data.Kind`. I don't know of any policy on GHC's module naming, but perhaps we should consider consulting with the CLC before placing things outside of `GHC.` `Type.Reflection` sounds quite reasonable. I'll try to put together a proposal around this idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 13:39:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 13:39:58 -0000 Subject: [GHC] #11685: undefined symbol: DataziSafeStore_zdszdfApplicativeNoLoggingTzuzdszdfMonadResourceT_closure In-Reply-To: <048.865d22267d4177ab8c280d1937378011@haskell.org> References: <048.865d22267d4177ab8c280d1937378011@haskell.org> Message-ID: <063.8387e20766ebf031b4292eed4aafda2b@haskell.org> #11685: undefined symbol: DataziSafeStore_zdszdfApplicativeNoLoggingTzuzdszdfMonadResourceT_closure -------------------------------------+------------------------------------- Reporter: martinvlk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid @@ -3,0 +3,1 @@ + {{{ @@ -10,0 +11,1 @@ + }}} New description: Hi, when compiling a program I get this message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc4185_0/libghc_82.so: undefined symbol: DataziSafeStore_zdszdfApplicativeNoLoggingTzuzdszdfMonadResourceT_closure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The same program compiled fine before, not sure what might be causing it.. happy to provide more info if you tell me what will help. Martin -- Comment: It's very hard to say; without a reproducible testcase it's hard to do much about this. I'm going to close this but if you observe this sort of failure again feel free to reopen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 13:55:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 13:55:35 -0000 Subject: [GHC] #11659: configure --help incorrectly says --docdir is still unversioned by default In-Reply-To: <050.007b9aca933c6049d4b4848346195a1d@haskell.org> References: <050.007b9aca933c6049d4b4848346195a1d@haskell.org> Message-ID: <065.6f5a4a82609517347f1761de003ff01d@haskell.org> #11659: configure --help incorrectly says --docdir is still unversioned by default -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: thomie, thoughtpolice, hvr (added) * milestone: => 8.0.1 Comment: Hmm, I briefly looked into this but I couldn't find any way to override autoconf's default. Thomie, hvr, or Austin, perhaps you would know of a way to accomplish this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 16:35:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 16:35:51 -0000 Subject: [GHC] #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH In-Reply-To: <042.98f1e89f02393a599dc5a3ef57e2d85f@haskell.org> References: <042.98f1e89f02393a599dc5a3ef57e2d85f@haskell.org> Message-ID: <057.aef1b371c5f5fc728b53e5430a7c3bc7@haskell.org> #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH -------------------------------------+------------------------------------- Reporter: jme | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jme): Sure, I can submit a patch. And it shouldn't be too difficult to include TH-specific details in the error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 16:49:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 16:49:49 -0000 Subject: [GHC] #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH In-Reply-To: <042.98f1e89f02393a599dc5a3ef57e2d85f@haskell.org> References: <042.98f1e89f02393a599dc5a3ef57e2d85f@haskell.org> Message-ID: <057.f8c918962ef8b17eebce176fbceca526@haskell.org> #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH -------------------------------------+------------------------------------- Reporter: jme | Owner: jme Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jme): * owner: => jme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 17:01:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 17:01:14 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.9a2f4122510bb7fef5dc34dbb4aa3687@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): We've spoken about moving `reflection` into GHC itself, because the core of it is well typed, even if it can't be properly expressed in the surface language, and we had planned to put it in `GHC.Reflection`. (Back at ICFP in Boston a couple of years ago.) The main reason why it didn't happen at the time was that by the time Austin and I got done writing `Proxy#` the conference was over. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 17:33:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 17:33:59 -0000 Subject: [GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.27329eb2661b8e1f59e3023ca38a1c9c@haskell.org> #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 20:16:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 20:16:17 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.d3f3612c21de484fa2175ab034ca8e01@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Replying to [comment:39 goldfire]: > I was referring to [https://github.com/ghc/ghc/blob/master/compiler/rename/RnBinds.hs#L293 this], which is about dependency analysis on bindings in general, not on splices. Aha! Incidentally, the line linked is never reached for the failing testcase in the original report, since the line above it is where the splice is renamed, and the `reify` call fails. > See [wiki:TemplateHaskell/BlogPostChanges]. Splices used to be run in the typechecker. But that caused #4364. And, sadly, I don't know a way to solve #4364 and the current ticket. The plan from comment:32 implicitly assumes that deciding that two declarations are mutually recursive is a conservative choice, and so we can do it even when we're not sure that the declarations are indeed mutually recursive. But #4364 shows us that this is not the case -- mutual recursion is ''not'' conservative for type declarations. And it isn't really for term declarations either: when declarations are mutually recursive, type generalization happens ''after'' checking the whole group, and so making more definitions think that they are mutually recursive potentially reduces that level of polymorphism (don't have an example of this intricate interaction to hand, I'm afraid). Ah yes, a very good reason to move running of splices to the renamer. Thanks for pointing out the relevant ticket! > So we seem to be a bit stuck: > > [...] I'm increasingly worried about the power-to-weight ratio of this proposal. > I agree, you're absolutely right about the power-to-weight ratio; bother! :-) Oh well, I've tweaked the manual so hopefully there might be a little less confusion about what's going on in this situation (and indeed, a pointer towards the `$(return [])` workaround). I'll try and move onto the next small ticket! Thanks for the discussion on this one, goldfire! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 20:47:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 20:47:28 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.d3d4316a0653787c3a537ec4e3e69c77@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Oh, should we (I, if I can?) close this ticket, if we're not going to pursue it further development-wise, and the documentation change has been merged? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 21:54:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 21:54:17 -0000 Subject: [GHC] #11643: Core lint error in simplifier when compiling Rules1 with -O -dcore-lint In-Reply-To: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> References: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> Message-ID: <060.34c3ebc62340b5ff1fa6eed65caa99ab@haskell.org> #11643: Core lint error in simplifier when compiling Rules1 with -O -dcore-lint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/Rules1 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"13a801af10289e0931532f7df4a6814b058389f3/ghc" 13a801af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="13a801af10289e0931532f7df4a6814b058389f3" Revert "Mark tests for #11643, #11644, #11645 and #9406 expect_broken" This reverts commit 90fa8cf2bf1677545c3f4a8bc967b1674822e90a. As noted in #11643, these should be fixed. Updates hpc submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 21:54:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 21:54:17 -0000 Subject: [GHC] #11645: Heap profiling - hp2ps: samples out of sequence In-Reply-To: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> References: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> Message-ID: <060.a3f741d018bd8d22eea32b2908732b5f@haskell.org> #11645: Heap profiling - hp2ps: samples out of sequence -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/hpc/tests/fork/hpc_fork Blocked By: | Blocking: Related Tickets: #664 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"13a801af10289e0931532f7df4a6814b058389f3/ghc" 13a801af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="13a801af10289e0931532f7df4a6814b058389f3" Revert "Mark tests for #11643, #11644, #11645 and #9406 expect_broken" This reverts commit 90fa8cf2bf1677545c3f4a8bc967b1674822e90a. As noted in #11643, these should be fixed. Updates hpc submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 21:54:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 21:54:17 -0000 Subject: [GHC] #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm In-Reply-To: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> References: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> Message-ID: <060.e1bbf9bf3a2230d59d296e7172b70828@haskell.org> #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T3220, | indexed- | types/should_compile/ColInference3 Blocked By: | Blocking: Related Tickets: #11371, #11643 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"13a801af10289e0931532f7df4a6814b058389f3/ghc" 13a801af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="13a801af10289e0931532f7df4a6814b058389f3" Revert "Mark tests for #11643, #11644, #11645 and #9406 expect_broken" This reverts commit 90fa8cf2bf1677545c3f4a8bc967b1674822e90a. As noted in #11643, these should be fixed. Updates hpc submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 21:54:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 21:54:17 -0000 Subject: [GHC] #9406: unexpected failure for T7837(profasm) In-Reply-To: <042.6cf0b0817037f8cfba5de5652e277f8a@haskell.org> References: <042.6cf0b0817037f8cfba5de5652e277f8a@haskell.org> Message-ID: <057.3d61a76a01699c44125ce3c737a5989d@haskell.org> #9406: unexpected failure for T7837(profasm) -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: | Keywords: T7837 Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: T7837 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"13a801af10289e0931532f7df4a6814b058389f3/ghc" 13a801af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="13a801af10289e0931532f7df4a6814b058389f3" Revert "Mark tests for #11643, #11644, #11645 and #9406 expect_broken" This reverts commit 90fa8cf2bf1677545c3f4a8bc967b1674822e90a. As noted in #11643, these should be fixed. Updates hpc submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 21:57:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 21:57:48 -0000 Subject: [GHC] #11643: Core lint error in simplifier when compiling Rules1 with -O -dcore-lint In-Reply-To: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> References: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> Message-ID: <060.7949d667e59eea9507b5e880b6faa8bd@haskell.org> #11643: Core lint error in simplifier when compiling Rules1 with -O -dcore-lint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/Rules1 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Indeed these are fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 23:18:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 23:18:42 -0000 Subject: [GHC] #11686: implicit call stacks should provide a way to get the calling function's name Message-ID: <047.a2277be9d1e1be7f13fd63d4fd15a5f6@haskell.org> #11686: implicit call stacks should provide a way to get the calling function's name -------------------------------------+------------------------------------- Reporter: elaforge | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With implicit call stacks we can get the calling SrcPos and the called function's name, but not the caller function's name. E.g.: {{{#!hs {-# LANGUAGE ImplicitParams, ConstraintKinds #-} import qualified GHC.Stack as Stack caller :: IO () caller = callee 10 where callee :: (?stack :: Stack.CallStack) => Int -> IO () callee _n = mapM_ print (Stack.getCallStack ?stack) }}} Gives {{{ ("?stack",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "T.hs", srcLocStartLine = 9, srcLocStartCol = 36, srcLocEndLine = 9, srcLocEndCol = 42}) ("callee",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "T.hs", srcLocStartLine = 6, srcLocStartCol = 23, srcLocEndLine = 6, srcLocEndCol = 29}) }}} It would be nice to get the name "caller" as well. It's too bad getCallStack returns pairs instead of an abstract type like Frame. Perhaps a separate Stack.getFrames could do that while getCallStack continues to return pairs for compatibility. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 7 23:24:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Mar 2016 23:24:54 -0000 Subject: [GHC] #11686: implicit call stacks should provide a way to get the calling function's name In-Reply-To: <047.a2277be9d1e1be7f13fd63d4fd15a5f6@haskell.org> References: <047.a2277be9d1e1be7f13fd63d4fd15a5f6@haskell.org> Message-ID: <062.08391699a8ff1464bfa428b934c625ba@haskell.org> #11686: implicit call stacks should provide a way to get the calling function's name -------------------------------------+------------------------------------- Reporter: elaforge | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: gridaphobe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 00:44:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 00:44:02 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.de704b0a61dc075b0252a5cd59ddf239@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by inaki): Replying to [comment:9 adamgundry]: > I played around with your example a bit and came up with the following construction, which isn't the most beautiful but works in GHC 8.0 (so in particular, I've lowercased the label names): Clever :) Replying to [comment:10 simonpj]: > There are two things going on here > > * Allowing uppper-case names for overloaded labels. This sounds plausible to me, although I have not thought through the consequences. > > * Some form of overloading for pattern matching, building on pattern synonyms. Certainly sounds interesting, but should really have its own ticket and wiki page. Indeed! I thought it may be an straightforward feature request, but now I am not sure. Honestly, the realization that they cannot be (straightforwardly) pattern matched against removes quite a bit of my original motivation (detailed in comment:2) for asking this. So the fact that they are not really patterns may make it a good thing that they cannot start by uppercase, so one is not tempted to match against them. In any case I can certainly file a new ticket with the feature request for "OverloadedPatterns", if you think that's useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 02:47:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 02:47:45 -0000 Subject: [GHC] #11686: implicit call stacks should provide a way to get the calling function's name In-Reply-To: <047.a2277be9d1e1be7f13fd63d4fd15a5f6@haskell.org> References: <047.a2277be9d1e1be7f13fd63d4fd15a5f6@haskell.org> Message-ID: <062.fe6191b8de4fa12ccb1143bf464e98b5@haskell.org> #11686: implicit call stacks should provide a way to get the calling function's name -------------------------------------+------------------------------------- Reporter: elaforge | Owner: gridaphobe Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * owner: => gridaphobe * milestone: => 8.2.1 Comment: Thanks for the report. I like the suggestion to return an abstract Frame type. I'm not sure I'll have time to work on this before 8.0 is released, so I'm tentatively setting it for 8.2. The main issue will probably be that adding the caller strings will exacerbate #10844, so I should finish addressing that ticket first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 03:26:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 03:26:30 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.6582c6075b7344a538ba2055d9cc4158@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): In case it wasn't clear, until I wrote comment:39, I thought this was all quite feasible and a nice plan. I just don't want you to think I led you down a garden path into a trap! But falling into traps is just part of software development, I suppose. I'm grateful for your time and good attitude as this proposal has become pear-shaped. There's one important thing to do before closing the ticket: record our discoveries somewhere. In particular, I think a Note in the code is in order about why things are the way they are. Might you find a good spot, summarizing our discoveries and linking to this ticket? It might also be worth putting a link to this ticket in the manual, in case an overinterested soul wanders by. You say you've updated the manual. Where? How? Are you a committer? Or is there a Phab patch? (Apologies if the answer to this is obvious. It's even possible I have reviewed your changes and applied them myself! I tend to be rather aggressive in deleting stale records in my brain of tasks having been accomplished. This habit may sometimes make me appear somewhat dense. Sorry!) Once all that's done, we (you should be able to) should close this as wontfix. Thanks again for your efforts here, and I'm sorry that they didn't lead to fruition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 05:34:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 05:34:33 -0000 Subject: [GHC] #11687: GHC reports unimplemented/strange closure type 5937 in the ARM platform Message-ID: <046.132b2bfeb7d9730f653c87d886b5930b@haskell.org> #11687: GHC reports unimplemented/strange closure type 5937 in the ARM platform --------------------------------+---------------------------------- Reporter: highfly | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------- angie: internal error: scavenge: unimplemented/strange closure type 5937 @ 0x74c01a60 (GHC version 7.10.3 for arm_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 Tue Mar 8 07:58:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 07:58:39 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing Message-ID: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tyson Whitehead gives a detailed description of the problem [https://github.com/haskell/bytestring/issues/70 here]. Key points: - Program fails to rewrite {{{ ByteString.break (== x) chunk }}} to {{{ ByteString.breakByte x chunk }}} - Missed unboxing opportunity (which led to 34gb additional allocations, which is why he noticed it) I could reproduce the problem on OSX and Windows with GHC 7.10.3. Haven't tested Linux. I repost it here to make sure it doesn't go unnoticed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 07:59:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 07:59:29 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.8aa26bf179fd43083d7a858cfaf7a53a@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alexbiehl): * Attachment "tywhitehead_rewrite.hs" added. Test program from Tywhitedheads bug report -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 08:01:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 08:01:06 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.d013dd5c84258f7743b47c4be9ddcd45@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by alexbiehl: @@ -10,1 +10,1 @@ - I could reproduce the problem on OSX and Windows with GHC 7.10.3. Haven't + I can reproduce the problem on OSX and Windows with GHC 7.10.3. Haven't New description: Tyson Whitehead gives a detailed description of the problem [https://github.com/haskell/bytestring/issues/70 here]. Key points: - Program fails to rewrite {{{ ByteString.break (== x) chunk }}} to {{{ ByteString.breakByte x chunk }}} - Missed unboxing opportunity (which led to 34gb additional allocations, which is why he noticed it) I can reproduce the problem on OSX and Windows with GHC 7.10.3. Haven't tested Linux. I repost it here to make sure it doesn't go unnoticed. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 08:12:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 08:12:55 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.b105aac99c4869a50e9cc933553872ab@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by Sergei Trofimovich ): In [changeset:"90e1e160b783644c2d3cc0a05e3a804cea549cf9/ghc" 90e1e160/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90e1e160b783644c2d3cc0a05e3a804cea549cf9" Split external symbol prototypes (EF_) (Trac #11395) Before the patch both Cmm and C symbols were declared with 'EF_' macro: #define EF_(f) extern StgFunPtr f() but for Cmm symbols we know exact prototypes. The patch splits there prototypes in to: #define EFF_(f) void f() /* See Note [External function prototypes] */ #define EF_(f) StgFunPtr f(void) Cmm functions are 'EF_' (External Functions), C functions are 'EFF_' (External Foreign Functions). While at it changed external C function prototype to return 'void' to workaround ghc bug on m68k. Described in detail in Trac #11395. This makes simple tests work on m68k-linux target! Thanks to Michael Karcher for awesome analysis happening in Trac #11395. Signed-off-by: Sergei Trofimovich Test Plan: ran "hello world" on m68k successfully Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1975 GHC Trac Issues: #11395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 08:13:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 08:13:15 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.6c66df4800032f5a6fb1c89a75611322@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alexbiehl): * Attachment "11688_smaller_testcase.hs" added. Smaller testcase which failes to rewrite break and failes to unbox result of findIndexOrEnd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 08:15:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 08:15:51 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.125c9e59e0195d2ad7707169375054b2@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): (Compile both example with {{{ -ddump-simpl -O2 -ddump-simpl -dsuppress- all -dno-suppress-idinfo }}}) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 08:20:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 08:20:55 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.3786ed057585cc53c20f66be5c1b2fe8@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by slyfox): The problem in comment:#21 was in ASL/LSL implementation: https://github.com/vivier/qemu-m68k/pull/7 should fix it (lightly tested) With Phab:D1975 applied ghc-stage2 still SIGSEGs. Current run of regression tests fails the following ~200 tests: {{{ $ make fasttest TEST_HC=$(pwd)/inplace/bin/ghc-stage1 THREADS=12 # testsuite/mk/ghcconfig_*.mk needs a fix in WORDSIZE, GHCI support }}} TEST="T7962 T9905fail3 T9905fail2 T9905fail1 ghc-e-fail2 ghc-e-fail1 annfail09 annfail03 T7859 cabal08 T1372 T5681 T8131b T7571 T9576 cabal09 cabal01 cabal03 cabal04 cabal05 cabal06 rnfail043 T3333 ghcilink001 ghcilink002 ghcilink003 ghcilink004 ghcilink005 ghcilink006 GShow1 T9045 linker_unload stack001 stack003 T5435_v_gcc bug1010 T5435_v_asm T9839_01 T10017 testmblockalloc T8124 T5250 T9329 T11103 overloadedrecfldsfail09 SafeLang16 SafeLang12 SafeLang01 T8628 T6145 T8639_api T10508_api literals parsed RAE_T32a T11195 T11303b T11303 T11276 T11374 UnsafeInfered02 UnsafeWarn02 UnsafeInfered12 T5550 T7702 T5321FD T5030 T4801 T5631 T5837 T9872a T5642 T9872b T3064 parsing001 T9872d T9872c T1969 T5321Fun T783 T9233 T9961 recomp009 ImpSafeOnly08 safePkg01 ImpSafeOnly02 ImpSafeOnly03 ImpSafeOnly01 ImpSafeOnly06 ImpSafeOnly07 ImpSafeOnly04 ImpSafeOnly05 ImpSafeOnly09 ImpSafeOnly10 T10052 prog001 T7022 T9160 AtomicPrimops tryReadMVar2 conc006 overloadedrecfldsrun04 overloadedlabelsrun04 T680 T5314 T949 prof-doc-last heapprof001 T3001-2 scc003 T10826 dynCompileExpr bug1465 ExtraConstraintsWildcardInPatternSplice NamedWildcardInTypeSplice posix004 ghci004 ghci006 landmines dynHelloWorld T9360a T9360b T5313 T7478 Conversions T3586 T5549 T7954 T5237 T3245 T4321 T7850 T9203 T10359 MethSharing integerGmpInternals dataToExpQUnit T3007 T1679 ffi014 TH_spliceViewPat T1407 load_short_name T6016 qsem001 hTell002 showDouble qsemn001 T4006 memo002 dynamic003 unicode002 stableptr003 stableptr004 T7600 cgrun058 cgrun074 cgrun026 encoding004 T3307 openTempFile001 environment001 T4855 num008 T11430 T10269 T10268 exampleTest T11321 comments T10396 listcomps T10307 T10399 bundle-export T10357 T10354 T10358 annotations T10255 T10276 T10278 T11018 T10313 T10312 T11332 parseTree T10309 T10280 boolFormula apirecomp001 numrun014 T8726 arith001 arith012 arith005 KindEqualities2 RAE_T32b Rae31 T876 T4830 T7257 lazy-bs-alloc" Many of them are not real problems (like missing TH annotation around tests, perf failures) but some are real failures. Investigating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 09:02:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 09:02:30 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.71ef2f8261bf33f0a782b03bd8806c69@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jplatte): * cc: jplatte (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 09:05:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 09:05:42 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.4a6a36be31396dc4a5b735c158b3369b@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Replying to [comment:42 goldfire]: > In case it wasn't clear, until I wrote comment:39, I thought this was all quite feasible and a nice plan. I just don't want you to think I led you down a garden path into a trap! But falling into traps is just part of software development, I suppose. I'm grateful for your time and good attitude as this proposal has become pear-shaped. Indeed so that hidden traps are part of software development - thanks for helping me down (what appeared to be) a sensible path! > There's one important thing to do before closing the ticket: record our discoveries somewhere. In particular, I think a Note in the code is in order about why things are the way they are. Might you find a good spot, summarizing our discoveries and linking to this ticket? It might also be worth putting a link to this ticket in the manual, in case an overinterested soul wanders by. Good idea, I'll try and do that this evening. > You say you've updated the manual. Where? How? Are you a committer? Or is there a Phab patch? Yes, there's a Phab patch - see https://phabricator.haskell.org/D1899 - I 'think' I don't need to do anything further with that patch, correct? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 09:37:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 09:37:42 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.c3b9ee993dac0b5394e13a63c0638434@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * related: #9939, #9973, #10100, #10183 => #9939, #9973, #10100, #10183, #11370 Comment: For the record, in comment:ticket:11370:32 it was decided to have `-Wredundant-constraint` included in `-Wall` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 10:02:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 10:02:31 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.fa76d81f1a429fecaabbb3e8e0b17f53@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I briefly looked at this; I left a comment on the `bytestring` ticket which I'll reproduce here, > I suspect the issue here is that `(==)` is being inlined too early, hiding the rule fire opportunity. By contrast, if you give `(==)` another name with a later inline pragma the `break -> breakByte` rule fires as expected. > > {{{#!hs > main = do > chunk <- DB.hGetSome stdin 32768 > let newline = c2w '\n' > let (prefix,suffix) = DB.break (eq newline) chunk > DB.hPut stdout prefix > DB.hPut stdout suffix > > eq :: Eq a => a -> a -> Bool > eq = (==) > {-# INLINE [1] eq #-} > > {-# RULES > "ByteString specialise break (eq x)" forall x. > DB.break (eq x) = DB.breakByte x > #-} > }}} > > Actually, even if one doesn't specify an explicit phase on `eq` the rule still fires! This is likely accidental, since GHC just happens to look at the `breakByte` rule before the `eq` inlining. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 10:51:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 10:51:37 -0000 Subject: [GHC] #11687: GHC reports unimplemented/strange closure type 5937 in the ARM platform In-Reply-To: <046.132b2bfeb7d9730f653c87d886b5930b@haskell.org> References: <046.132b2bfeb7d9730f653c87d886b5930b@haskell.org> Message-ID: <061.4041f59c572e9d01384e50e310c4888f@haskell.org> #11687: GHC reports unimplemented/strange closure type 5937 in the ARM platform ----------------------------------+---------------------------------- Reporter: highfly | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Changes (by bgamari): * status: new => infoneeded * milestone: => 8.0.1 @@ -0,0 +1,1 @@ + {{{ @@ -6,0 +7,1 @@ + }}} New description: {{{ angie: internal error: scavenge: unimplemented/strange closure type 5937 @ 0x74c01a60 (GHC version 7.10.3 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Comment: I believe this is likely fixed in GHC 8.0.1. Could you try one of the [[http://downloads.haskell.org/~ghc/8.0.1-rc1/ghc-8.0.0.20160111-arm- unknown-linux.tar.xz|release candidates]] or [[http://home.smart- cactus.org/~ben/ghc/nightlies/arm/20160225/|nightlies]]? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 10:54:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 10:54:02 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.2203f32200f5e26ca13bafb99f707ea0@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * failure: None/Unknown => Runtime performance bug * differential: => Phab:D1980 Comment: Phab:D1980 is a proposed fix. I believe it should be safe to defer inlining `Eq` and `Ord`, but this needs confirmation. I'm really not sure whether we want to risk pushing this to 8.0, even if we do conclude that it's the right way forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 11:21:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 11:21:46 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.38f44f7c34c94ac8f632b0e8c3025f06@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh dear, Phab:D1980 actually won't work at all; the problem isn't the inlining of the class methods themselves, it is the class op rule generated by GHC. Namely, {{{ Rule fired Rule: Class op == Before: GHC.Classes.== TyArg GHC.Word.Word8 ValArg GHC.Word.$fEqWord8 ValArg ds_d2p3 ValArg ds_d2p4 After: GHC.Word.$fEqWord8_$c== Cont: Stop[BoringCtxt] GHC.Types.Bool }}} This will require further pondering. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 11:21:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 11:21:58 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.c778a70180474b9e91ee385dc4eb8966@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 11:39:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 11:39:05 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.e4db0ab7cf37de5c1590f8ba13402de8@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I would be fine with retaining the old behavior, keeping the parens, for now. It's pretty widely believed that the binding of record syntax specified in the report was a mistake. Let's allow the Haskell Prime committee to discuss this matter before we commit to changing `Show`. While it's almost certainly not practical to change the binding of record syntax, the next report could specify a more lax semantics for `Show`. To be clear, I'm merely requesting that the committee add this matter to their list of matters to address; their final decision is of course in their hands. If there is a good chance that the committee will consider such a change, then let's revert the commit in comment:25 for now and reconsider after the committee has made their decision. If it's unlikely that the next report will loosen `Show`, then we should decide now whether we want retain and document the old behavior as an infelicity of GHC's implementation, or whether we want to come into compliance with the Report. I'm slightly leaning towards the former for the sake of stability, although I'm happy to hear arguments in the other direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 11:49:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 11:49:16 -0000 Subject: [GHC] #6032: HEAD (7.5.20120421) requires RankNTypes for a rank-2 type In-Reply-To: <046.8760c43a0784b143c63536ebaecc6692@haskell.org> References: <046.8760c43a0784b143c63536ebaecc6692@haskell.org> Message-ID: <061.6b9a9f6aacd1482bf2f6b2aa7657a3cd@haskell.org> #6032: HEAD (7.5.20120421) requires RankNTypes for a rank-2 type -------------------------------------+--------------------------------- Reporter: dreixel | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"1a9734a69260e69943c00755952edd7185dcc484/ghc" 1a9734a6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1a9734a69260e69943c00755952edd7185dcc484" template-haskell: Drop use of Rank2Types/PolymorphicComponents As per #6032, `Rank2Types` and `PolymorphicComponents` have been deprecated in favour of `RankNTypes`. also update `other-extensions` in template-haskell.cabal flag to reflect reality. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 11:57:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 11:57:17 -0000 Subject: [GHC] #11679: Quasi-quoting syntax is ambiguous with list comprehensions In-Reply-To: <046.e4bc67337e38c6a1747904f615313ea3@haskell.org> References: <046.e4bc67337e38c6a1747904f615313ea3@haskell.org> Message-ID: <061.efd1cf5e72506c3524dff5ff4890899b@haskell.org> #11679: Quasi-quoting syntax is ambiguous with list comprehensions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1981 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1981 Comment: I've opened Phab:D1981 documenting this issue in the users guide. I'm not pleased with this situation, but I don't see any good fix at this point. Consequently I'll close this ticket as wontfix once the documentation is merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 12:01:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 12:01:33 -0000 Subject: [GHC] #11661: Missing MonadFail instance for Q monad from TemplateHaskell In-Reply-To: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> References: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> Message-ID: <064.7b5b20ce7b6b788a9868e11e020753ec@haskell.org> #11661: Missing MonadFail instance for Q monad from TemplateHaskell -------------------------------------+------------------------------------- Reporter: PeterTrsko | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D1982 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => phab:D1982 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 12:22:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 12:22:00 -0000 Subject: [GHC] #11659: configure --help incorrectly says --docdir is still unversioned by default In-Reply-To: <050.007b9aca933c6049d4b4848346195a1d@haskell.org> References: <050.007b9aca933c6049d4b4848346195a1d@haskell.org> Message-ID: <065.ba2617824aa2af8c26a718a83a4eb6cd@haskell.org> #11659: configure --help incorrectly says --docdir is still unversioned by default -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1983 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1983 Comment: Here's a proposed fix in Phab:D1983. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 14:16:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 14:16:09 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.268ae48378a0047923b0c3255c601c62@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This comes up regularly; e.g. #10595, #7141 (maybe), #5973 (maybe), #4397 (I bet the fix is delicate), #2271, #1434. And #10418 is similar but for constructors not class ops. In general, I it's dangerous to match on an overloaded class op. After all, did you really mean to match on `(==)` at every type? I doubt it? In this case we mean `==` at type `Char`. So the advice in comment:4 of #10595, is to write {{{ instance Eq Char where (==) = eqChar eqChar :: Char -> Char -> Bool {-# INLINE [0] eqChar #-} -- Delay inlining }}} and then make the rule be {{{ {-# RULES "bsbreak" forall x chunk. ByteString.break (eqChar x) chunk = ... #-} }}} This is simple and robust. But it does mean chaging the base library to use named functions for instance methods. Probably good practice anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 14:41:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 14:41:15 -0000 Subject: [GHC] #11645: Heap profiling - hp2ps: samples out of sequence In-Reply-To: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> References: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> Message-ID: <060.85c590a3ff2dc3e5203e0dadf7de7f61@haskell.org> #11645: Heap profiling - hp2ps: samples out of sequence -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/hpc/tests/fork/hpc_fork Blocked By: | Blocking: Related Tickets: #664 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jme): The problem is that the profiler doesn't work with `forkProcess` (''e.g.'', see #8862). In this particular case, the issue is that the elapsed ''per-process'' time is being reported for each sample. Since the parent spends more time performing the forks than each child does executing `threadDelay`, its elapsed time is the largest. But the parent outputs its sample before either child, and so the samples appear out of order. The reason this behavior does not cause a problem when using 7.10.3 is that the sample times used to only be reported in hundredths of a second (and so were all 0.00). As of 1da3bbd2bd82ea11f8a1d760385df84708bbea63, they are being reported with full precision. One possible way to work around this is to simply increase the `threadDelay` intervals for each child (400000 for the first and 800000 for the second worked for me). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 14:42:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 14:42:20 -0000 Subject: [GHC] #11679: Quasi-quoting syntax is ambiguous with list comprehensions In-Reply-To: <046.e4bc67337e38c6a1747904f615313ea3@haskell.org> References: <046.e4bc67337e38c6a1747904f615313ea3@haskell.org> Message-ID: <061.4298d313aa8e6d444b6c2e2c06c2222c@haskell.org> #11679: Quasi-quoting syntax is ambiguous with list comprehensions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here's an example (due to hvr) which will compile with and without `-XQuasiQuotes` but will produce different results, {{{#!hs import Text.Heredoc (here) x :: String x = [here| here <- ['h','e','r','e']] -- |] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 14:46:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 14:46:07 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.24cd970a03c07849991311e83a4739f4@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, we should make sure this wisdom ends up in the users guide somewhere (and maybe even the Haddocks of `GHC.Classes`; I was wondering what purpose `eqInt` served). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 15:07:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 15:07:31 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.61bcc7d61a67b89b3a558cbfb8cfd6e0@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, we should! Also can you make the base-lib changes; and check that with the right RULE the original bug in `bytestring` is fixed? And then tell the `bytestring` devs. Incidentally, doesn't the rule elicit a warning? It should! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 15:23:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 15:23:05 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.0ffb5559f67c0095efbd2d345a94acd7@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Comment: Here's a new patch which makes the `base` changes (although only for `Eq`; perhaps we should give the same treatment to `Ord` as well?) and adds some documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 15:47:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 15:47:58 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.cefb7c7257ab20b95fa91eac003874d3@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See also #10528, esp comment:13, which explains why rewriting the LHS of a rule is not so cool. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 15:54:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 15:54:25 -0000 Subject: [GHC] #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm In-Reply-To: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> References: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> Message-ID: <060.60273b9352c112a3b70d948b2eb436ec@haskell.org> #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T3220, | indexed- | types/should_compile/ColInference3 Blocked By: | Blocking: Related Tickets: #11371, #11643 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): See #11643 for fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 16:08:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 16:08:02 -0000 Subject: [GHC] #11679: Quasi-quoting syntax is ambiguous with list comprehensions In-Reply-To: <046.e4bc67337e38c6a1747904f615313ea3@haskell.org> References: <046.e4bc67337e38c6a1747904f615313ea3@haskell.org> Message-ID: <061.336d310e5d327beb53c4bb97a72e28bc@haskell.org> #11679: Quasi-quoting syntax is ambiguous with list comprehensions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): [http://mashable.com/wp-content/uploads/2013/07/crying-waterfalls.gif :(] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 16:26:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 16:26:43 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.610bd21486731eebfa6d1255bedd10f3@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): No, according to the Phab diff, that patch has been committed. Thanks. Just post a new Diff for the remaining changes when you're ready and link to it from here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 16:28:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 16:28:18 -0000 Subject: [GHC] #11661: Missing MonadFail instance for Q monad from TemplateHaskell In-Reply-To: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> References: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> Message-ID: <064.cc0a48ea2471e4ebdb96a29f9b921272@haskell.org> #11661: Missing MonadFail instance for Q monad from TemplateHaskell -------------------------------------+------------------------------------- Reporter: PeterTrsko | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D1982 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"1c76e1686bd4291556ae9357151f256c805b4b5d/ghc" 1c76e16/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1c76e1686bd4291556ae9357151f256c805b4b5d" template-haskell: define `MonadFail Q` instance When `MonadFail`is available, this patch makes `MonadFail` a superclass of `Quasi`, and `Q` an instance of `MonadFail`. NB: Since f16ddcee0c64a92ab911a7841a8cf64e3ac671fd, we need to be able to compile `template-haskell` with stage0 compilers that don't provide a `MonadFail` class yet. Once we reach GHC 8.3 development we can drop the CPP conditionals again. Addresses #11661 Reviewed By: bgamari, goldfire Differential Revision: https://phabricator.haskell.org/D1982 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 17:31:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 17:31:55 -0000 Subject: [GHC] #11661: Missing MonadFail instance for Q monad from TemplateHaskell In-Reply-To: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> References: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> Message-ID: <064.befc83ee41b9b477d6f5046df9ea2627@haskell.org> #11661: Missing MonadFail instance for Q monad from TemplateHaskell -------------------------------------+------------------------------------- Reporter: PeterTrsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D1982 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` via 35b747fcde36bdc96e533bd1c3f02d81845453c2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 17:58:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 17:58:08 -0000 Subject: [GHC] #11689: typo (extra s) in error message (out-of-scope typess) Message-ID: <049.f38414deaa576c423d3294d4306ce447@haskell.org> #11689: typo (extra s) in error message (out-of-scope typess) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ MB.hs:92:49: error: ? Ambiguous type variable ... These potential instances exist: ... ...plus 325 instance involving out-of-scope typess }}} There is an extra 's' in 'typess'. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 19:34:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 19:34:24 -0000 Subject: [GHC] #11689: typo (extra s) in error message (out-of-scope typess) In-Reply-To: <049.f38414deaa576c423d3294d4306ce447@haskell.org> References: <049.f38414deaa576c423d3294d4306ce447@haskell.org> Message-ID: <064.96e0418457af3d0673ce6466d6bb2ebc@haskell.org> #11689: typo (extra s) in error message (out-of-scope typess) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * failure: None/Unknown => Incorrect warning at compile-time * resolution: => fixed * milestone: => 8.0.1 Comment: This was fixed in c8702e3092250b89f60ad3fe7c71c627e5f388f6 which will be present in the next rc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 20:13:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 20:13:48 -0000 Subject: [GHC] #11689: typo (extra s) in error message (out-of-scope typess) In-Reply-To: <049.f38414deaa576c423d3294d4306ce447@haskell.org> References: <049.f38414deaa576c423d3294d4306ce447@haskell.org> Message-ID: <064.67d92cef3ef116fdec647ccbda5ef819@haskell.org> #11689: typo (extra s) in error message (out-of-scope typess) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): Oh, sorry. Before reporting, I did try this search: https://ghc.haskell.org/trac/ghc/search?q=typess and it did not show a report specific for this bug. It does show #11616 which contains another instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 20:53:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 20:53:08 -0000 Subject: [GHC] #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH In-Reply-To: <042.98f1e89f02393a599dc5a3ef57e2d85f@haskell.org> References: <042.98f1e89f02393a599dc5a3ef57e2d85f@haskell.org> Message-ID: <057.a0b490b4dd548ae788f8bfa2789d68bd@haskell.org> #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH -------------------------------------+------------------------------------- Reporter: jme | Owner: jme Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yay! Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 22:29:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 22:29:12 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.74e4bb499a30deb754bd61755a9a1b0c@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Replying to [comment:44 goldfire]: > No, according to the Phab diff, that patch has been committed. Thanks. Just post a new Diff for the remaining changes when you're ready and link to it from here. Done - https://phabricator.haskell.org/D1985 - please let me know what you think! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 8 23:37:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Mar 2016 23:37:44 -0000 Subject: [GHC] #11684: Fix tests with Clang In-Reply-To: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> References: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> Message-ID: <059.affe903a50a4c489a2efb5e4a613d18d@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): My change modifies `FPTOOLS_SET_C_LD_FLAGS` from `aclocal.m4` as follows: {{{ diff --git a/aclocal.m4 b/aclocal.m4 index 49c575e..de24752 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -615,6 +615,10 @@ AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], then $2="$$2 -fno-stack-protector" fi + if $CC -c conftest.c -Qunused-arguments > /dev/null 2>&1 + then + $2="$$2 -Qunused-arguments" + fi }}} If that modifies the CFLAGS for the stage0 compiler then this is obviously the wrong approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 9 00:44:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Mar 2016 00:44:59 -0000 Subject: [GHC] #11684: Fix tests with Clang In-Reply-To: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> References: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> Message-ID: <059.799d3683329a37de629bd76bd33b5ef0@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): From IRC: {{{ erikd: FPTOOLS_SET_C_LD_FLAGS also sets CONF_CC_OPTS_STAGE0 it seems FPTOOLS_SET_C_LD_FLAGS([build],[CONF_CC_OPTS_STAGE0], [CONF_GCC_LINKER_OPTS_STAGE0],[CONF_LD_LINKER_OPTS_STAGE0], [CONF_CPP_OPTS_STAGE0]) in configure.ac }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 9 01:04:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Mar 2016 01:04:41 -0000 Subject: [GHC] #11681: ghc panic with TypeError In-Reply-To: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> References: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> Message-ID: <059.46bcaf7e6f39bf2d9d3a14c224691e0b@haskell.org> #11681: ghc panic with TypeError -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aavogt): I can't reproduce the original problem with -rc2 either, but I get the original error message with this file: {{{#!hs {-# LANGUAGE FlexibleInstances #-} class C x where m :: x () class B x instance B x => C x }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160204 for x86_64-unknown-linux): fvProv falls into a hole {a1eE} }}} Interestingly the kind error is in there if we're missing FlexibleInstances {{{ kind_error_fvprov.hs:12:17: error: ? Illegal instance declaration for ?C x? (All instance types must be of the form (T a1 ... an) where a1 ... an are *distinct type variables*, and each type variable appears at most once in the instance head. Use FlexibleInstances if you want to disable this.) ? In the instance declaration for ?C x? kind_error_fvprov.hs:12:19: error: ? Expected kind ?* -> *?, but ?x? has kind ?*? ? In the first argument of ?C?, namely ?x? In the instance declaration for ?C x? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 9 01:51:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Mar 2016 01:51:27 -0000 Subject: [GHC] #11681: ghc panic with TypeError In-Reply-To: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> References: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> Message-ID: <059.fe097f6efdb5a886022c11e9f338b248@haskell.org> #11681: ghc panic with TypeError -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by inaki): Replying to [comment:5 aavogt]: > I can't reproduce the original problem with -rc2 either This is very bizarre: I just updated to the latest build in fedora (which still identifies itself with the same version) and couldn't reproduce the crash either. But the example by aavogt above also crashes for me. And playing around with my original example, the following **does** crash: {{{#!hs {-# LANGUAGE DataKinds, FlexibleContexts, TypeOperators, FlexibleInstances #-} import GHC.TypeLits class C t where instance (TypeError (Text "A" :<>: {- Text -} "B")) => C t where main :: IO () main = return () }}} Notice the absence of the `UndecidableInstances` extension, the content is otherwise identical. It is not impossible I made a mistake when copying the original example for the crash, apologies if this was the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 9 04:50:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Mar 2016 04:50:33 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.53e4765d5ba5c36049a9e25f3a1b4ebb@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I just tripped over this, with `TcCoercibleFail` timing out when testing against a `DEBUG` build. Can we somehow tell the testsuite to skip this one in this scenario until we have a better workaround? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 9 05:14:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Mar 2016 05:14:23 -0000 Subject: [GHC] #11690: stage 1 compiler silently ignores plugins Message-ID: <043.6bb550c2fb8b0e3c6348c8759d6a0132@haskell.org> #11690: stage 1 compiler silently ignores plugins -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It can't load plugins but it shouldn't just silently ignore IMHO. At least a warning would be nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 9 09:04:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Mar 2016 09:04:57 -0000 Subject: [GHC] #11684: Fix tests with Clang In-Reply-To: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> References: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> Message-ID: <059.f721e53ac19024ca81410f5e46224437@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ?Phab:D1986 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * differential: => ?Phab:D1986 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 9 13:14:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Mar 2016 13:14:07 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.f2c8813fc9d3235d8ad023184c07e4b7@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1973 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4c3a0a4a7b999251cbbee00befbfe32b86e556e2/ghc" 4c3a0a4a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4c3a0a4a7b999251cbbee00befbfe32b86e556e2" Fix the implementation of lazyId 'lazy' was doing part of its job, but not all! In particular, an application f (lazy e) where f is strict, was still being compiled using call-by-value in CorePrep. This defeated the purpose of defining catch as catch a b = catch# (lazy a) b See Trac #11555, and Neil Mitchell's test case in comment:14 This patch makes 'lazy' behave properly. I updated Note [lazyId magic] in MkId, but all the action is in CorePrep. I can't say I really like this, but it does the job. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 9 13:16:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Mar 2016 13:16:38 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.7ebb48e435f8afa048b4f4f1ccf54bb8@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1973 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, so pls merge the patch in comnent:17. And could you please add Neil's test in comment:14 as a regression test? Neil: I think this should work for you now. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 9 13:42:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Mar 2016 13:42:42 -0000 Subject: [GHC] #11681: ghc panic with TypeError In-Reply-To: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> References: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> Message-ID: <059.e28181d5d91121b4791c35ea6f240e91@haskell.org> #11681: ghc panic with TypeError -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I dunno about RC2, but HEAD says (on the program in in comment:6): {{{ T11681.hs:11:42: error: ? Expected kind ?ErrorMessage?, but ?"B"? has kind ?Symbol? ? In the second argument of ?:<>:?, namely ?"B"? In the first argument of ?TypeError?, namely ?Text "A" :<>: "B"? In the instance declaration for ?C t? }}} which seems pretty plausible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 9 16:20:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Mar 2016 16:20:01 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.6535d0e0b9e9b6b3b47d21913c30ae96@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I don't have particularly strong feelings on this matter, and I'd be okay with reverting this for now, since multiple GHC devs have expressed their displeasure in this change. This change does minimize the number of parentheses outputted in a way that agrees with the Haskell Report, but as Edward Kmett notes in a [https://mail.haskell.org/pipermail/haskell-cafe/2009-November/069497.html Haskell Caf? thread], we're already not using a minimal amount of parentheses as it is due to `Show` not taking fixity into account when parenthesizing (e.g., you can omit parentheses when chaining several `infixl` constructors). I wouldn't feel terrible about adding extra parentheses in this particular case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 9 20:01:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Mar 2016 20:01:29 -0000 Subject: [GHC] #11691: Documentation indicates RelaxedPolyRec is optional Message-ID: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> #11691: Documentation indicates RelaxedPolyRec is optional -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The documentation in "Other Type System Extensions" says "If `-XRelaxedPolyRec` is specified ..." and "With -XRelaxedPolyRec ..." and "This flag implies `-XRelaxedPolyRec`". There may be other references elsewhere. In fact, `RelaxedPolyRec` has been not only the default but in fact ''impossible to turn off'' since at least GHC 7.6.3. The documentation should probably stop mentioning the (long-meaningless) flag, and simply state that GHC uses Jones's extension instead. The Haskell Report section cited regarding contexts in explicit signatures for declaration groups is so vague that I'm not sure it's even worth mentioning that GHC relaxes it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 9 20:08:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Mar 2016 20:08:54 -0000 Subject: [GHC] #5850: Greater customization of GHCi prompt In-Reply-To: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> References: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> Message-ID: <065.a8e8f34f67ffc2eba2686fd16347754e@haskell.org> #5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: niksaz Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9994 | Differential Rev(s): Phab:D623 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niksaz): * owner: => niksaz Comment: Working on this feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 9 20:45:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Mar 2016 20:45:30 -0000 Subject: [GHC] #11691: Documentation indicates RelaxedPolyRec is optional In-Reply-To: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> References: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> Message-ID: <060.45574c3aff6f97f591f26fb9dbd2448b@haskell.org> #11691: Documentation indicates RelaxedPolyRec is optional -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good idea! Might you offer a patch? Thanks for pointing this out. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 9 23:59:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Mar 2016 23:59:42 -0000 Subject: [GHC] #9887: No message when GHCi reusing compiled code In-Reply-To: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> References: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> Message-ID: <060.6384432fa5ea9827938b0edb72392c99@haskell.org> #9887: No message when GHCi reusing compiled code -------------------------------------+------------------------------------- Reporter: jsrice | Owner: lukyanov Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1991 Wiki Page: | -------------------------------------+------------------------------------- Changes (by lukyanov): * owner: => lukyanov * differential: => Phab:D1991 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 06:16:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 06:16:20 -0000 Subject: [GHC] #11692: Suggest default definition of Applicative Message-ID: <051.d49ddb0a05fa30783e0a6deba6437f12@haskell.org> #11692: Suggest default definition of Applicative -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs ghci> data A a = A a deriving (Show, Functor) ghci> instance Monad A :3:10: error: ? No instance for (Applicative A) arising from the superclasses of an instance declaration ? In the instance declaration for ?Monad A? }}} could suggest defining it in terms of `Monad`: {{{#!hs :3:10: error: ? No instance for (Applicative A) arising from the superclasses of an instance declaration ? In the instance declaration for ?Monad A? ? Default implementation given a `Monad` instance: instance Applicative A where pure = return (<*>) = Control.Monad.ap }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 08:12:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 08:12:09 -0000 Subject: [GHC] #11693: Add `When` type family Message-ID: <051.b86a72dd66c608270c9e71ac37cbc943@haskell.org> #11693: Add `When` type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Does a type family like `When` from [https://github.com/mikeizbicki/subhask/blob/master/src/SubHask/SubType.hs#L133 here] belong somewhere in `Data.Types.*` {{{#!hs type family When (a :: Bool) (b :: Constraint) :: Constraint where When True b = b When False b = () }}} like [https://hackage.haskell.org/package/base/docs/Control- Monad.html#v:when when]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 09:07:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 09:07:49 -0000 Subject: [GHC] #11475: Lint should check for inexhaustive alternatives In-Reply-To: <046.fd80dcd8f8868c23b12a0a5bfb5d7bcb@haskell.org> References: <046.fd80dcd8f8868c23b12a0a5bfb5d7bcb@haskell.org> Message-ID: <061.bdee08cda1cd3cf9a86b1e736740e19f@haskell.org> #11475: Lint should check for inexhaustive alternatives -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah yes, that is tricky. I'm really not sure how far it is profitable to go here. That is, when does keeping Lint happy become burdensome? But let me suggest a possible approach for this particular case. * Ids have Unfoldings inside them. One such is `OtherCon [AltCon]` (see `CoreSyn`) which says "this Id does not match any of these constructors". * Since they are Ids even lambda-bound variables may have unfoldings. I'm in two minds about whether this is a good idea, but you could give the `\y` in the defn of `lvl` above a `OtherCon[A,B]` unfolding. Then you wouldn't get a Lint error from the `case` in `lvl`. * But in exchange you'd have a new thing to check: that `lvl` was indeed applied to arguments that were not `A` or `B`. So I'm not sure we are any further forward. Maybe this can only be done with a better flow analysis... a "super-Lint" if you like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 12:27:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 12:27:35 -0000 Subject: [GHC] #11694: The function `lift'ghc: panic! (the 'impossible' happened) Message-ID: <048.525e6af3a4c4087bd326a138fab1eb31@haskell.org> #11694: The function `lift'ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Sventimir | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The error message I got doesn't even make much sense (or at least I don't understand it). Here it is: {{{ src/Splices.hs:22:18: Couldn't match kind `* -> *' with `*' Expected type: (a1 -> a1) -> heist-0.14.1.1:Heist.Internal.Types.HeistState.HeistT m m Text Actual type: (a1 -> a1) -> heist-0.14.1.1:Heist.Internal.Types.HeistState.HeistT m m Text Kind incompatibility when matching types: a_t -> a_t :: * -> * a1 -> a1 :: * The function `lift'ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} As far as I understand it says that two things of the same type (a -> a) have different kind... And the offending function is really simple: {{{#!hs import Happstack.Server (path) import Heist.Interpreted (textSplice) insertFromPath :: Splice m insertFromPath = lift path id >>= textSplice }}} I believe that `m` should evaluate to `ServerPartT IO` from Happstack.Server module. I append the whole source code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 12:28:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 12:28:12 -0000 Subject: [GHC] #11694: The function `lift'ghc: panic! (the 'impossible' happened) In-Reply-To: <048.525e6af3a4c4087bd326a138fab1eb31@haskell.org> References: <048.525e6af3a4c4087bd326a138fab1eb31@haskell.org> Message-ID: <063.5920218755bc7a769dbd05553b9c9270@haskell.org> #11694: The function `lift'ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Sventimir | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Sventimir): * Attachment "Splices.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 12:28:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 12:28:22 -0000 Subject: [GHC] #11694: The function `lift'ghc: panic! (the 'impossible' happened) In-Reply-To: <048.525e6af3a4c4087bd326a138fab1eb31@haskell.org> References: <048.525e6af3a4c4087bd326a138fab1eb31@haskell.org> Message-ID: <063.1cd567be5843dc9a2bf59c8ed9a0ed2e@haskell.org> #11694: The function `lift'ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Sventimir | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Sventimir): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 13:41:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 13:41:57 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.801c2418096017ba2596559f7476474f@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rrnewton): * cc: rrnewton (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 13:47:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 13:47:57 -0000 Subject: [GHC] #11695: On GHCi prompt the arrow (movement) keys create strange character sequences Message-ID: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> #11695: On GHCi prompt the arrow (movement) keys create strange character sequences --------------------------------------+--------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Fire up `GHCi` and sit on the arrow down (or left) keys. This is what I get after constantly pressing for some time: {{{ $ ghci GHCi, version 8.1.20160202: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ggreif/.ghci Prelude> OBOBOBBOBOBOBOBOBOBOBCOCCOCOCCOCCOC :1:1: error: Data constructor not in scope: OBOBOBBOBOBOBOBOBOBOBCOCCOCOCCOCCOC }}} When such a strange letter appears, there is also a blinking of the terminal. It is not happening on Windows. I have seen it on RHEL5 and RHEL6. Pretty annoying, especially when you want to quickly navigate in the repl. This is probably a `haskeline` bug, but I am coming here to see whether others suffer from it too, i.e. is it reproducible for elseone? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 13:51:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 13:51:06 -0000 Subject: [GHC] #11695: On GHCi prompt the arrow (movement) keys create strange character sequences In-Reply-To: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> References: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> Message-ID: <063.45ed54f64bebf56d184c15fa61ceec87@haskell.org> #11695: On GHCi prompt the arrow (movement) keys create strange character sequences ---------------------------------+-------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by heisenbug): FWIW, I found this in a reddit thread, so it seems to be reproducible: https://www.reddit.com/r/haskell/comments/2jmdcg/ghci_uses_readline/clds4pm -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 14:10:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 14:10:42 -0000 Subject: [GHC] #11695: On GHCi prompt the arrow (movement) keys create strange character sequences In-Reply-To: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> References: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> Message-ID: <063.d58a39ce19ef453ac185314f7ce7d005@haskell.org> #11695: On GHCi prompt the arrow (movement) keys create strange character sequences ---------------------------------+-------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Hmmm, I tried holding the down arrow key for 30 seconds or so but was unable to reproduce this. That being said, it's possible this is due to a different typematic rate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 14:56:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 14:56:16 -0000 Subject: [GHC] #11695: On GHCi prompt the arrow (movement) keys create strange character sequences In-Reply-To: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> References: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> Message-ID: <063.fe27f7663c977e2095c7fa3175477929@haskell.org> #11695: On GHCi prompt the arrow (movement) keys create strange character sequences ---------------------------------+-------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by heisenbug): I did some experiments: doing it in an `ssh` session (to the very same machine) from a Windows laptop does not trigger the bug. I should say that the RHEL box is a server, `$DISPLAY` is a `vnc` session on different a login box. So there is more IO triggered on the `ghci` machine than one would assume. I did the same thing (wandering around in a block of "mmmmmm"), with `python` repl. No problems. So it mist be a `ghci` thing: {{{ $ ghci GHCi, version 7.11.20150407: http://www.haskell.org/ghc/ :? for help *Main> mmmmmmmmmmmmmmmmmmmmmmmmmmmmODmmmmmmOCmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmCmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmCmmmmmmmmmmmmmmmmmmmmmOODDmmmOCmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmOCmmmmmmmmmmmmDmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmOCmmCmmm :2:1: Not in scope: ?mmmmmmmmmmmmmmmmmmmmmmmmmmmmODmmmmmmOCmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmCmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmCmmmmmmmmmmmmmmmmmmmmmOODDmmmOCmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmOCmmmmmmmmmmmmDmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmOCmmCmmm? *Main> :q Leaving GHCi. $ python Python 2.3.7 (#1, Nov 3 2010, 17:47:44) [GCC 3.4.6] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm }}} Maybe this is some improper handling of `EINTR` (or such) ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 16:02:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 16:02:49 -0000 Subject: [GHC] #1365: -fbyte-code is ignored in a OPTIONS_GHC pragma In-Reply-To: <047.0b0f638b3610964bc1921eacae64b292@haskell.org> References: <047.0b0f638b3610964bc1921eacae64b292@haskell.org> Message-ID: <062.9c2ded86674b391de9ba57a9f758ee1d@haskell.org> #1365: -fbyte-code is ignored in a OPTIONS_GHC pragma -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: => None/Unknown Comment: This came up on [[https://mail.haskell.org/pipermail/ghc- devs/2016-March/011566.html|ghc-devs]] recently in a thread discussing loading GHC itself into GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 16:59:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 16:59:30 -0000 Subject: [GHC] #11696: Windows Install Makes Unnecessary/Incorrect PATH Changes Message-ID: <050.17364a786e2a83136dd65f23990038b8@haskell.org> #11696: Windows Install Makes Unnecessary/Incorrect PATH Changes -------------------------------------+------------------------------------- Reporter: AlexAndrews | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.10.3 system | Keywords: path | Operating System: Windows environment variable install | Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I installed haskell 7.10.3 (32-bit) under Windows XP SP3 into a folder on my L: drive. However, the installation process added a number of non- existent directories to my PATH variables: User environment variable PATH: C:\Documents and Settings\\Application Data\cabal\bin System environment variable PATH: C:\Program Files\Haskell\bin If these directories need to be in the PATH variables, they should be created by the installer and, if so, since I installed haskell to my L: drive, surely these should be created on my L: drive (or the user should be prompted for their location)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 17:28:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 17:28:04 -0000 Subject: [GHC] #11693: Add `When` type family In-Reply-To: <051.b86a72dd66c608270c9e71ac37cbc943@haskell.org> References: <051.b86a72dd66c608270c9e71ac37cbc943@haskell.org> Message-ID: <066.0bfe2fd8ecff32da60b94826aaf2e8ff@haskell.org> #11693: Add `When` type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): This strikes me as the kind of thing that belongs out in a user library like `constraints` or `subhask` as it requires a fair bit of machinery to use well, and suffers the sort of type-level "boolean blindness" that indicates it'd often need to be reimplemented subtly differently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 19:16:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 19:16:49 -0000 Subject: [GHC] #11696: Windows Install Makes Unnecessary/Incorrect PATH Changes In-Reply-To: <050.17364a786e2a83136dd65f23990038b8@haskell.org> References: <050.17364a786e2a83136dd65f23990038b8@haskell.org> Message-ID: <065.d6fcae4102a49b26708b4cf8537d24cb@haskell.org> #11696: Windows Install Makes Unnecessary/Incorrect PATH Changes -------------------------------------+------------------------------------- Reporter: AlexAndrews | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: | Keywords: path | environment variable install Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => upstream * component: Package system => None Comment: I suspect this is a Haskell Platform issue, not a GHC issue. I've mentioned this ticket to the Haskell Platform maintainers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 20:57:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 20:57:42 -0000 Subject: [GHC] #11694: The function `lift'ghc: panic! (the 'impossible' happened) In-Reply-To: <048.525e6af3a4c4087bd326a138fab1eb31@haskell.org> References: <048.525e6af3a4c4087bd326a138fab1eb31@haskell.org> Message-ID: <063.965dc91085c7c9ae66efa3e8d8f83dc7@haskell.org> #11694: The function `lift'ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Sventimir | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you (or someone) try with the 8.0 release candidate? This may well be fixed. See #11048 and friends Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 21:46:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 21:46:17 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2311697=3A_rts/posix/Itimer=2Ec=3A_ignoring?= =?utf-8?b?IHJldHVybiB2YWx1ZSBvZiDigJhyZWFk4oCZ?= Message-ID: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> #11697: rts/posix/Itimer.c: ignoring return value of ?read? -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Builds currently failing in travis. Eg : https://travis- ci.org/ghc/ghc/jobs/115023819 {{{ rts/posix/Itimer.c: In function ?itimer_thread_func?: rts/posix/Itimer.c:205:17: error: error: ignoring return value of ?read?, declared with attribute warn_unused_result [-Werror=unused-result] }}} The code being complained about is: {{{ if (USE_TIMERFD_FOR_ITIMER) { read(timerfd, &nticks, sizeof(nticks)); } else { }}} The value of `nticks` is never used, so a solution to this may be: {{{ if (USE_TIMERFD_FOR_ITIMER) { if (read(timerfd, &nticks, sizeof(nticks)) != sizeof(nticks)) nticks = 0; } else { }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 21:47:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 21:47:56 -0000 Subject: [GHC] #11698: GHC's tct_closed flag is not being set correctly Message-ID: <046.7686f983b8149fd1d6dcacf21545b08a@haskell.org> #11698: GHC's tct_closed flag is not being set correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `Note [Bindings with closed types]` in `TcEnv` describes when a binding is "closed", which in turn affects generalisation. (See the Note for details.) But the implementation doesn't follow the Note. Instead it uses this function in `TcEnv`: {{{ isClosedLetBndr :: Id -> TopLevelFlag -- See Note [Bindings with closed types] in TcRnTypes -- Note that we decided if a let-bound variable is closed by -- looking at its type, which is slightly more liberal, and a whole -- lot easier to implement, than looking at its free variables isClosedLetBndr id | isEmptyVarSet (tyCoVarsOfType (idType id)) = TopLevel | otherwise = NotTopLevel }}} It may be easier but it's also wrong. Consider {{{ f x = ( let g y = x+y in ... , x::Int) }}} Is `g` closed (which affects how definitions in `...` are generalised)? Well if we typecheck the second element of the tuple first, we may "know" that `x::Int` by the time we are inferring a type for `g`, conclude that `g` has no free type variables, and say that it is closed. But if we do the `x::Int` part second, so while type checking the `let` we think that `x::alpha`, then we'll say that `g` is open. This looks nasty. I think we should do it the way the `Note` says. Thanks to Facundo for pointing this out. Not urgent, but plainly wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 21:51:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 21:51:44 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.e75299adf1d491033a7a83e63fc7ac32@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by Sergei Trofimovich ): In [changeset:"c42cdb7f6dcfd519d9607ac9fa53f049b2922fb8/ghc" c42cdb7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c42cdb7f6dcfd519d9607ac9fa53f049b2922fb8" fix Float/Double unreg cross-compilation Looking at more failures on m68k (Trac #11395) I've noticed the arith001 and arith012 test failures. (--host=x86_64-linux --target=m68k-linux). The following example was enough to reproduce a problem: v :: Float v = 43 main = print v m68k binaries printed '0.0' instead of '43.0'. The bug here is how we encode Floats and Double as Words with the same binary representation. Floats: Before the patch we just coerced Float to Int. That breaks when we cross-compile from 64-bit LE to 32-bit BE. The patch fixes conversion by accounting for padding. when we extend 32-bit value to 64-bit value (LE and BE do it slightly differently). Doubles: Before the patch Doubles were coerced to a pair of Ints (not correct as x86_64 can hold Double in one Int) and then trucated this pair of Ints to pair of Word32. The patch fixes conversion by always decomposing in Word32 and accounting for host endianness (newly introduced hostBE) and target endianness (wORDS_BIGENDIAN). I've tested this patch on Double and Float conversion on --host=x86_64-linux --target=m68k-linux crosscompiler. It fixes 10 tests related to printing Floats and Doubles. Thanks to Bertram Felgenhauer who poined out this probem. Signed-off-by: Sergei Trofimovich Test Plan: checked some examples manually, fixed 10 tests in test suite Reviewers: int-e, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1990 GHC Trac Issues: #11395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 22:18:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 22:18:13 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311697=3A_rts/posix/Itimer=2Ec=3A_ig?= =?utf-8?b?bm9yaW5nIHJldHVybiB2YWx1ZSBvZiDigJhyZWFk4oCZ?= In-Reply-To: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> References: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> Message-ID: <059.cee568424a9036b63c89684d3b9b171d@haskell.org> #11697: rts/posix/Itimer.c: ignoring return value of ?read? -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Probably a better solution: {{{ if (USE_TIMERFD_FOR_ITIMER) { int MAYBE_UNUSED rc; rc = read(timerfd, &nticks, sizeof(nticks)) != sizeof(nticks)); } else { }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 22:19:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 22:19:59 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311697=3A_rts/posix/Itimer=2Ec=3A_ig?= =?utf-8?b?bm9yaW5nIHJldHVybiB2YWx1ZSBvZiDigJhyZWFk4oCZ?= In-Reply-To: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> References: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> Message-ID: <059.f5648d47a4b377f50a602cc43657ec84@haskell.org> #11697: rts/posix/Itimer.c: ignoring return value of ?read? -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by erikd: @@ -27,0 +27,3 @@ + + This seems to be a warning that only occurs on Ubuntu, because the Ubuntu + libc has marked the `read` function as `warn_unused_result`. New description: Builds currently failing in travis. Eg : https://travis- ci.org/ghc/ghc/jobs/115023819 {{{ rts/posix/Itimer.c: In function ?itimer_thread_func?: rts/posix/Itimer.c:205:17: error: error: ignoring return value of ?read?, declared with attribute warn_unused_result [-Werror=unused-result] }}} The code being complained about is: {{{ if (USE_TIMERFD_FOR_ITIMER) { read(timerfd, &nticks, sizeof(nticks)); } else { }}} The value of `nticks` is never used, so a solution to this may be: {{{ if (USE_TIMERFD_FOR_ITIMER) { if (read(timerfd, &nticks, sizeof(nticks)) != sizeof(nticks)) nticks = 0; } else { }}} This seems to be a warning that only occurs on Ubuntu, because the Ubuntu libc has marked the `read` function as `warn_unused_result`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 22:38:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 22:38:52 -0000 Subject: [GHC] #11696: Windows Install Makes Unnecessary/Incorrect PATH Changes In-Reply-To: <050.17364a786e2a83136dd65f23990038b8@haskell.org> References: <050.17364a786e2a83136dd65f23990038b8@haskell.org> Message-ID: <065.0fd86b379a8ac85a91a31cfb14441417@haskell.org> #11696: Windows Install Makes Unnecessary/Incorrect PATH Changes -------------------------------------+------------------------------------- Reporter: AlexAndrews | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: invalid | Keywords: path | environment variable install Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gershomb): * status: upstream => closed * resolution: => invalid Comment: Closing this as invalid as it is an HP issue, which in general should be reported here: https://github.com/haskell/haskell-platform That said, these two directories are not places that the platform installer itself creates or installs things to. They are, however, the directories that cabal will create and install things to by default when you `cabal install` an executable , and thus the platform installer (correctly) adds them to your path as a convenience. We can document this behavior further, but I see no need to change it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 22:50:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 22:50:42 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311697=3A_rts/posix/Itimer=2Ec=3A_ig?= =?utf-8?b?bm9yaW5nIHJldHVybiB2YWx1ZSBvZiDigJhyZWFk4oCZ?= In-Reply-To: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> References: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> Message-ID: <059.2a984bb7e26af6d180c5883640f9b37c@haskell.org> #11697: rts/posix/Itimer.c: ignoring return value of ?read? -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:1 erikd]: > Probably a better solution: IMO, in case of an unexpected return code we should rather emit some error/warning message. I would have fixed this myself a few days ago when this started breaking my `./validate`s but I didn't have time for a proper fix yet and was hoping the author of the patch would beat me providing a fix... PS: phab:rGHC120b9cdb31878ecee442c0a4bb9532a9d30c0c64 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 22:57:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 22:57:13 -0000 Subject: [GHC] #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options In-Reply-To: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> References: <051.9d27ecbb137bef89ba7eae5ddb6b4517@haskell.org> Message-ID: <066.931e2c4d5ef301591f951a18168f9f6d@haskell.org> #11677: Dramatic de-optimization with "-O", "-O1", "-O2" options -------------------------------------+------------------------------------- Reporter: malphunction | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: optimization | deoptimization Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is another in the long chain of tickets involving the "state hack" and `replicateM`. See #1168 for a list and #9388 for ideas. Sadly `-fno-state-hack` doesn't make any difference. Reason: the `fmap` for `IO` is begin called, and looks like {{{ fmapIO = \f a s. case a s of (r, s') -> (f r, s') }}} So if we have `replicateM (fmapIO (g (expensive x)) getLine)`, we'll inline `fmapIO` to {{{ replicateM (let f = g (expensive x) in \s. case getLine s of (r, s') -> (f r, s')) }}} Now if that `\s` which come from `fmapIO` is treated as one-shot, we'll inline `g (expensive x)` inside; disaster. The `-fno-state-hack` doesn't make any difference because Joachim arranged to persist one-shot-ness in interface files, so what matters is the setting in `GHC.Base` where `fmapIO` was defined. Anyway that's the reason, and we have many examples of it. The right solution is sketched in #9388 but it needs someone to pick up the cudgels. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 22:58:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 22:58:07 -0000 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@haskell.org> References: <047.1e9bce153303809272446b6c0aede02d@haskell.org> Message-ID: <062.28a1b717a48b0995202d41569980acee@haskell.org> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | nofib/spectral/calendar Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See #11677 for another example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 10 23:33:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Mar 2016 23:33:53 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311697=3A_rts/posix/Itimer=2Ec=3A_ig?= =?utf-8?b?bm9yaW5nIHJldHVybiB2YWx1ZSBvZiDigJhyZWFk4oCZ?= In-Reply-To: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> References: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> Message-ID: <059.c00c0c0bbe26eb00831efbb2aaea9577@haskell.org> #11697: rts/posix/Itimer.c: ignoring return value of ?read? -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Replying to [comment:3 hvr]: > IMO, in case of an unexpected return code we should rather emit some error/warning message. I would have fixed this myself a few days ago when this started breaking my `./validate`s but I didn't have time for a proper fix yet and was hoping the author of the patch would beat me providing a fix... Would you prefer something like: {{{ if (USE_TIMERFD_FOR_ITIMER) { if (read(timerfd, &nticks, sizeof(nticks)) != sizeof(nticks)) sysErrorBelch("Itimer: read(timer_fd) failed"); } else { }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 03:24:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 03:24:07 -0000 Subject: [GHC] #11695: On GHCi prompt the arrow (movement) keys create strange character sequences In-Reply-To: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> References: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> Message-ID: <063.2e9978e433c3ec9fe502e6674b5db618@haskell.org> #11695: On GHCi prompt the arrow (movement) keys create strange character sequences ---------------------------------+-------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by judahj): By any chance are you using tmux or a similar program? If so, check out the instructions here (your symptoms sound similar): https://github.com/judah/haskeline/wiki/UsingTmux Otherwise, can you give a little more information about your setup? - What is the value of $TERM - What terminal program (e.g. xterm) you're using - To try to figure out exactly what's confusing ghci: can you explain more what "$DISPLAY is a vnc session on a different box" means? I'm not familiar with that kind of setup. Which machine are you actually typing text into, and how is that text being relayed to the server that's actually running ghci? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 07:39:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 07:39:55 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.a348eedcf3bb14db4662f482270f90ba@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: erikd Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9043 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * owner: bgamari => erikd Comment: I have something that compiles but doesn't work yet. I'll take this over, -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 08:56:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 08:56:48 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311697=3A_rts/posix/Itimer=2Ec=3A_ig?= =?utf-8?b?bm9yaW5nIHJldHVybiB2YWx1ZSBvZiDigJhyZWFk4oCZ?= In-Reply-To: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> References: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> Message-ID: <059.580ed56f8a05cf10a41807b547e6da6d@haskell.org> #11697: rts/posix/Itimer.c: ignoring return value of ?read? -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): ...yes, definitely better than silencing symptoms...! :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 08:58:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 08:58:25 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311697=3A_rts/posix/Itimer=2Ec=3A_ig?= =?utf-8?b?bm9yaW5nIHJldHVybiB2YWx1ZSBvZiDigJhyZWFk4oCZ?= In-Reply-To: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> References: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> Message-ID: <059.ed9eeb903793f3a1508dea6592e29429@haskell.org> #11697: rts/posix/Itimer.c: ignoring return value of ?read? -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D1993 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => phab:D1993 Comment: I see you already made a patch... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 10:07:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 10:07:09 -0000 Subject: [GHC] #11678: runhaskell (and ghc, ghci) fail to run if HOME is not set In-Reply-To: <046.9c5274446945cc784560071347805372@haskell.org> References: <046.9c5274446945cc784560071347805372@haskell.org> Message-ID: <061.83af8006499ee5ab732ee1869520d3bf@haskell.org> #11678: runhaskell (and ghc, ghci) fail to run if HOME is not set -------------------------------------+------------------------------------- Reporter: crosser | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1971 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 10:58:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 10:58:56 -0000 Subject: [GHC] #11698: GHC's tct_closed flag is not being set correctly In-Reply-To: <046.7686f983b8149fd1d6dcacf21545b08a@haskell.org> References: <046.7686f983b8149fd1d6dcacf21545b08a@haskell.org> Message-ID: <061.5ab27e2771e61d04091421a5a46703f5@haskell.org> #11698: GHC's tct_closed flag is not being set correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mboes): * cc: mboes (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 11:03:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 11:03:57 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.1dfcd7fe07191c0dde99e762cebc3b13@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 11698 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mboes): * blockedby: => 11698 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:26:51 -0000 Subject: [GHC] #11624: Cannot declare hs-boot declaration if there is already a value in scope In-Reply-To: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> References: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> Message-ID: <060.ac7a0045c9f5cae41ee2a141f3845144@haskell.org> #11624: Cannot declare hs-boot declaration if there is already a value in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10472 | Differential Rev(s): Phab:D1963 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fc16690a536b74e7af72e963599471474e3df603/ghc" fc16690/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fc16690a536b74e7af72e963599471474e3df603" Fix #11624, cannot declare hs-boot if already one in scope. I'm not sure if this fix is the "right way" to do it, but it solves the proximal problem, which is that lookupBindGroupOcc was picking out the wrong renaming for hs-boot signatures, which then lead to an interface file error. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1963 GHC Trac Issues: #11624 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:26:51 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.b7c3d75e948939afb0dfbb1c703caacc@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1973 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c937f424e4acd61d1c558e8fe9b47e7d580fdbd8/ghc" c937f424/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c937f424e4acd61d1c558e8fe9b47e7d580fdbd8" Add regression test for #11555 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:26:51 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.82798da408896ae36ccbf37f7699f71e@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1973 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"30ee9102db2f16894912e19b9d16156824611bbb/ghc" 30ee9102/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="30ee9102db2f16894912e19b9d16156824611bbb" Make `catch` lazy in the action Previously ```lang=haskell catch (error "uh oh") (\(_ :: SomeException) -> print "it failed") ``` would unexpectedly fail with "uh oh" instead of the handler being run due to the strictness of `catch` in its first argument. See #11555 for details. Test Plan: Validate Reviewers: austin, hvr, simonpj Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1973 GHC Trac Issues: #11555 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:26:51 -0000 Subject: [GHC] #11679: Quasi-quoting syntax is ambiguous with list comprehensions In-Reply-To: <046.e4bc67337e38c6a1747904f615313ea3@haskell.org> References: <046.e4bc67337e38c6a1747904f615313ea3@haskell.org> Message-ID: <061.3d382a7cc755b8d95959bb3d57c1be0b@haskell.org> #11679: Quasi-quoting syntax is ambiguous with list comprehensions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"767ff7cab7fc2d27b66cdd25d551ccf9e9e7c51d/ghc" 767ff7ca/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="767ff7cab7fc2d27b66cdd25d551ccf9e9e7c51d" Document Quasi-quotes/list comprehension ambiguity Test Plan: read it Reviewers: austin, goldfire Reviewed By: goldfire Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D1981 GHC Trac Issues: #11679 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:26:51 -0000 Subject: [GHC] #11354: Install script installs docs without -version suffix In-Reply-To: <043.018901061c911df7ad296ca4936d7024@haskell.org> References: <043.018901061c911df7ad296ca4936d7024@haskell.org> Message-ID: <058.16fb45fe0ce30770a5907364dc32706b@haskell.org> #11354: Install script installs docs without -version suffix -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1868 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a74a3846c84ad55de3deeed8b2401a2ed514b2e1/ghc" a74a384/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a74a3846c84ad55de3deeed8b2401a2ed514b2e1" Include version in AC_PACKAGE_TARNAME `AC_PACKAGE_TARNAME` is used by autoconf to generate the default value of docdir, which we now set to include a version number (see #11354). This fixed #11659. Test Plan: `./configure --help`, validate Reviewers: austin, thomie, hvr, erikd Reviewed By: hvr, erikd Subscribers: erikd Differential Revision: https://phabricator.haskell.org/D1983 GHC Trac Issues: #11659 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:26:51 -0000 Subject: [GHC] #11145: Template Haskell quotes of data instance GADTs is totally broken In-Reply-To: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> References: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> Message-ID: <062.933f332d180ff7fe3e8d3790746b651f@haskell.org> #11145: Template Haskell quotes of data instance GADTs is totally broken -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bollmann Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1978 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f3def7643d390db54d18b8c3d385c490fba58a41/ghc" f3def76/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f3def7643d390db54d18b8c3d385c490fba58a41" add regression test for #11145. The original TH failure observed by the ticket, namely that Template Haskell quotes of data instance GADTs are broken, is not observable anymore in HEAD. I therefore just added the corresponding regression test. Test Plan: ./validate Reviewers: goldfire, austin, thomie, jstolarek, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1978 GHC Trac Issues: #11145 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:26:51 -0000 Subject: [GHC] #11659: configure --help incorrectly says --docdir is still unversioned by default In-Reply-To: <050.007b9aca933c6049d4b4848346195a1d@haskell.org> References: <050.007b9aca933c6049d4b4848346195a1d@haskell.org> Message-ID: <065.fc8b16ebc507df1647984a29075fe2f2@haskell.org> #11659: configure --help incorrectly says --docdir is still unversioned by default -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1983 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a74a3846c84ad55de3deeed8b2401a2ed514b2e1/ghc" a74a384/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a74a3846c84ad55de3deeed8b2401a2ed514b2e1" Include version in AC_PACKAGE_TARNAME `AC_PACKAGE_TARNAME` is used by autoconf to generate the default value of docdir, which we now set to include a version number (see #11354). This fixed #11659. Test Plan: `./configure --help`, validate Reviewers: austin, thomie, hvr, erikd Reviewed By: hvr, erikd Subscribers: erikd Differential Revision: https://phabricator.haskell.org/D1983 GHC Trac Issues: #11659 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:26:51 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311697=3A_rts/posix/Itimer=2Ec=3A_ig?= =?utf-8?b?bm9yaW5nIHJldHVybiB2YWx1ZSBvZiDigJhyZWFk4oCZ?= In-Reply-To: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> References: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> Message-ID: <059.2925869d0a88a1eb1d38f58a9a061895@haskell.org> #11697: rts/posix/Itimer.c: ignoring return value of ?read? -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D1993 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8626d76a723c2514bab91afb82e6b8b94fed2a2b/ghc" 8626d76a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8626d76a723c2514bab91afb82e6b8b94fed2a2b" rtx/posix/Itimer.c: Handle return value of `read` On Ubuntu libc's `read` function is marked with attribute `warn_unused_result` which was causing build failures on Harbourmaster. Test Plan: validate on Harbourmaster Reviewers: austin, hvr, bgamari Reviewed By: hvr, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1993 GHC Trac Issues: #11697 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:26:51 -0000 Subject: [GHC] #10691: certain operations in new integer-gmp are too lazy In-Reply-To: <047.5a091b0736d5db136f703c98736ac583@haskell.org> References: <047.5a091b0736d5db136f703c98736ac583@haskell.org> Message-ID: <062.e60eed58df6c789a7760633c99ecd6ec@haskell.org> #10691: certain operations in new integer-gmp are too lazy -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries | Version: 7.10.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f8056fca87e83fd37d3f2441f5cb0335e12e3aef/ghc" f8056fc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f8056fca87e83fd37d3f2441f5cb0335e12e3aef" Make integer-gmp operations more strict Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1984 GHC Trac Issues: #10691 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:26:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:26:52 -0000 Subject: [GHC] #11678: runhaskell (and ghc, ghci) fail to run if HOME is not set In-Reply-To: <046.9c5274446945cc784560071347805372@haskell.org> References: <046.9c5274446945cc784560071347805372@haskell.org> Message-ID: <061.703bbcdcd095e097fe0f1d4bdad15f84@haskell.org> #11678: runhaskell (and ghc, ghci) fail to run if HOME is not set -------------------------------------+------------------------------------- Reporter: crosser | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1971 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2908ae8dbe8fd69f8c3ac3dab199026dfc250445/ghc" 2908ae8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2908ae8dbe8fd69f8c3ac3dab199026dfc250445" Handle unset HOME environment variable more gracefully Test Plan: * Validate * try `env -i ghc` * try `env -i runghc HelloWorld.hs` Reviewers: austin Subscribers: thomie, ezyang Differential Revision: https://phabricator.haskell.org/D1971 GHC Trac Issues: #11678 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:29:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:29:38 -0000 Subject: [GHC] #11696: Windows Install Makes Unnecessary/Incorrect PATH Changes In-Reply-To: <050.17364a786e2a83136dd65f23990038b8@haskell.org> References: <050.17364a786e2a83136dd65f23990038b8@haskell.org> Message-ID: <065.c1d5b93b77189fad04598670603d77df@haskell.org> #11696: Windows Install Makes Unnecessary/Incorrect PATH Changes -------------------------------------+------------------------------------- Reporter: AlexAndrews | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: invalid | Keywords: path | environment variable install Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AlexAndrews): Replying to [comment:2 gershomb]: > Closing this as invalid as it is an HP issue, which in general should be reported here: https://github.com/haskell/haskell-platform > > That said, these two directories are not places that the platform installer itself creates or installs things to. They are, however, the directories that cabal will create and install things to by default when you `cabal install` an executable , and thus the platform installer (correctly) adds them to your path as a convenience. We can document this behavior further, but I see no need to change it. Fair enough, but having asked where Haskell should be installed, the HP should also ask where to locate the directories that `cabal install` will use. I will submit an HP ticket on the URL you provided. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:29:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:29:40 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.44325076fcb93e6fbce9116a788607f5@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1973 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge Comment: Need to merge 4c3a0a4a, 30ee9102, c937f424e4acd61d1c558e8fe9b47e7d580fdbd8, and a1c4230e15cbf897b97903c8a1199a1cc91efd26 to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:31:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:31:05 -0000 Subject: [GHC] #11624: Cannot declare hs-boot declaration if there is already a value in scope In-Reply-To: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> References: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> Message-ID: <060.788eb161ea92f2ccdb5cc4d6f2b383d1@haskell.org> #11624: Cannot declare hs-boot declaration if there is already a value in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10472 | Differential Rev(s): Phab:D1963 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:33:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:33:24 -0000 Subject: [GHC] #11659: configure --help incorrectly says --docdir is still unversioned by default In-Reply-To: <050.007b9aca933c6049d4b4848346195a1d@haskell.org> References: <050.007b9aca933c6049d4b4848346195a1d@haskell.org> Message-ID: <065.5c2a2a8b5203d4ef63e49fed44359bed@haskell.org> #11659: configure --help incorrectly says --docdir is still unversioned by default -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1983 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged as cabe4620ca7eeddfcf8b2ee624eac6be029e2276 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:34:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:34:51 -0000 Subject: [GHC] #11679: Quasi-quoting syntax is ambiguous with list comprehensions In-Reply-To: <046.e4bc67337e38c6a1747904f615313ea3@haskell.org> References: <046.e4bc67337e38c6a1747904f615313ea3@haskell.org> Message-ID: <061.adf1a7378f82c683b9a7eb2b736be21e@haskell.org> #11679: Quasi-quoting syntax is ambiguous with list comprehensions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1981 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Merged as 57cfb4740424f4ab49f772a241fc38bf18d9d19c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:37:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:37:12 -0000 Subject: [GHC] #10691: certain operations in new integer-gmp are too lazy In-Reply-To: <047.5a091b0736d5db136f703c98736ac583@haskell.org> References: <047.5a091b0736d5db136f703c98736ac583@haskell.org> Message-ID: <062.95b3e9195339b647b4cf407eb4637f50@haskell.org> #10691: certain operations in new integer-gmp are too lazy -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: libraries | Version: 7.10.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: 8.2.1 => 8.0.1 @@ -8,1 +8,1 @@ - For consistency not just with Int, but also other integer-* + For consistency not just with `Int`, but also other integer-* New description: This came up in #ghc the other day. {{{ rwbarton at morphism:~$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> undefined * 0 0 }}} For consistency not just with `Int`, but also other integer-* implementations, this should be undefined. Also affected is for example `andInteger`. -- Comment: Perhaps we want this in 8.0 afterall. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 12:39:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 12:39:38 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.367d198aa5cb32ead8f5a77cf5bb79a5@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.0.1 Comment: This seems like a bad enough issue that we may want to merge to 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 13:11:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 13:11:00 -0000 Subject: [GHC] #11678: runhaskell (and ghc, ghci) fail to run if HOME is not set In-Reply-To: <046.9c5274446945cc784560071347805372@haskell.org> References: <046.9c5274446945cc784560071347805372@haskell.org> Message-ID: <061.2f90b4d9da2e477a977f66893e0d21f3@haskell.org> #11678: runhaskell (and ghc, ghci) fail to run if HOME is not set -------------------------------------+------------------------------------- Reporter: crosser | Owner: bgamari Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1971 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 13:27:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 13:27:53 -0000 Subject: [GHC] #11678: runhaskell (and ghc, ghci) fail to run if HOME is not set In-Reply-To: <046.9c5274446945cc784560071347805372@haskell.org> References: <046.9c5274446945cc784560071347805372@haskell.org> Message-ID: <061.0d4515d9878b5884a48f9497cfa2b099@haskell.org> #11678: runhaskell (and ghc, ghci) fail to run if HOME is not set -------------------------------------+------------------------------------- Reporter: crosser | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1971 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 6e524ebaf299043990048356b01c045f2d6dc0d5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 13:29:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 13:29:19 -0000 Subject: [GHC] #10691: certain operations in new integer-gmp are too lazy In-Reply-To: <047.5a091b0736d5db136f703c98736ac583@haskell.org> References: <047.5a091b0736d5db136f703c98736ac583@haskell.org> Message-ID: <062.a37b9473aaaba7b0ed08becdcbc368b3@haskell.org> #10691: certain operations in new integer-gmp are too lazy -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: libraries | Version: 7.10.1 (other) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as e764ede35f5c5b2c41e1670c6a9b831e0a70cd17. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 13:31:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 13:31:51 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.02226d5631abf254237ac4061a9f2479@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as bbdc52f3a6e6a28e209fb8f65699121d4ef3a4e3 and fd3e581b7c9142247601774afc98e49f63b8af45. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 13:32:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 13:32:16 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311697=3A_rts/posix/Itimer=2Ec=3A_ig?= =?utf-8?b?bm9yaW5nIHJldHVybiB2YWx1ZSBvZiDigJhyZWFk4oCZ?= In-Reply-To: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> References: <044.4543018424ad0d22ee23eae77687d0ae@haskell.org> Message-ID: <059.dc736aadc191bb6e4e3583d5576e0242@haskell.org> #11697: rts/posix/Itimer.c: ignoring return value of ?read? -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D1993 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Merged to `ghc-8.0` as fd3e581b7c9142247601774afc98e49f63b8af45. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 13:33:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 13:33:22 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.6cde1a8e59bac45d31c82e00d82e8591@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1973 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 13:35:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 13:35:51 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.a806d2ec4c6f3912335860d5e461792e@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11608 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: comment:18 has been merged to `ghc-8.0` as 43163e3bd5bcd7c92fc692b365be750a7b766026. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 13:38:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 13:38:57 -0000 Subject: [GHC] #11624: Cannot declare hs-boot declaration if there is already a value in scope In-Reply-To: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> References: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> Message-ID: <060.d4b8d74840d7b75e42451d4d0b4d16cb@haskell.org> #11624: Cannot declare hs-boot declaration if there is already a value in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10472 | Differential Rev(s): Phab:D1963 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed @@ -3,1 +3,1 @@ - {{{ + {{{#!hs @@ -49,1 +49,1 @@ - Is a regression from 7.10. The dodginess is proximal to renameSig but I + Is a regression from 7.10. The dodginess is proximal to `renameSig` but I New description: This code no longer works: {{{#!hs -- A.hs-boot module A where concat :: Int -> Int -- overlaps with Prelude's concat -- B.hs module B where import Prelude () import {-# SOURCE #-} A x = concat 3 -- A.hs module A where import B concat n = n + 2 }}} Building `ghc --make A`, this crashes with: {{{ [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling B ( B.hs, B.o ) B.hs:4:5: error: ? Can't find interface-file declaration for variable concat Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ? In the expression: concat 3 In an equation for ?x?: x = concat 3 }}} The trouble is that renaming has botched up the top-level declaration for boot: {{{ ezyang at sabre:~$ ghc-8.0 -c A.hs-boot -ddump-rn -dppr-debug A.hs-boot:1:1: ==================== Renamer ==================== {A.hs-boot:2:1-20} base-4.9.0.0:Data.Foldable.concat{v r2S} :: {A.hs-boot:2:11-20} ghc-prim-0.5.0.0:GHC.Types.Int{(w) tc 3J} -> ghc-prim-0.5.0.0:GHC.Types.Int{(w) tc 3J} }}} Is a regression from 7.10. The dodginess is proximal to `renameSig` but I haven't quite narrowed it down yet. -- Comment: Merged to `ghc-8.0` as 88a86f126f0fb2439b832927d51fd6d6445135b7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 13:40:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 13:40:44 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.ea29ac6a0b88632d23a71b80c2a70c38@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: merge Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D876 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge Comment: Hasn't been merged yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 13:41:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 13:41:14 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.27fe559c3fe5483945a73611991c9750@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D876 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 745bdd88f9e4f9c85d46e84c58d6799bf71725b7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 14:45:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 14:45:46 -0000 Subject: [GHC] #11692: Suggest default definition of Applicative In-Reply-To: <051.d49ddb0a05fa30783e0a6deba6437f12@haskell.org> References: <051.d49ddb0a05fa30783e0a6deba6437f12@haskell.org> Message-ID: <066.2445c858aec809b8feb6474a2f39f641@haskell.org> #11692: Suggest default definition of Applicative -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Your suggested warning enhancement is in contradiction to the recommendation expressed in several places (migration guide, AMP wiki page etc, `-Wnoncanonical-monad-instances`) to define `return` in terms of `pure` rather than the other way round. In fact, since GHC 7.10/base-4.8 you don't even need to define `Monad(return)` at all anymore, as it's got a default implementation `return = pure`. Suggesting to define `pure = return` risks ending up with circular definition of `return`/`pure` when refactoring. In fact, together with the MonadFail proposal the proper (minimal, i.e. excluding non-mandatory methods) mental model of the F-A-M-MF hierarchy to have is more or less: {{{#!hs class Functor f where fmap :: (a -> b) -> f a -> f b class Functor f => Applicative f where pure :: a -> f a (<*>) :: f (a -> b) -> f a -> f b class Applicative m => Monad m where (>>=) :: m a -> (a -> m b) -> m b class Monad m => MonadFail m fail :: String -> m a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 14:48:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 14:48:25 -0000 Subject: [GHC] #11698: GHC's tct_closed flag is not being set correctly In-Reply-To: <046.7686f983b8149fd1d6dcacf21545b08a@haskell.org> References: <046.7686f983b8149fd1d6dcacf21545b08a@haskell.org> Message-ID: <061.4247ca6ef44aa76d48d1b37df3497472@haskell.org> #11698: GHC's tct_closed flag is not being set correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11656 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): The definition reads {{{ Definition: A variable is "closed", and has tct_closed set to TopLevel, iff a) all its free variables are imported, or are let-bound with closed types b) generalisation is not restricted by the monomorphism restriction }}} I suppose that (a) should read instead: {{{ a) all its free variables are imported, or are let-bound and closed. }}} i.e. not only the type must be closed, the defining term should be as well. If closed types are required for a binding to be closed, then a new item (c) should be added asking for it, unless (a) implies that somehow: {{{ Definition: A variable is "closed", and has tct_closed set to TopLevel, iff a) all its free variables are imported, or are let-bound and closed b) generalisation is not restricted by the monomorphism restriction c) it has a closed type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 14:51:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 14:51:02 -0000 Subject: [GHC] #11699: Type families mistakingly report kind variables as unbound type variables Message-ID: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> #11699: Type families mistakingly report kind variables as unbound type variables -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC verifies that if some equation of a type family binds a type variable, that this type variable actually exists and doesn't disappear through type synonym/family application (#7536). However this also mistakingly catches kind variables that aren't present in the type family head. Simplest test case: {{{#!hs {-# LANGUAGE TypeFamilies, PolyKinds #-} type family F a where F (f a) = f a }}} As seen on 8.0.1-rc2 and 7.10.2: {{{ ../File.hs:3:23: Family instance purports to bind type variable ?k1? but the real LHS (expanding synonyms) is: F (f a) = ... In the equations for closed type family ?F? In the type family declaration for ?F? }}} The culprit seems to be in `exactTyCoVarsOfType`, which doesn't grab kind variables from a type variable's kind, even though `tyCoVarsOfType` does. Now, I'm not too sure whether this is a "GHC rejects valid program", or "Incorrect warning at compile time", as I'm not sure if type families like the aforementioned `F` are actually okay. (Are they?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 15:17:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 15:17:58 -0000 Subject: [GHC] #9887: No message when GHCi reusing compiled code In-Reply-To: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> References: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> Message-ID: <060.354f4b0b8111f35f5c3042bd789f71da@haskell.org> #9887: No message when GHCi reusing compiled code -------------------------------------+------------------------------------- Reporter: jsrice | Owner: lukyanov Type: feature request | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1991 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 15:18:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 15:18:31 -0000 Subject: [GHC] #11698: GHC's tct_closed flag is not being set correctly In-Reply-To: <046.7686f983b8149fd1d6dcacf21545b08a@haskell.org> References: <046.7686f983b8149fd1d6dcacf21545b08a@haskell.org> Message-ID: <061.da030444aae933de78af6581f6023f7f@haskell.org> #11698: GHC's tct_closed flag is not being set correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11656 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes for (a). And (c) is implied by (a) and (b). Why? Assume (induction hypothesis) that closed variables have closed types, and that we have a new binding f = e, satisfying (a) and (b). Then since monomorphism restriction does not apply, and there are no free type variables, we can fully generalise, so its type will be closed. We should state that in the Note though -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 15:22:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 15:22:06 -0000 Subject: [GHC] #11699: Type families mistakingly report kind variables as unbound type variables In-Reply-To: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> References: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> Message-ID: <059.bbfb4c5652af2f06541ffed9a25b2a61@haskell.org> #11699: Type families mistakingly report kind variables as unbound type variables -------------------------------------+------------------------------------- Reporter: mniip | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => goldfire * keywords: => TypeInType * milestone: => 8.0.1 Comment: Richard, this doesn't look hard. I think the program itself is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 15:24:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 15:24:12 -0000 Subject: [GHC] #11699: Type families mistakingly report kind variables as unbound type variables In-Reply-To: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> References: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> Message-ID: <059.57d685a760e083a6fdb1f47990e2f5c1@haskell.org> #11699: Type families mistakingly report kind variables as unbound type variables -------------------------------------+------------------------------------- Reporter: mniip | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This one is actually already fixed in HEAD. I'll add the test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 15:53:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 15:53:17 -0000 Subject: [GHC] #11694: The function `lift'ghc: panic! (the 'impossible' happened) In-Reply-To: <048.525e6af3a4c4087bd326a138fab1eb31@haskell.org> References: <048.525e6af3a4c4087bd326a138fab1eb31@haskell.org> Message-ID: <063.df7be555b3cbe09aa7ec0064a4ac4643@haskell.org> #11694: The function `lift'ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Sventimir | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #11048 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #11048 * milestone: => 8.0.1 Comment: Indeed this appears to be fixed on the `ghc-8.0` branch. Thanks for reporting this, Sventimir! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 15:58:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 15:58:57 -0000 Subject: [GHC] #11699: Type families mistakingly report kind variables as unbound type variables In-Reply-To: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> References: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> Message-ID: <059.02a439af72f433cc5f5c22dbfedabe35@haskell.org> #11699: Type families mistakingly report kind variables as unbound type variables -------------------------------------+------------------------------------- Reporter: mniip | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Replying to [comment:1 simonpj]: > Richard, this doesn't look hard. > > I think the program itself is fine. So there are no issues with type family equations introducing new kind variables? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 17:35:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 17:35:36 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.4184483928bf91d665000f76a13448b1@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: closed => new * resolution: fixed => Comment: The ticket was for Mac OS X. We only solved the issue on Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 18:45:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 18:45:41 -0000 Subject: [GHC] #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel In-Reply-To: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> References: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> Message-ID: <059.25e29e9a59844eee5d791ae588a89f4a@haskell.org> #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: Bumping to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 21:25:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 21:25:47 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.2dad9698b2748236c6d37837a4330088@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: erikd Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9043 | Differential Rev(s): Phab:D1996 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => patch * differential: => Phab:D1996 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 22:01:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 22:01:50 -0000 Subject: [GHC] #11684: Fix tests with Clang In-Reply-To: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> References: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> Message-ID: <059.30ce098d350cd61741323edbe439ab20@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ?Phab:D1986 Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Turns out the warnings are coming from Clang when compiling an assembler file. The configure test therefore needs to test for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 22:24:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 22:24:02 -0000 Subject: [GHC] #11700: pattern match bug Message-ID: <050.22a2b2ee064f088d52261b2a9d8c72b0@haskell.org> #11700: pattern match bug -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: https://github.com/TobyGoodwin | /odd-ghc-pattern-bug | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With some types built by persistent-template, I'm running into very odd behaviour. Attempting to pull apart a tuple in one go... {{{#!hs let (Entity museKey muse, Entity msgKey msg, Entity fldrKey fldr) = cluster }}} fails (or rather, attempting to use msg or fldr fails) with errors like {{{ Couldn't match expected type ?Folder? with actual type ?Folder? }}} But splitting the pattern up: {{{#!hs let (a, b, c) = cluster Entity museKey muse = a Entity msgKey msg = b Entity fldrKey fldr = c }}} everything works normally Complete test case here: https://github.com/TobyGoodwin/odd-ghc-pattern- bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 22:55:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 22:55:16 -0000 Subject: [GHC] #11684: Fix tests with Clang In-Reply-To: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> References: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> Message-ID: <059.91315506d8776db9ec56bed351684f90@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ?Phab:D1986 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): That makes more sense. We can also just not pass those arguments when running the assembler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 23:18:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 23:18:01 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.6ad03fd4f58cf5f8a35bbc4435da4cd3@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by Sergei Trofimovich ): In [changeset:"e46742f5c51938bc7c992ac37fecc6df8cab7647/ghc" e46742f5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e46742f5c51938bc7c992ac37fecc6df8cab7647" rts: fix threadStackUnderflow type in cmm stg_stack_underflow_frame had an incorrect call of C function 'threadStackUnderflow': ("ptr" ret_off) = foreign "C" threadStackUnderflow( MyCapability(), CurrentTSO); Which means it's prototype is: void * (*) (W_, void*); While real prototype is: W_ (*) (Capability *cap, StgTSO *tso); The fix is simple. Fix type annotations: (ret_off) = foreign "C" threadStackUnderflow( MyCapability() "ptr", CurrentTSO "ptr"); Noticed when debugged T9045 test failure on m68k target which distincts between pointer and non pointer return types (uses different registers) While at it noticed and fixed return types for 'throwTo' and 'findSpark'. Trac #11395 Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 23:18:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 23:18:33 -0000 Subject: [GHC] #11701: ghc generates significant slower code Message-ID: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> #11701: ghc generates significant slower code -------------------------------------+------------------------------------- Reporter: HuStmpHrrr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: efficiency | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've already started a discussion here in SO: http://stackoverflow.com/questions/35941674/latest-ghc-generates-slower- code So again, I realized that the latest version of ghc produces significantly slower code than older version. my default ghc is the latest version as of now: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 }}} I have also two other old versions installed in my local machine. test code as following {{{#!hs import Data.Word import Data.List import System.Environment collatzNext :: Word32 -> Word32 collatzNext a = (if even a then a else 3*a+1) `div` 2 -- new code collatzLen :: Word32 -> Int collatzLen a0 = lenIterWhile collatzNext (/= 1) a0 lenIterWhile :: (a -> a) -> (a -> Bool) -> a -> Int lenIterWhile next notDone start = len start 0 where len n m = if notDone n then len (next n) (m+1) else m -- End of new code main = do [a0] <- getArgs let max_a0 = (read a0)::Word32 print $ maximum $ map (\a0 -> (collatzLen a0, a0)) [1..max_a0] }}} following are the three runs in my machine: {{{ $ ~/Tools/ghc-7.6.1/bin/ghc -O2 Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ time ./Test 1000000 (329,837799) real 0m1.901s user 0m1.896s sys 0m0.000s $ ~/Tools/ghc/bin/ghc -O2 Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ time ./Test 1000000 (329,837799) real 0m10.562s user 0m10.528s sys 0m0.036s $ ~/Tools/ghc-7.4.2/bin/ghc -O2 Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ time ./Test 1000000 (329,837799) real 0m1.879s user 0m1.876s sys 0m0.000s }}} Obviously we can tell latest version of ghc produces worse code than the older two versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 23:20:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 23:20:35 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.56453b6db1e6961cb34f1e4e2ebf0e40@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by slyfox): With changeset:e46742f5c51938bc7c992ac37fecc6df8cab7647 I can get ghci working \o/ {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20160305: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/slyfox/.ghci }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 23:22:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 23:22:35 -0000 Subject: [GHC] #11701: ghc generates significant slower code In-Reply-To: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> References: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> Message-ID: <064.14414ddd5256064f4d4ad174cae2467d@haskell.org> #11701: ghc generates significant slower code -------------------------------------+------------------------------------- Reporter: HuStmpHrrr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: efficiency Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by HuStmpHrrr): according to the investigation of Zeta in SO, it's because `even` is not inlined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 23:27:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 23:27:29 -0000 Subject: [GHC] #11684: Fix tests with Clang In-Reply-To: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> References: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> Message-ID: <059.4d6e3fe3aaf1b2230d4b7cc4652cb2c7@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ?Phab:D1986 Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Looking at `compiler/main/DriverPipeline.hs` now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 11 23:29:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Mar 2016 23:29:44 -0000 Subject: [GHC] #11684: Fix tests with Clang In-Reply-To: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> References: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> Message-ID: <059.3359586c73cda1eeeb56628366e310c5@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ?Phab:D1986 Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Interestingly, `DriverPipeline.hs` already optionally adds `-Qunused- arguments` when the compiler is Clang. For some reason, Debian's Clang is not being recognised as Clang. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 00:04:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 00:04:12 -0000 Subject: [GHC] #11701: ghc generates significant slower code In-Reply-To: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> References: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> Message-ID: <064.a27bdd1b5c33e377a7cce83378fbe14b@haskell.org> #11701: ghc generates significant slower code -------------------------------------+------------------------------------- Reporter: HuStmpHrrr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: efficiency Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Wow, indeed 7.10.3 chooses not to inline `even`. I've not looked into why but this is quite surprising. Inlining `even` produces a significant speedup (roughly a factor of five) as one would expect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 00:06:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 00:06:15 -0000 Subject: [GHC] #11701: ghc generates significant slower code In-Reply-To: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> References: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> Message-ID: <064.202042fe73384e17c5f209e09e4e8329@haskell.org> #11701: ghc generates significant slower code -------------------------------------+------------------------------------- Reporter: HuStmpHrrr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: efficiency Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, the problem appears to be that `GHC.Real.even` and `odd` are not marked as `INLINE` but rather are merely specialized to `Integer` and `Int`, whereas you use it at `Word32`. We should specialize these to these other types but it seems to me like they are cheap enough operations to be worth inlining. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 00:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 00:10:09 -0000 Subject: [GHC] #11701: ghc generates significant slower code In-Reply-To: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> References: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> Message-ID: <064.d94ef639aafe08eac2f72cd46bfdff15@haskell.org> #11701: ghc generates significant slower code -------------------------------------+------------------------------------- Reporter: HuStmpHrrr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: efficiency Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1997 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D1997 * milestone: => 8.0.1 Comment: I've opened Phab:D1997 to address this particular issue although I suspect we generally need to audit our use of inlining vs. specialization. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 00:16:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 00:16:03 -0000 Subject: [GHC] #11701: ghc generates significant slower code In-Reply-To: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> References: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> Message-ID: <064.297d654ff0f86c675d2167b82d813235@haskell.org> #11701: ghc generates significant slower code -------------------------------------+------------------------------------- Reporter: HuStmpHrrr | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: efficiency Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1997 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 00:16:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 00:16:52 -0000 Subject: [GHC] #11653: Emit timings for individual compiler passes (was: Time compiler passes) In-Reply-To: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> References: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> Message-ID: <061.af0fdc9dc8337fc9f08c57f51fa2b053@haskell.org> #11653: Emit timings for individual compiler passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1959 Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 00:17:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 00:17:22 -0000 Subject: [GHC] #11653: Emit timings for individual compiler passes In-Reply-To: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> References: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> Message-ID: <061.6694a01d9f5fb336155e0db056fd4faf@haskell.org> #11653: Emit timings for individual compiler passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1959 Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -2,1 +2,1 @@ - would produce timings of various phases of compilation. Even better, if + would produce timings of various phases of compilation. Even better, if it New description: It would be very useful for compiler performance analysis if the compiler would produce timings of various phases of compilation. Even better, if it could produce allocation numbers as well. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 00:24:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 00:24:16 -0000 Subject: [GHC] Batch modify: #8953, #10141, #10249, #10332, #10343, #10383, ... Message-ID: <20160312002416.49C2E3A2FF@ghc.haskell.org> Batch modification to #8953, #10141, #10249, #10332, #10343, #10383, #10431, #10506, #10770, #10830, #10878, #10915, #10962, #10972, #11096, #11457, #10582 by bgamari: milestone to 8.2.1 Comment: This bug won't be fixed in 8.0.1; bumping to 8.2. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 00:26:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 00:26:58 -0000 Subject: [GHC] #11681: ghc panic with TypeError In-Reply-To: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> References: <044.1648947b04b5a125b07a542edb5c7eb1@haskell.org> Message-ID: <059.b92f6a744503243835c27ca9015d8460@haskell.org> #11681: ghc panic with TypeError -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I observe the same error as simonpj describes in comment:7 on the `ghc-8.0` branch. I'm fairly confident that this is fixed; if you find that it is still reproducible with the next release candidate (which will likely come in the next week or so) feel free to re-open this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 00:28:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 00:28:10 -0000 Subject: [GHC] #11494: Add -Wcompat to -Wall In-Reply-To: <046.4883b5c7ccf037dba12555f655b97205@haskell.org> References: <046.4883b5c7ccf037dba12555f655b97205@haskell.org> Message-ID: <061.0b87ee4139c6c866610b33c3df8c8936@haskell.org> #11494: Add -Wcompat to -Wall -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings| #To-Wcompat-Wallornot11494 | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: We ultimately concluded that it would be best to keep these as two independent warning sets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 03:16:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 03:16:49 -0000 Subject: [GHC] #11699: Type families mistakingly report kind variables as unbound type variables In-Reply-To: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> References: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> Message-ID: <059.c2aafa9f06fe789008dae91b96437d4b@haskell.org> #11699: Type families mistakingly report kind variables as unbound type variables -------------------------------------+------------------------------------- Reporter: mniip | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): No issues. This was just a straightforward bug, as you pointed out. If you update to HEAD, your program should work fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 05:57:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 05:57:15 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.7fd54d4678980804d92bed31a7e5dbab@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by glaubitz): Replying to [comment:26 slyfox]: > With changeset:e46742f5c51938bc7c992ac37fecc6df8cab7647 I can get ghci working \o/ Whoa, congrats. That's very impressive. Can't wait to start bootstrapping ghc on m68k in Debian :). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 11:46:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 11:46:51 -0000 Subject: [GHC] #11684: Fix tests with Clang In-Reply-To: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> References: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> Message-ID: <059.132c58f80e3bdee1678707ef63bb475e@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ?Phab:D1986 Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): For some reaosn `DriverPiplelne.mkExtraObj` is calling `SysTools.runCc` directly, on assembly language files while most other assembly language files get passed through `DriverPiplelne.runPhase`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 15:45:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 15:45:20 -0000 Subject: [GHC] #11676: Preserve name of original function in worker name In-Reply-To: <046.9564de68fd6f249b5e9dd2c92248810c@haskell.org> References: <046.9564de68fd6f249b5e9dd2c92248810c@haskell.org> Message-ID: <061.abffbcdd5fa95822a1ef21a92e2220b7@haskell.org> #11676: Preserve name of original function in worker name -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1970 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4d791b4f77975422df38f6b43084008edd097f1b/ghc" 4d791b4f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4d791b4f77975422df38f6b43084008edd097f1b" Simplify: Make generated names more useful makeTrivial is responsible for concocting names during simplification. Previously, however, it would make no attempt to generate a name that might be useful to later readers of the resulting Core. Here we add a bit of state to SimplEnv: a finite depth stack of binders within which we are currently simplifying. We then derive generated binders from this context. See #11676. Open questions: * Is there a better way to accomplish this? * Is `maxContextDepth` too large/small? Test Plan: Validate, look at Core. Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: thomie, simonpj Differential Revision: https://phabricator.haskell.org/D1970 GHC Trac Issues: #11676 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 15:45:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 15:45:20 -0000 Subject: [GHC] #9887: No message when GHCi reusing compiled code In-Reply-To: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> References: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> Message-ID: <060.47a25d470a2cb18beaf8c9b9b85c34c2@haskell.org> #9887: No message when GHCi reusing compiled code -------------------------------------+------------------------------------- Reporter: jsrice | Owner: lukyanov Type: feature request | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1991 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"41051dd846c3a7fc01cbb8ad3b7dd2b4332f7f0b/ghc" 41051dd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="41051dd846c3a7fc01cbb8ad3b7dd2b4332f7f0b" ghci: add message when reusing compiled code #9887 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1991 GHC Trac Issues: #9887 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 15:45:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 15:45:20 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.fa53d68f351812a97c10a55f2a1efe9b@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: erikd Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9043 | Differential Rev(s): Phab:D1996 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"92821ec9a57817e1429ae94c756539259488b728/ghc" 92821ec9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="92821ec9a57817e1429ae94c756539259488b728" LlvmCodeGen: Fix generation of malformed LLVM blocks Commit 673efccb3b uncovered a bug in LLVM code generation that produced LLVM code that the LLVM compiler refused to compile: { clpH: br label %clpH } This may well be a bug in LLVM itself. The solution is to keep the existing entry label and rewrite the function as: { clpH: br label %nPV nPV: br label %nPV } Thanks to Ben Gamari for pointing me in the right direction on this one. Test Plan: Build GHC with BuildFlavour=quick-llvm Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1996 GHC Trac Issues: #11649 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 19:06:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 19:06:49 -0000 Subject: [GHC] #11598: Cache coercion kinds and roles In-Reply-To: <047.56bbfff0d86db02c37b25ddc698d48a1@haskell.org> References: <047.56bbfff0d86db02c37b25ddc698d48a1@haskell.org> Message-ID: <062.72db39df078e7a15080c993a6f1d27a7@haskell.org> #11598: Cache coercion kinds and roles -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8095 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * failure: None/Unknown => Compile-time performance bug * milestone: => 8.2.1 Comment: I have made a real solid attempt at this, but I am giving up for now. My work is [https://github.com/goldfirere/ghc/tree/cache-coercion-kind here] (the cache-coercion-kind tag on my github fork). The code there has a roughly 10% slowdown on most of the `perf/compiler` performance tests, along with more drastic slowdowns on the `T9872x` tests. (It has a 16% improvement on `T5030`, though.) It is unclear to me where the slowdown is coming from. I have explored T9872d in some detail, though. It is slowed by the fact that phantom coercions are not always made anymore by `mkPhantomCo`. They can now be `SubCo Phantom`, too. This leads to a ton of work zonking a coercion hole proving a phantom equality. But I suspect phantoms are rare, and so this is not the cause of the general slowdown. Unfortunately, because `PhantomProv` needs a ''kind'' coercion, we are required to have `coercionRepKind` (a function that calculates an uncached kind). This is doable, of course, but I'm wary of sinking more time into this. It's quite possible that savings are realized only in concert with #8095, but the hour is too late for that. Just to record some thoughts on #8095: That ticket proposes looking at every `mkTcXXXCo` call to see if `-dcore-lint` is set and to drop coercions if not. I now think this is the wrong approach. Instead, let's use laziness: we just have to be careful about when `coercionRep`s are forced. As long as we never force them, we'll never have to calculate them. We should, when convenient, replace the thunked coercions with `OmittedCo` or something. For example, during zonking and simplification. And we'll need to write `OmittedCo` to interface files. But it shouldn't be too bad. To pull this off, we'll have to cache a few more things than my work already does: specifically, we'll need to cache the set of tycons mentioned in a coercion and whether or not the coercion is reflexive. I'm also worried about `Rules.match_co` which examines the structure of a coercion, so we may need a bit of re-engineering around that. This is a welcome problem, though, because the fact that `match_co` looks at coercions is just awful. Bottom line: I'm punting to 8.2, and lowering my expectations for performance improvements that will go into 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 19:07:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 19:07:20 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.8d0409fcad69f12dc27d151dd2a93371@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321, #11598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): See comment:2:ticket:11598 for some thoughts on how to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 19:44:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 19:44:28 -0000 Subject: [GHC] #11702: Constant folding on 'mod/Word' - incorrect result Message-ID: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> #11702: Constant folding on 'mod/Word' - incorrect result -------------------------------------+------------------------------------- Reporter: ondrap | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling this with GHC 7.10.3 on both MacOS and Linux with '-O' producess results '5 0'. {{{#!hs module Main where testfn :: Word -> IO () testfn wseq = do print $ wseq `mod` 1 main = do testfn 5 print $ (5 :: Word) `mod` 1 }}} Changing type to Int produces correct result. It has probably something to do with compiler/prelude/PrelRules.hs - the rules for Int and Word differ. It seems to me that it should be optimized the same way, but the culprit seems to be the 'rightIdentityDynFlags onew' - that seems to be a clear bug (if it does what I think it does). {{{#!hs primOpRules nm IntRemOp = mkPrimOpRule nm 2 [ nonZeroLit 1 >> binaryLit (intOp2 rem) , leftZero zeroi , do l <- getLiteral 1 dflags <- getDynFlags guard (l == onei dflags) retLit zeroi , equalArgs >> retLit zeroi , equalArgs >> retLit zeroi ] primOpRules nm WordRemOp = mkPrimOpRule nm 2 [ nonZeroLit 1 >> binaryLit (wordOp2 rem) , rightIdentityDynFlags onew ] }}} I found it in different code where lots of inlining reduced some branch of code into this and produced wrong result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 21:47:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 21:47:33 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.d7b2d2cf0de44dc71e794d39083b3ed4@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: I've merged these to `ghc-8.0` as bd454972e94a639f57cf16a2d419e879f023e80e, 79737db203bed639c525861c5da57224ea663374, c769188ba88dc8e9011451170c58fdb5b03b4a35, f996692ed93c4d7744242a2212c2886359d29586. Thanks for your work! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 21:55:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 21:55:06 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.b48144770b27f93e7fc8458e3c6d6416@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: erikd Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9043 | Differential Rev(s): Phab:D1996 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 12 21:55:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Mar 2016 21:55:48 -0000 Subject: [GHC] #9887: No message when GHCi reusing compiled code In-Reply-To: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> References: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> Message-ID: <060.a261651e1c62919979fe689a857b3e53@haskell.org> #9887: No message when GHCi reusing compiled code -------------------------------------+------------------------------------- Reporter: jsrice | Owner: lukyanov Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.8.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1991 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Merged to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 13 02:40:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Mar 2016 02:40:50 -0000 Subject: [GHC] #11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics Message-ID: <051.d88b9387a728df13c9639e42ea307515@haskell.org> #11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: Segmentation | Operating System: Unknown/Multiple Fault, Generics, Runtime error | Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: attached | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Reproduced issue on both Windows-7/GHC-7.10.3 and Linux-4.1.15/GHC-7.8.4 Seems to probably be a problem with GHC.Generics and the runtime. Windows/GHC-7.10.3 states: internal error: evacuate: strange closure type 15 (GHC version 7.10.3 for x86_64_unkown_mingw32) Please report this as a GHC bug: httpL//www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Linux/GHC-7.8.4 states: Segmentation fault Behavior varies based on CSV input file size, a CSV file with header with 1 to 4 rows works. A CSV with a header and more than 10 rows segmentation faults imediatly. Inbetween 4 to 10 sometimes runs forever, works, or segmentation faults. The test case uses Cassava and GHC.Generics and some derived instances to read a CSV file with a record data type with many fields. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 13 02:41:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Mar 2016 02:41:43 -0000 Subject: [GHC] #11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics In-Reply-To: <051.d88b9387a728df13c9639e42ea307515@haskell.org> References: <051.d88b9387a728df13c9639e42ea307515@haskell.org> Message-ID: <066.ece893ea81beeaa027d7c4b619f57bcd@haskell.org> #11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Segmentation | Fault, Generics, Runtime error Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: attached Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NathanWaivio): * Attachment "csv-test.hs" added. Code that causes problem -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 13 02:42:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Mar 2016 02:42:03 -0000 Subject: [GHC] #11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics In-Reply-To: <051.d88b9387a728df13c9639e42ea307515@haskell.org> References: <051.d88b9387a728df13c9639e42ea307515@haskell.org> Message-ID: <066.3ab7f946b81d3caa03c07cff5e27d392@haskell.org> #11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Segmentation | Fault, Generics, Runtime error Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: attached Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NathanWaivio): * Attachment "test-passes.csv" added. Input file that works -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 13 02:42:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Mar 2016 02:42:25 -0000 Subject: [GHC] #11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics In-Reply-To: <051.d88b9387a728df13c9639e42ea307515@haskell.org> References: <051.d88b9387a728df13c9639e42ea307515@haskell.org> Message-ID: <066.746b095d75c5681353b66e110cd24a65@haskell.org> #11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Segmentation | Fault, Generics, Runtime error Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: attached Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NathanWaivio): * Attachment "test-fails.csv" added. Input file that fails -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 13 04:01:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Mar 2016 04:01:44 -0000 Subject: [GHC] #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH In-Reply-To: <042.98f1e89f02393a599dc5a3ef57e2d85f@haskell.org> References: <042.98f1e89f02393a599dc5a3ef57e2d85f@haskell.org> Message-ID: <057.40055bdd29881f22c390d6f78289b495@haskell.org> #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH -------------------------------------+------------------------------------- Reporter: jme | Owner: jme Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2000 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jme): * status: new => patch * differential: => Phab:D2000 Comment: I've submitted a patch (Phab:D2000). I'm still not completely happy with the form of the new error message, since it states where an exact match to an out-of-scope variable is '''not''' in scope: {{{ T11680.hs:37:7: error: ? Variable not in scope: bar :: () ? ?bar? (line 82) is not in scope before the splice on lines 78-80 Perhaps you meant one of these: ?bat? (line 40), ?baz? (line 43) }}} But specifying where it '''is''' in scope would have been far wordier. If you think the extra detail would be more helpful to users, though, I'm happy to change it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 13 18:25:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Mar 2016 18:25:00 -0000 Subject: [GHC] #7198: New codegen more than doubles compile time of T3294 In-Reply-To: <047.96b5f0effd7d95ff044f855e6d48f3db@haskell.org> References: <047.96b5f0effd7d95ff044f855e6d48f3db@haskell.org> Message-ID: <062.4bd9018a48e417ab8568287cae38cdbf@haskell.org> #7198: New codegen more than doubles compile time of T3294 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michalt): This sounds interesting and I wanted to attempt to fix this. :-) I'm not very familiar with the code, so some help would be super useful. IIRC there are a few things happening here: - We have a bunch of nested `let`s that we could try to flatten based on a heuristic that considers how many free variables the `let` has. - We generate a lot of unnecessary code for copying the values from the stack to the heap (using local variables instead of assigning them directly). - The original description also mentions reloads for unused variables. But I'm not sure I understand what exactly is this referring to. (Some example would be nice!) Based on that I have a few questions on how to approach solving this: - What would be a good place in the code to consider flattening of `let`s? - What code is responsible for the unnecessary code for copying the values? It seems that this is would be the `StgCmm*` modules that compile STG to cmm, is that correct? Note: looking at Cmm when compiled with optimizations, it seems to me that the sinking pass is able to optimize the unnecessary copying of values through local variables (the assignment are of the form `F64[Hp - 312] = F64[Sp + 8];`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 13 18:25:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Mar 2016 18:25:40 -0000 Subject: [GHC] #7198: New codegen more than doubles compile time of T3294 In-Reply-To: <047.96b5f0effd7d95ff044f855e6d48f3db@haskell.org> References: <047.96b5f0effd7d95ff044f855e6d48f3db@haskell.org> Message-ID: <062.6fbef9b4969cbe64117e2978ad77fb32@haskell.org> #7198: New codegen more than doubles compile time of T3294 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 13 18:44:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Mar 2016 18:44:44 -0000 Subject: [GHC] #11704: Word and Int literals not correctly truncated when cross compiling 64 -> 32 bit Message-ID: <044.ef02078386f7a5f7e48e062dab051f3c@haskell.org> #11704: Word and Int literals not correctly truncated when cross compiling 64 -> 32 bit -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC does not take the target word size into account for some of the rules in `PrelRules`: {{{#!hs rule_convert "integerToWord" integerToWordName mkWordLitWord, rule_convert "integerToInt" integerToIntName mkIntLitInt, }}} The relevant code from `CoreSyn`: {{{#!hs -- | Create a machine word literal expression of type @Word#@ from a @Word at . -- If you want an expression of type @Word@ use 'MkCore.mkWordExpr' mkWordLitWord :: DynFlags -> Word -> Expr b mkWordLit dflags w = Lit (mkMachWord dflags w) mkWordLitWord dflags w = Lit (mkMachWord dflags (toInteger w)) -- | Create a machine integer literal expression of type @Int#@ from an @Int at . -- If you want an expression of type @Int@ use 'MkCore.mkIntExpr' mkIntLitInt :: DynFlags -> Int -> Expr b mkIntLitInt dflags n = Lit (mkMachInt dflags (toInteger n)) }}} If a literal is bigger than the target word size, these rules can lead to loss of truncation when optimizing a `fromInteger` / `toInteger` pair. This makes testcase `codeGen/5785.hs` fail when compiled with optimization with GHCJS on 64 bit GHC. It probably also affects targeting 64 platforms with 32 bit compilers, where literals would be truncated too much, but I don't have a way of testing that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 13 18:47:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Mar 2016 18:47:35 -0000 Subject: [GHC] #11704: Word and Int literals not correctly truncated when cross compiling 64 -> 32 bit In-Reply-To: <044.ef02078386f7a5f7e48e062dab051f3c@haskell.org> References: <044.ef02078386f7a5f7e48e062dab051f3c@haskell.org> Message-ID: <059.2b6cfbe9be3831660298c34f8b8fc0d4@haskell.org> #11704: Word and Int literals not correctly truncated when cross compiling 64 -> 32 bit -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Ericson2314): * cc: Ericson2314 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 13 19:29:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Mar 2016 19:29:37 -0000 Subject: [GHC] #11702: Constant folding on 'mod/Word' - incorrect result In-Reply-To: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> References: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> Message-ID: <060.1050570f08d92648f4fdcad0c7c0632b@haskell.org> #11702: Constant folding on 'mod/Word' - incorrect result -------------------------------------+------------------------------------- Reporter: ondrap | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Prelude | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest * milestone: => 8.0.1 Comment: Seems like this is something we should get on top of before 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 13 20:25:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Mar 2016 20:25:12 -0000 Subject: [GHC] #10162: Add unicode syntax for banana brackets In-Reply-To: <045.f7ad53896487f5f5496f96174e92dff7@haskell.org> References: <045.f7ad53896487f5f5496f96174e92dff7@haskell.org> Message-ID: <060.9943ef6159d2cb1b437b922bf723c77b@haskell.org> #10162: Add unicode syntax for banana brackets -------------------------------------+------------------------------------- Reporter: zardoz | Owner: JoshPrice247 Type: feature request | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.8.4 (Parser) | Keywords: unicode, Resolution: | UnicodeSyntax, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by JoshPrice247): * owner: => JoshPrice247 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 13 21:46:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Mar 2016 21:46:57 -0000 Subject: [GHC] #11705: Back port of LlvmCodeGen fix broke 8.0 Message-ID: <044.692f0302bfed2c31f2458fa1392cbc8b@haskell.org> #11705: Back port of LlvmCodeGen fix broke 8.0 -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit 1e7764ce in the ghc-8.0 branch (back ported from master) fails to compile because it assumes the prelude of ghc-7.10. Specifically: {{{ compiler/llvmGen/LlvmCodeGen.hs:131:12: Not in scope: ?pure? compiler/llvmGen/LlvmCodeGen.hs:140:34: Not in scope: ?<$>? Perhaps you meant one of these: ?<+>? (imported from Outputable), ?<>? (imported from Outputable) }}} etc. The fix should be pretty trivial. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 13 22:19:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Mar 2016 22:19:11 -0000 Subject: [GHC] #11705: Back port of LlvmCodeGen fix broke 8.0 In-Reply-To: <044.692f0302bfed2c31f2458fa1392cbc8b@haskell.org> References: <044.692f0302bfed2c31f2458fa1392cbc8b@haskell.org> Message-ID: <059.3200e7f9065dee3f32728781381f20e0@haskell.org> #11705: Back port of LlvmCodeGen fix broke 8.0 -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2003 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => patch * differential: => Phab:D2003 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 00:40:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 00:40:19 -0000 Subject: [GHC] #11706: Increase precedence of statements (if-then-else, case-of, do) Message-ID: <048.963578de7c77f87376af43ef595e0d3d@haskell.org> #11706: Increase precedence of statements (if-then-else, case-of, do) -------------------------------------+------------------------------------- Reporter: YoYoYonnY | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: ? Component: Compiler | Version: (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Warning: Skip to the {{{TL; DR}}}, and maybe the {{{How it works}}} section; You don't want to read this. (I've warned you.) == The problem == We do it all the time: Writing that one dollar sign just before our expressions, just because Haskell can't parse it: {{{#!hs f x = g $ if x then {- ... -} else {- ... -} f x = g $ case x of {- ... -} f x = g $ do {- ... -} }}} However, we programmers are lazy and want to type as few characters as possible. Think about the precious characters we would save if we could write code this way: {{{#!hs f x = g if x then {- ... -} else {- ... -} f x = g case x of {- ... -} f x = g do {- ... -} }}} Wow, our productivity just shot up by a whopping 6%! However, this code looks ugly, noone would ever write this... Right? There has to be some way to catagorize this feature with others people would never use... == Pragmas to the rescue! == The {{{LANGUAGE}}} pragma! Of course! We can add a syntactic extension to enable above syntax! But how should we name it... {{{InlineStatements}}}? {{{InfixStatements}}}? {{{ParenthesizedStatements}}}? {{{IncreasedStatementPrecedence}}}? {{{StatementsWithoutParenthesis}}}? I don't know. I am [1] not the parents who might one day give birth to this feature. I am merely the one who conceptualized it. [1] (probably, unless this request remains unnoticed for another 20 years or so) == How it works == * Implicit parenthesis will be put around ''all'' statements, according to the following rules: 1. Parenthesis will be opened at the start of the statement. 2. Parenthesis will be closed at the end of the statement. The end of the statement is determined by 1. The curly brackets around the statement, or; 2. The indentation of the statement Basically, these are the rule Haskell already uses. Sorry if this is obvious, but some people seemed to get confused, so here's some examples: === (Correct) Examples === Examples are in the form: {{{#!hs implicitParenthesis -- New syntax explicitParenthesis -- Old syntax }}} Call {{{idM :: Monad m => m a -> m a}}} as {{{idM :: IO String -> IO String}}}. {{{#!hs idM do putStrLn "What's my name?" getLine idM (do { putStrLn "What's my name?"; getLine; }) }}} Create function {{{whatsMyName :: Maybe String -> String}}}. {{{#!hs whatsMyName x = id case x of Just name = "My name is " ++ name Nothing = "What's my name?" whatsMyName x = id (case x of { Just name = "My name is " ++ name; Nothing = "What's my name?"; }) }}} Another example using {{{let}}} and {{{if-then-else}}}. {{{#!hs main = putStrLn (++) "I've been tryna work it out... The square root of 69 is 8 something, right? " let eight_something = 8.306623862918075 in if sqrt 69 == eight_something then "Yeah" else "Oh na na" main = putStrLn ((++) "I've been tryna work it out... The square root of 69 is 8 something, right? " (let eight_something = 8.306623862918075 in (if sqrt 69 == eight_something then "Yeah" else "Oh na na")) }}} === Incorrect examples === {{{#!hs f do putStrLn "This won't work..." True f (do { putStrLn "This won't work..."; True; }) }}} {{{#!hs f do putStrLn "This won't work..." True -- Indented by extra space f (do { putStrLn "This won't work..."; True; }) }}} == TL; DR == What there is: {{{#!hs main = when $ do putStrLn "Parenthesis..." main = when True (do putStrLn "Parenthesis...") }}} What I want: {{{#!hs when (doBlocksNeedParenthesis) do putStrLn "This code is invalid." when (doBlocksNeedParenthesis) $ do putStrLn "This code is valid." when (doBlocksNeedParenthesis) (do putStrLn "This code is valid aswell.") when (thisIsImplemented) do putStrLn "These are all equal" when (thisIsImplemented) (do putStrLn "These are all equal") when (thisIsImplemented) $ do putStrLn "These are all equal" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 09:31:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 09:31:22 -0000 Subject: [GHC] #11701: ghc generates significant slower code In-Reply-To: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> References: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> Message-ID: <064.743d2186b8b8cb3dbc19cec4d72b811b@haskell.org> #11701: ghc generates significant slower code -------------------------------------+------------------------------------- Reporter: HuStmpHrrr | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: efficiency Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1997 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): A factor of 5 is an impressively big loss from failing to inline `even`! I think we should investigate why it ''isn't'' being inlined automatically. I tried a tiny case: {{{ module Foo where even :: (Integral a) => a -> Bool even n = n `rem` 2 == 0 module Bar where import Foo f :: Int -> Bool f x = Foo.even x }}} Sure enough, `even` is not inlined. With `-dverbose-core2core -ddump- inlinings` we get {{{ Considering inlining: even arg infos [ValueArg, TrivArg] interesting continuation BoringCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [60 0] 240 0 discounted size = 120 ANSWER = NO }}} So we are only getting a tiny discount from the fact that we are giving a completely fixed dictionary to `even`; even though `even`'s body is dominated by dictionary selections that would disappear if we inlined `even`. So maybe we should look at our discounting scheme. See `CoreUnfold.classOpSize` and `ufDictDiscount` in particular. But there's a bit more to it than that. Here's the unfolding for `even`: {{{ Unfolding: (\ @ a ($dIntegral :: Integral a) (eta :: a) -> let { $dReal :: Real a = $p1Integral @ a $dIntegral } in let { $dNum :: Num a = $p1Real @ a $dReal } in == @ a ($p1Ord @ a ($p2Real @ a $dReal)) (rem @ a $dIntegral eta (fromInteger @ a $dNum even2)) (fromInteger @ a $dNum even1)) -} }}} The original argument is `$dIntegral` and only two of the seven dictionary-selection operations are applied to that argument; and only they attract discounts. Food for thought here. This function ''obviously'' should be inlined (when applied to a particular fixed dictionary) but it's not quite clear how to make that happen. Making it INLINEABLE, as the patch does, makes it specialisable which is good. Then it becomes small, and then it gets inlined. That path works quite well. Maybe all overloaded functions, perhaps up to some size limit, should automatically be INLINEABLE. Food for thought Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 09:52:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 09:52:47 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.f4cbb5fb10e86286ef00925164e58090@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:19 goldfire]: > Can we somehow tell the testsuite to skip this one in this scenario until we have a better workaround? Add the following [wiki:Building/RunningTests/Adding#Thesetupfield setup function] to the test definition in `all.T`: {{{ when(compiler_debugged(), skip) }}} I made that change in 49c55e68aae9841c166430ae566b0d9bdc03c99d. You might need a `git pull`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 10:05:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 10:05:21 -0000 Subject: [GHC] #11706: Increase precedence of statements (if-then-else, case-of, do) In-Reply-To: <048.963578de7c77f87376af43ef595e0d3d@haskell.org> References: <048.963578de7c77f87376af43ef595e0d3d@haskell.org> Message-ID: <063.b3080f3d91a8c8b31abd6a708ffadc65@haskell.org> #11706: Increase precedence of statements (if-then-else, case-of, do) -------------------------------------+------------------------------------- Reporter: YoYoYonnY | Owner: Type: feature request | Status: infoneeded Priority: lowest | Milestone: ? Component: Compiler | Version: (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Thanks for writing this up. Indeed you are not the first one to propose some variant on this idea (see, e.g., #10843). Not so long ago there was a rather lengthy discussion on this matter, which I summarized in ticket:10843#comment:12. I'll admit that don't believe that too-many-dollar-signs is the greatest of our problems and am skeptical that this sort of pragma would pull its weight. That being said, I'm happy to help you work through the details of this proposal. To begin, I think we should clear up a few nits, * the definition of "statement" being used here contradicts that defined by the Report (which defines it as being a monadic action in a `do` block). The `if` and `case` constructs are merely parts of the expression grammar. * several of your examples use `=` to delimit the sides of a case branch where you likely meant `->`. * what about `let` expressions? It seems rather odd that they are excluded here. * lambdas are a bit different from the other constructs here, but still worth thinking about * how does the binding of these expressions compare with that of infix functions? For instance, what does `(+1) <$> do return 42` mean? Our grammar is already very complex; any proposal to add further complexity needs to be carefully specified. If you would like to see this feature (and think that your proposal differs significantly from that of #10843) could you start a Wiki page describing precisely how your proposed parsing scheme differs from that described in Report? Also, keep in mind that this may interact with other syntactic extensions; be sure to consider how these interactions may play out. I would guess that you want to start by looking at [[https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3|layout]] section. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 10:10:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 10:10:19 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.f29391c1a0313b208bc87361455ff343@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The `RuntimeRep` rework has been merged to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 10:11:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 10:11:13 -0000 Subject: [GHC] #11614: document TypeInType In-Reply-To: <047.1743dce4e41c34187f3120f682a53edd@haskell.org> References: <047.1743dce4e41c34187f3120f682a53edd@haskell.org> Message-ID: <062.523cceef304ad555db5aeccbf1349e07@haskell.org> #11614: document TypeInType -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1995 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1995 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 10:11:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 10:11:49 -0000 Subject: [GHC] #11642: Heterogeneous type equality evidence ignored In-Reply-To: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> References: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> Message-ID: <061.d7c410e5499b1619ca3ce44a5ca66f16@haskell.org> #11642: Heterogeneous type equality evidence ignored -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 10:12:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 10:12:44 -0000 Subject: [GHC] #11702: Constant folding on 'mod/Word' - incorrect result In-Reply-To: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> References: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> Message-ID: <060.0ef540a3b535388a32fcf94b45e8b4e7@haskell.org> #11702: Constant folding on 'mod/Word' - incorrect result -------------------------------------+------------------------------------- Reporter: ondrap | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Prelude | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 10:36:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 10:36:38 -0000 Subject: [GHC] #11702: Constant folding on 'mod/Word' - incorrect result In-Reply-To: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> References: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> Message-ID: <060.e36d754ce57b48271cb2f41ec9adc5e3@haskell.org> #11702: Constant folding on 'mod/Word' - incorrect result -------------------------------------+------------------------------------- Reporter: ondrap | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Prelude | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2004 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2004 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 10:42:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 10:42:05 -0000 Subject: [GHC] #11684: Fix tests with Clang In-Reply-To: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> References: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> Message-ID: <059.af4191510a3f88482f3423f6a5059017@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ?Phab:D1988 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * differential: ?Phab:D1986 => ?Phab:D1988 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 12:23:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 12:23:19 -0000 Subject: [GHC] #11702: Constant folding on 'mod/Word' - incorrect result In-Reply-To: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> References: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> Message-ID: <060.bd84767692e56a1b04b33345f3fd8adc@haskell.org> #11702: Constant folding on 'mod/Word' - incorrect result -------------------------------------+------------------------------------- Reporter: ondrap | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Prelude | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2004 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3f60ce8751c860a2bd0ddbe87429136a9d97449b/ghc" 3f60ce8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3f60ce8751c860a2bd0ddbe87429136a9d97449b" Add regression test for #11702 Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2002 GHC Trac Issues: #11702 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 14:48:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 14:48:32 -0000 Subject: [GHC] #11707: Don't desugar large lists with build Message-ID: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When looking at `T9661` I noticed that a massive list was being inlined into `listArray`, where foldr/build was being applied, turning a bunch of massive static data into a massive block of code. It seems likely that keeping this as static data would be preferable here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 14:55:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 14:55:38 -0000 Subject: [GHC] #11706: Increase precedence of lexps (if-then-else, case-of, do, lambda and let-in) (was: Increase precedence of statements (if-then-else, case-of, do)) In-Reply-To: <048.963578de7c77f87376af43ef595e0d3d@haskell.org> References: <048.963578de7c77f87376af43ef595e0d3d@haskell.org> Message-ID: <063.d91e40803f8b9a59e63dc8337940146b@haskell.org> #11706: Increase precedence of lexps (if-then-else, case-of, do, lambda and let-in) -------------------------------------+------------------------------------- Reporter: YoYoYonnY | Owner: Type: feature request | Status: infoneeded Priority: lowest | Milestone: ? Component: Compiler | Version: (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by YoYoYonnY: @@ -1,2 +1,1 @@ - Warning: Skip to the {{{TL; DR}}}, and maybe the {{{How it works}}} - section; You don't want to read this. (I've warned you.) + == Intro == @@ -4,41 +3,2 @@ - == The problem == - - We do it all the time: Writing that one dollar sign just before our - expressions, just because Haskell can't parse it: - - {{{#!hs - f x = g $ if x then {- ... -} else {- ... -} - f x = g $ case x of {- ... -} - f x = g $ do {- ... -} - }}} - - However, we programmers are lazy and want to type as few characters as - possible. Think about the precious characters we would save if we could - write code this way: - - {{{#!hs - f x = g if x then {- ... -} else {- ... -} - f x = g case x of {- ... -} - f x = g do {- ... -} - }}} - - Wow, our productivity just shot up by a whopping 6%! - - However, this code looks ugly, noone would ever write this... Right? - There has to be some way to catagorize this feature with others people - would never use... - - == Pragmas to the rescue! == - - The {{{LANGUAGE}}} pragma! Of course! We can add a syntactic extension to - enable above syntax! But how should we name it... - - {{{InlineStatements}}}? {{{InfixStatements}}}? - {{{ParenthesizedStatements}}}? {{{IncreasedStatementPrecedence}}}? - {{{StatementsWithoutParenthesis}}}? - - I don't know. I am [1] not the parents who might one day give birth to - this feature. I am merely the one who conceptualized it. - - [1] (probably, unless this request remains unnoticed for another 20 years - or so) + For readability, the intro is now available [http://pastebin.com/8Fsh7pAE + here]. @@ -48,1 +8,1 @@ - * Implicit parenthesis will be put around ''all'' statements, according + * Implicit parenthesis will be put around ''all'' {{{lexps}}}, according @@ -50,5 +10,5 @@ - 1. Parenthesis will be opened at the start of the statement. - 2. Parenthesis will be closed at the end of the statement. The end of - the statement is determined by - 1. The curly brackets around the statement, or; - 2. The indentation of the statement + 1. Parenthesis will be opened at the start of the {{{lexp}}}. + 2. Parenthesis will be closed at the end of the {{{lexp}}}. The end of + the {{{lexp}}} is determined by + 1. The curly brackets around the {{{lexp}}} (If possible), or; + 2. The indentation of the {{{lexp}}} @@ -58,2 +18,5 @@ - Sorry if this is obvious, but some people seemed to get confused, so - here's some examples: + As for the Context-Free Syntax found at + https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3|layout, + {{{lexp}}} would have to be moved up, dropped out of {{{infixexp}}}, and + added into {{{exp}}} (As well as a few other places in {{{aexp}}} and + {{{guard}}}) @@ -61,1 +24,1 @@ - === (Correct) Examples === + == Motivation == @@ -63,1 +26,2 @@ - Examples are in the form: + As for my personal motivation, I think that, with all the other syntactic + extensions already implemented, this feature is definitly missing. @@ -65,2 +29,4 @@ - {{{#!hs - implicitParenthesis -- New syntax + As Richard Eisenberg already pointed out (See + [https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12 in this + comment]); combining {{{lexp}}} with {{{aexp}}} would make the Haskell + syntax more consistent. @@ -68,2 +34,2 @@ - explicitParenthesis -- Old syntax - }}} + bgamari listed above argument and quite a few other pros and cons + [https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12 here]. @@ -71,2 +37,1 @@ - Call {{{idM :: Monad m => m a -> m a}}} as {{{idM :: IO String -> IO - String}}}. + A few arguments not listed there: @@ -74,4 +39,8 @@ - {{{#!hs - idM do - putStrLn "What's my name?" - getLine + * If the Haskell community ever decides to implement this feature in the + main language, we will already be prepared. + * Similairly, if this feature ever gives problems or adds new interesting + possibilities to the language, we will be prepared. + * Yet another syntactical extension means yet another thing to look out + for; + * However, this also means people will become more aware of LANGUAGE + pragmas. @@ -79,2 +48,1 @@ - idM (do { putStrLn "What's my name?"; getLine; }) - }}} + == Naming == @@ -82,1 +50,1 @@ - Create function {{{whatsMyName :: Maybe String -> String}}}. + Here follow a few suggestions for the name of this extension: @@ -84,4 +52,5 @@ - {{{#!hs - whatsMyName x = id case x of - Just name = "My name is " ++ name - Nothing = "What's my name?" + * InlineStatements + * InfixStatements + * ParenthesizedStatements + * IncreasedStatementPrecedence + * StatementsWithoutParenthesis @@ -89,3 +58,2 @@ - whatsMyName x = id (case x of { Just name = "My name is " ++ name; Nothing - = "What's my name?"; }) - }}} + Here are some more, taken from [https://mail.haskell.org/pipermail + /haskell-cafe/2015-September/121217.html over here]. @@ -93,1 +61,2 @@ - Another example using {{{let}}} and {{{if-then-else}}}. + * ArgumentBlock + * ArgumentDo @@ -95,10 +64,1 @@ - {{{#!hs - main = putStrLn - (++) - "I've been tryna work it out... The square root of 69 is 8 - something, right? " - let - eight_something = 8.306623862918075 - in if sqrt 69 == eight_something - then "Yeah" - else "Oh na na" + == Examples == @@ -106,4 +66,1 @@ - main = putStrLn ((++) "I've been tryna work it out... The square root of - 69 is 8 something, right? " (let eight_something = 8.306623862918075 in - (if sqrt 69 == eight_something then "Yeah" else "Oh na na")) - }}} + Examples can now be found [http://pastebin.com/6kLQvKs9 here]. @@ -111,1 +68,1 @@ - === Incorrect examples === + == Resources == @@ -113,40 +70,6 @@ - {{{#!hs - f do - putStrLn "This won't work..." - True - - f (do { putStrLn "This won't work..."; True; }) - }}} - - {{{#!hs - f - do - putStrLn "This won't work..." - True -- Indented by extra space - - f (do { putStrLn "This won't work..."; True; }) - }}} - - == TL; DR == - - What there is: - - {{{#!hs - - main = when $ do putStrLn "Parenthesis..." - main = when True (do putStrLn "Parenthesis...") - - }}} - - What I want: - - {{{#!hs - - when (doBlocksNeedParenthesis) do putStrLn "This code is invalid." - when (doBlocksNeedParenthesis) $ do putStrLn "This code is valid." - when (doBlocksNeedParenthesis) (do putStrLn "This code is valid aswell.") - when (thisIsImplemented) do putStrLn "These are all equal" - when (thisIsImplemented) (do putStrLn "These are all equal") - when (thisIsImplemented) $ do putStrLn "These are all equal" - - }}} + [1] Cheesy intro: http://pastebin.com/8Fsh7pAE + [2] Original examples: [http://pastebin.com/6kLQvKs9] + [3] Pros and Cons: + [https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12] + [4] ArgumentBlock proposal: [https://mail.haskell.org/pipermail/haskell- + cafe/2015-September/121217.html] New description: == Intro == For readability, the intro is now available [http://pastebin.com/8Fsh7pAE here]. == How it works == * Implicit parenthesis will be put around ''all'' {{{lexps}}}, according to the following rules: 1. Parenthesis will be opened at the start of the {{{lexp}}}. 2. Parenthesis will be closed at the end of the {{{lexp}}}. The end of the {{{lexp}}} is determined by 1. The curly brackets around the {{{lexp}}} (If possible), or; 2. The indentation of the {{{lexp}}} Basically, these are the rule Haskell already uses. As for the Context-Free Syntax found at https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3|layout, {{{lexp}}} would have to be moved up, dropped out of {{{infixexp}}}, and added into {{{exp}}} (As well as a few other places in {{{aexp}}} and {{{guard}}}) == Motivation == As for my personal motivation, I think that, with all the other syntactic extensions already implemented, this feature is definitly missing. As Richard Eisenberg already pointed out (See [https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12 in this comment]); combining {{{lexp}}} with {{{aexp}}} would make the Haskell syntax more consistent. bgamari listed above argument and quite a few other pros and cons [https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12 here]. A few arguments not listed there: * If the Haskell community ever decides to implement this feature in the main language, we will already be prepared. * Similairly, if this feature ever gives problems or adds new interesting possibilities to the language, we will be prepared. * Yet another syntactical extension means yet another thing to look out for; * However, this also means people will become more aware of LANGUAGE pragmas. == Naming == Here follow a few suggestions for the name of this extension: * InlineStatements * InfixStatements * ParenthesizedStatements * IncreasedStatementPrecedence * StatementsWithoutParenthesis Here are some more, taken from [https://mail.haskell.org/pipermail /haskell-cafe/2015-September/121217.html over here]. * ArgumentBlock * ArgumentDo == Examples == Examples can now be found [http://pastebin.com/6kLQvKs9 here]. == Resources == [1] Cheesy intro: http://pastebin.com/8Fsh7pAE [2] Original examples: [http://pastebin.com/6kLQvKs9] [3] Pros and Cons: [https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12] [4] ArgumentBlock proposal: [https://mail.haskell.org/pipermail/haskell- cafe/2015-September/121217.html] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 14:57:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 14:57:09 -0000 Subject: [GHC] #11706: Increase precedence of lexps (if-then-else, case-of, do, lambda and let-in) In-Reply-To: <048.963578de7c77f87376af43ef595e0d3d@haskell.org> References: <048.963578de7c77f87376af43ef595e0d3d@haskell.org> Message-ID: <063.c008027c4cae386b55a88ca1dd251863@haskell.org> #11706: Increase precedence of lexps (if-then-else, case-of, do, lambda and let-in) -------------------------------------+------------------------------------- Reporter: YoYoYonnY | Owner: Type: feature request | Status: infoneeded Priority: lowest | Milestone: ? Component: Compiler | Version: (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by YoYoYonnY): Thanks for linking that ticket, I skimmed over the list of feature requests, but could not find any other requests asking for increased {{{lexp}}} precedence or similair. I suppose I underestimated the priority of this feature request. The typos in the ticket should now be fixed. The ticket is also simplified, the old code examples have been moved to Pastebin [http://pastebin.com/6kLQvKs9 here] (As a permament paste) for readability, and the cheesy intro has been moved to a separate Pastebin too, [http://pastebin.com/8Fsh7pAE here], to save a few clicks. I'll work on making more clean and general examples. I have to say that I agree; the proposal is mostly useless, one or two characters saved won't make a big difference. However, with other similair pragmas already implemented (UnicodeSyntax, RecordWildCards and TupleSections to name a few) I think it is reasonable to implement this feature somewhere in the future, be it with low priority. I think it is fair to refer to {{{if-then-else}}}, {{{case-of}}}, {{{do}}}, {{{lambda}}} and {{{let-in}}} as {{{lexp}}}, following https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3|layout, unless of course someone can think of a better term. The set of {{{lexp}}}s could of course also easily be extended with {{{lambda-case}}} and {{{mdo}}} (If this is not already the case). I have added {{{lambda}}} and {{{let-in}}} to the title, as these are part of the proposal. I've also added {{{lambda}}} to the examples, aswell as {{{lambda-case}}}, {{{mdo}}} and infix ones. I will leave the creation of a Wiki up to someone with more experience with the GHC Parser, although I might look into it myself sometime soon. As to if this ticket is diferentiatable from [https://ghc.haskell.org/trac/ghc/ticket/10843 #10843], I would say yes, this ticket is more general, however I would strongly recommend merging this ticket with [https://ghc.haskell.org/trac/ghc/ticket/10843 #10843], if that is in any way possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 15:09:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 15:09:48 -0000 Subject: [GHC] #11706: Increase precedence of lexps (if-then-else, case-of, do, lambda and let-in) In-Reply-To: <048.963578de7c77f87376af43ef595e0d3d@haskell.org> References: <048.963578de7c77f87376af43ef595e0d3d@haskell.org> Message-ID: <063.2d86f8779892737391a5d9f02aa359d8@haskell.org> #11706: Increase precedence of lexps (if-then-else, case-of, do, lambda and let-in) -------------------------------------+------------------------------------- Reporter: YoYoYonnY | Owner: Type: feature request | Status: infoneeded Priority: lowest | Milestone: ? Component: Compiler | Version: (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by YoYoYonnY: @@ -16,1 +16,1 @@ - Basically, these are the rule Haskell already uses. + Basically, these are the rules Haskell already uses. @@ -30,3 +30,3 @@ - [https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12 in this - comment]); combining {{{lexp}}} with {{{aexp}}} would make the Haskell - syntax more consistent. + [https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12 this comment]); + combining {{{lexp}}} with {{{aexp}}} would make the Haskell syntax more + consistent. @@ -71,0 +71,1 @@ + @@ -72,0 +73,1 @@ + @@ -74,0 +76,1 @@ + New description: == Intro == For readability, the intro is now available [http://pastebin.com/8Fsh7pAE here]. == How it works == * Implicit parenthesis will be put around ''all'' {{{lexps}}}, according to the following rules: 1. Parenthesis will be opened at the start of the {{{lexp}}}. 2. Parenthesis will be closed at the end of the {{{lexp}}}. The end of the {{{lexp}}} is determined by 1. The curly brackets around the {{{lexp}}} (If possible), or; 2. The indentation of the {{{lexp}}} Basically, these are the rules Haskell already uses. As for the Context-Free Syntax found at https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3|layout, {{{lexp}}} would have to be moved up, dropped out of {{{infixexp}}}, and added into {{{exp}}} (As well as a few other places in {{{aexp}}} and {{{guard}}}) == Motivation == As for my personal motivation, I think that, with all the other syntactic extensions already implemented, this feature is definitly missing. As Richard Eisenberg already pointed out (See [https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12 this comment]); combining {{{lexp}}} with {{{aexp}}} would make the Haskell syntax more consistent. bgamari listed above argument and quite a few other pros and cons [https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12 here]. A few arguments not listed there: * If the Haskell community ever decides to implement this feature in the main language, we will already be prepared. * Similairly, if this feature ever gives problems or adds new interesting possibilities to the language, we will be prepared. * Yet another syntactical extension means yet another thing to look out for; * However, this also means people will become more aware of LANGUAGE pragmas. == Naming == Here follow a few suggestions for the name of this extension: * InlineStatements * InfixStatements * ParenthesizedStatements * IncreasedStatementPrecedence * StatementsWithoutParenthesis Here are some more, taken from [https://mail.haskell.org/pipermail /haskell-cafe/2015-September/121217.html over here]. * ArgumentBlock * ArgumentDo == Examples == Examples can now be found [http://pastebin.com/6kLQvKs9 here]. == Resources == [1] Cheesy intro: http://pastebin.com/8Fsh7pAE [2] Original examples: [http://pastebin.com/6kLQvKs9] [3] Pros and Cons: [https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12] [4] ArgumentBlock proposal: [https://mail.haskell.org/pipermail/haskell- cafe/2015-September/121217.html] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 18:20:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 18:20:33 -0000 Subject: [GHC] #11705: Back port of LlvmCodeGen fix broke 8.0 In-Reply-To: <044.692f0302bfed2c31f2458fa1392cbc8b@haskell.org> References: <044.692f0302bfed2c31f2458fa1392cbc8b@haskell.org> Message-ID: <059.db2322d88de360df3797269b095ae5f1@haskell.org> #11705: Back port of LlvmCodeGen fix broke 8.0 -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2003 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: patch => closed * resolution: => fixed Comment: This patch has been applied to the `ghc-8.0` branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 20:13:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 20:13:20 -0000 Subject: [GHC] #11698: GHC's tct_closed flag is not being set correctly In-Reply-To: <046.7686f983b8149fd1d6dcacf21545b08a@haskell.org> References: <046.7686f983b8149fd1d6dcacf21545b08a@haskell.org> Message-ID: <061.59dc98eeee10536536eae059214664d2@haskell.org> #11698: GHC's tct_closed flag is not being set correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11656 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I can think of two ways to compute closedness. 1. Attach the free variables computed during the renaming pass to each binding. During type-checking, use these and the type of the binding to determine if it is closed. 2. Compute the free variables during type-checking and determine closedness from these alone. Is it (1) ok? Maybe it is more convenient than (2)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 22:15:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 22:15:19 -0000 Subject: [GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc) In-Reply-To: <045.274c910606d60239cadf6f398a2dd711@haskell.org> References: <045.274c910606d60239cadf6f398a2dd711@haskell.org> Message-ID: <060.34b338f48cf896c536ae270fbce46055@haskell.org> #11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: jme Type: bug | Status: patch Priority: high | Milestone: Component: Profiling | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | perf/space_leaks/space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2005 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jme): * status: new => patch * differential: => Phab:D2005 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 14 23:15:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Mar 2016 23:15:35 -0000 Subject: [GHC] #11698: GHC's tct_closed flag is not being set correctly In-Reply-To: <046.7686f983b8149fd1d6dcacf21545b08a@haskell.org> References: <046.7686f983b8149fd1d6dcacf21545b08a@haskell.org> Message-ID: <061.4568224662be97f681be3c0cc982cf43@haskell.org> #11698: GHC's tct_closed flag is not being set correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11656 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, (1) already happens. The annoying thing is plumbing the info to `tcExtendLetEnv`. Note that `TcBinds.decideGeneralisationPlan` already computes the closed- ness flag, at least for the `InferGen` case; it would be annoying to compute it twice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 00:57:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 00:57:02 -0000 Subject: [GHC] #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on Message-ID: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: kcsongor Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: typefamilies | Operating System: Unknown/Multiple trace hangs | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the following code, which is supposed to fail with a type error. However, when compiled with HEAD using the -ddump-tc-trace flag, the type checker hangs. {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} module Test where import Data.Proxy test :: (IsElem a as ~ 'True) => Proxy a -> Proxy as -> Bool test _ _ = True x = test (Proxy :: Proxy Int) (Proxy :: Proxy '[]) type family IsElem (x :: k) (xs :: [k]) where IsElem x '[] = 'False IsElem x (x ': xs) = 'True IsElem x (y ': xs) = IsElem x xs }}} The reason is that in typecheck/TcHsType.hs, the type family tycons are type-checked with knot-tying, however, they are being traced, forcing their evaluation which causes the typechecker to hang. My proposed fix is to only print the safe values that we know are constructed by the time of tracing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 00:58:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 00:58:10 -0000 Subject: [GHC] #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on In-Reply-To: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> References: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> Message-ID: <062.b2782080abc7e339bd78facac5dd32d1@haskell.org> #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: kcsongor Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: typefamilies Resolution: | trace hangs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kcsongor): * Attachment "TypeFamilyErrors_4.hs" added. Relevant file to reproduce the issue -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:02:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:02:01 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.6e45f2a67a470e72e0109717c7633b3f@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): @thomie: Great -- thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:50:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:50:22 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.99772a0ea684aaf3bda244ccbdbe6e10@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"84c773e1bc5c551b0f922c6fe9c70762d184a394/ghc" 84c773e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="84c773e1bc5c551b0f922c6fe9c70762d184a394" Fix #11334. Now we fail when trying to default non-*-kinded kind variables with -XNoPolyKinds. test case: dependent/should_fail/T11334 [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:50:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:50:22 -0000 Subject: [GHC] #11407: -XTypeInType uses up all memory when used in data family instance In-Reply-To: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> References: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> Message-ID: <065.f12a9f06caada09e20812dedca5049c2@haskell.org> #11407: -XTypeInType uses up all memory when used in data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e9bf7bb5cc9fb3f87dd05111aa23da76b86a8967/ghc" e9bf7bb5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e9bf7bb5cc9fb3f87dd05111aa23da76b86a8967" Fix #11407. This removes the `defer_me` check that was in checkTauTvUpdate and uses only a type family check instead. The old defer_me check repeated work done by fast_check in occurCheckExpand. There is also some error message improvement, necessitated by the terrible error message that the test case produced, even when it didn't consume all of memory. test case: dependent/should_fail/T11407 [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:50:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:50:22 -0000 Subject: [GHC] #11329: Visible type applications: failing tests with WAY=hpc In-Reply-To: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> References: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> Message-ID: <060.b38b59518b2bcd8992f096ba69cb4aef@haskell.org> #11329: Visible type applications: failing tests with WAY=hpc -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/VtaParse | typecheck/should_compile/Vta1 | typecheck/should_compile/Vta2 Blocked By: | Blocking: Related Tickets: #11456 | Differential Rev(s): Phab:D1824 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"972730cc42a419b8cd148abaa927e03415da3a68/ghc" 972730c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="972730cc42a419b8cd148abaa927e03415da3a68" Refactor visible type application. This replaces the old HsType and HsTypeOut constructors with HsAppType and HsAppTypeOut, leading to some simplification. (This refactoring addresses #11329.) This also fixes #11456, which stumbled over HsType (which is not an expression). test case: ghci/scripts/T11456 [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:50:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:50:22 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic In-Reply-To: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> References: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> Message-ID: <066.87176bea102117bea8d527d67547119f@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11329 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"972730cc42a419b8cd148abaa927e03415da3a68/ghc" 972730c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="972730cc42a419b8cd148abaa927e03415da3a68" Refactor visible type application. This replaces the old HsType and HsTypeOut constructors with HsAppType and HsAppTypeOut, leading to some simplification. (This refactoring addresses #11329.) This also fixes #11456, which stumbled over HsType (which is not an expression). test case: ghci/scripts/T11456 [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:50:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:50:22 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.12f4023f83961c3f34edbb969c1aec15@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11523 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"35d37ff8a0bb9f64f347c8e4b6a24d49fd08c9dc/ghc" 35d37ff8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="35d37ff8a0bb9f64f347c8e4b6a24d49fd08c9dc" Fix #11401. This commit teaches shortCutReduction about Derived constraints. [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:50:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:50:22 -0000 Subject: [GHC] #11614: document TypeInType In-Reply-To: <047.1743dce4e41c34187f3120f682a53edd@haskell.org> References: <047.1743dce4e41c34187f3120f682a53edd@haskell.org> Message-ID: <062.8c17af62d16fdb7cd8b72479622fbbfa@haskell.org> #11614: document TypeInType -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1995 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e7a8cb145c2450ae12abfb9e30a2b7c1544abf67/ghc" e7a8cb14/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e7a8cb145c2450ae12abfb9e30a2b7c1544abf67" Document TypeInType (#11614) [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:50:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:50:22 -0000 Subject: [GHC] #11699: Type families mistakingly report kind variables as unbound type variables In-Reply-To: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> References: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> Message-ID: <059.0004b272623d74e08eaa86a632bd1514@haskell.org> #11699: Type families mistakingly report kind variables as unbound type variables -------------------------------------+------------------------------------- Reporter: mniip | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"693b38cbf5cd298b793b3179fb6cc57e196b55d0/ghc" 693b38c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="693b38cbf5cd298b793b3179fb6cc57e196b55d0" Test case for #11699 in typecheck/should_compile [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:50:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:50:22 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.72e44d9c171098ad2b7dbe31ce6753ed@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"55577a9130738932d022d442d0773ffd79d0945d/ghc" 55577a9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="55577a9130738932d022d442d0773ffd79d0945d" Fix #11648. We now check that a CUSK is really a CUSK and issue an error if it isn't. This also involves more solving and zonking in kcHsTyVarBndrs, which was the outright bug reported in #11648. Test cases: polykinds/T11648{,b} This updates the haddock submodule. [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:52:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:52:40 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.16fb196d414e1ff5afd3950b137929c0@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | dependent/should_fail/T11334 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_fail/T11334 * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:53:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:53:30 -0000 Subject: [GHC] #11407: -XTypeInType uses up all memory when used in data family instance In-Reply-To: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> References: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> Message-ID: <065.6d8da0c10f9d73951c2faf83405e3612@haskell.org> #11407: -XTypeInType uses up all memory when used in data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | dependent/should_fail/T11407 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_fail/T11407 * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:54:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:54:14 -0000 Subject: [GHC] #11329: Visible type applications: failing tests with WAY=hpc In-Reply-To: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> References: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> Message-ID: <060.c68669f39eacb16c6a82e7faca99fc6b@haskell.org> #11329: Visible type applications: failing tests with WAY=hpc -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/VtaParse | typecheck/should_compile/Vta1 | typecheck/should_compile/Vta2 | ghci/scripts/T11456 Blocked By: | Blocking: Related Tickets: #11456 | Differential Rev(s): Phab:D1824 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: parser/should_compile/VtaParse typecheck/should_compile/Vta1 typecheck/should_compile/Vta2 => parser/should_compile/VtaParse typecheck/should_compile/Vta1 typecheck/should_compile/Vta2 ghci/scripts/T11456 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:55:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:55:06 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic In-Reply-To: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> References: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> Message-ID: <066.310cd68c51ee339d12309549c41309de@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T11456 Blocked By: | Blocking: Related Tickets: #11329 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => ghci/scripts/T11456 * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:56:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:56:42 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.14cdd9a15c445d838f6a70048cb3b709@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11401 Blocked By: | Blocking: Related Tickets: #11523 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compile/T11401 * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:57:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:57:20 -0000 Subject: [GHC] #11614: document TypeInType In-Reply-To: <047.1743dce4e41c34187f3120f682a53edd@haskell.org> References: <047.1743dce4e41c34187f3120f682a53edd@haskell.org> Message-ID: <062.c23a80b0f367751636007ad3b4eb4655@haskell.org> #11614: document TypeInType -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1995 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): More on the way, according to Phab:D1995. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:58:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:58:07 -0000 Subject: [GHC] #11699: Type families mistakingly report kind variables as unbound type variables In-Reply-To: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> References: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> Message-ID: <059.31fa185aed4857b052cb3e8b2c2e2d3c@haskell.org> #11699: Type families mistakingly report kind variables as unbound type variables -------------------------------------+------------------------------------- Reporter: mniip | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compiler/T11699 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compiler/T11699 * status: new => merge Comment: The only thing to merge here is the test cases, I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 03:59:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 03:59:22 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.671697ca4ff6ebe21127417b9b455895@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11648{,b} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => polykinds/T11648{,b} * status: new => merge Comment: This one was a bit more pervasive than I first thought to solve, but it probably should be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 04:03:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 04:03:13 -0000 Subject: [GHC] #11709: Merge some TypeInType fixes Message-ID: <047.8d0ecbfab650310ecba0e613108d8b2b@haskell.org> #11709: Merge some TypeInType fixes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are a few more commits to merge, that didn't fit with a single ticket: * de4df6b41a227f527e9eb77733cd6c87b069d3d0 * 3f5d1a13f112f34d992f6b74656d64d95a3f506d * 6c768fcf0d6749bf5029baf6b7f99271b48b1037 * 18fbfa39104b92a05061ec5f6f5bf3b84b462605 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 04:03:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 04:03:21 -0000 Subject: [GHC] #11709: Merge some TypeInType fixes In-Reply-To: <047.8d0ecbfab650310ecba0e613108d8b2b@haskell.org> References: <047.8d0ecbfab650310ecba0e613108d8b2b@haskell.org> Message-ID: <062.f6b444506e40cb9e0467a2d2ffc6ebe2@haskell.org> #11709: Merge some TypeInType fixes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 04:03:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 04:03:29 -0000 Subject: [GHC] #11709: Merge some TypeInType fixes In-Reply-To: <047.8d0ecbfab650310ecba0e613108d8b2b@haskell.org> References: <047.8d0ecbfab650310ecba0e613108d8b2b@haskell.org> Message-ID: <062.faf7966cf7c8ebd955d29de22ff48262@haskell.org> #11709: Merge some TypeInType fixes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 11:15:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 11:15:48 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.7d8a46133bf6974b85d1ead3b33d1dcf@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): There is currently a GHC flag which controls whether `build` desugaring is used at all, `-fsimple-list-literals`. To roughly characterize the effect of `build` on allocation, I did a nofib against 3f60ce8751c860a2bd0ddbe87429136a9d97449b run with and without `-fsimple- list-literals`. The major allocation changes were, {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ansi +0.0% +10.8% 0.000 0.004 0.0% bspt +0.1% +2.7% 0.004 0.004 0.0% cacheprof +0.1% +3.3% 0.181 0.181 0.0% eliza -0.2% +0.8% 0.000 0.000 0.0% fluid -0.1% +0.7% 0.004 0.004 0.0% fulsom +0.0% +0.7% 0.125 0.125 -21.4% integrate +0.0% +152.6% 0.081 0.081 +7.4% lift +0.0% +4.5% 0.000 0.000 0.0% nucleic2 -0.3% +2.4% 0.024 0.024 0.0% parser -0.4% +0.6% 0.011 0.012 0.0% reptile -0.0% +0.1% 0.004 0.004 0.0% rewrite +0.1% +96.7% 0.007 0.012 0.0% (those tests with no change in allocations omitted) -------------------------------------------------------------------------------- Min -0.4% -0.2% -1.0% -2.0% -21.4% Max +0.1% +152.6% +0.3% +0.6% +7.4% Geometric Mean -0.0% +1.9% -0.2% -0.2% -0.2% }}} There are a few things to note here: * Allocations, if they change at all, increase without `build` fusion, as we would expect * A `fulsom` had its total memory usage dramatically reduced without `build` fusion; this may be worth further investigation. * Runtime didn't appreciably change in any case * Binary sizes don't change On the other hand, if I compile `T9961` with `-fsimple-list-literals`, I see a dramatic reduction in compiler allocations (from 745044392 to 518841472, about 30%). Unfortunately it's not easy to measure the runtime cost of list construction with this test. I'll try to write up a simple `Criterion` benchmark to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 11:28:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 11:28:27 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.65a5cedf3108e1124f98f9f99374990a@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It turns out that getting fusion to fire as it does in `T9961` is actually quite tricky. For instance, while `listArray` fuses (producing a large string of `writeArray#`s) in this case, {{{#!hs arr = listArray (0,10) [ -1,-1,-1,-1,-1,-1,-1,-1,-1,-1 ] }}} It does not in this case, {{{#!hs arr = listArray (0,10) [ 1,1,1,1,1,1,1,1,1,1 ] }}} I then realized that only the prefix of negated elements will be unrolled. For instance, {{{#!hs arr = listArray (0,10) [ -1,-1,-1,1,1,1,1,1,1,1 ] }}} will fuse the first three elements into the construction loop, which will look something like this, {{{#!hs case newArray# ww3_aZu (arrEleBottom) s1#_aXo of _ { (# ipv_aXz, ipv1_aXA #) -> case ww3_aZu of wild3_aXC { __DEFAULT -> case writeArray# ipv1_aXA 0 arr11 ipv_aXz of s4#_aXH { __DEFAULT -> case -# wild3_aXC 1 of wild_XZ { __DEFAULT -> case writeArray# ipv1_aXA 1 arr11 s4#_aXH of s4#1_XYH { __DEFAULT -> case wild_XZ of wild1_X14 { __DEFAULT -> letrec { go_aYj :: [Integer] -> GHC.Prim.Int# -> GHC.Prim.State# s -> GHC.Prim.State# s go_aYj = \ ds_aYk eta_B2 eta1_B1 -> case ds_aYk of _ { [] -> eta1_B1; : y_aYp ys_aYq -> case writeArray# ipv1_aXA eta_B2 y_aYp eta1_B1 of s4#2_XYg { __DEFAULT -> case tagToEnum# (==# eta_B2 wild1_X14) of _ { False -> go_aYj ys_aYq (+# eta_B2 1) s4#2_XYg; True -> s4#2_XYg } } }; } in {- ... -} }}} where `arr11 = __integer -1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 11:33:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 11:33:55 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.ca1b24a5e9f3859f51038c84b3c9eaf5@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Why do `integrate` and `rewrite` regress so much? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 11:39:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 11:39:10 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.7de692de39f374d3a31a60b32fa5187f@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:3 simonpj]: > Why do `integrate` and `rewrite` regress so much? In the case of `integrate` we have, {{{#!hs let d = (u-l)/8.0 in d * sum [ (f l)*0.5, f (l+d), f (l+(2.0*d)), f (l+(3.0*d)), f (l+(4.0*d)), f (u-(3.0*d)), f (u-(2.0*d)), f (u-d), (f u)*0.5] }}} which is precisely the sort of pattern I was concerned about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 11:40:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 11:40:48 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.4241c1e1c2b5132ef38dba696883d7db@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm not as certain in the case of `rewrite`, which is a much larger program. This is one possibility, {{{#!hs group_rules = map parse_eqn [ "(a * b) * c = a * (b * c)", "E * x = x", "I(x) * x = E" ] }}} Perhaps the more likely culprit is, {{{#!hs p_term = seQ q_func [p_ident, look_for '(', list_of p_expr ',', look_for ')'] ## p_prim }}} where, `seQ` involves `foldr` on its list argument and was clearly designed expecting fusion. There are also a number of singleton lists, although -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 11:50:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 11:50:46 -0000 Subject: [GHC] #11710: Fusion of a simple listArray call is very fragile Message-ID: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> #11710: Fusion of a simple listArray call is very fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following (taken from ticket:11707#comment:2), {{{#!hs module Test where import Data.Array arr, arr2 :: Array Int Int arr = listArray (0,10) [ 1,1,1,1,1,1,1,1,1,1 ] arr2 = listArray (0,10) [ 1,1,1,1,1,1,1,1,1,-1 ] }}} Given that these are a small array, one might suspect it would be worthwhile for GHC to fuse the lists with `listArray`, giving rise to two nicely unrolled construction procedures. However, if you look at the Core produced by `-O1` this you'll find that this only happens in the case of `arr2`. `arr` on the other handle, is mysteriously not fused. The fact that these expressions are so similar and yet produce entirely different code is quite worrying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 11:51:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 11:51:43 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.fd184c6e1df6f1c79a7540e9f607bb5f@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've split out the strange inconsistency in unrolling discussed in comment:2 into another ticket, #11710. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 11:54:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 11:54:20 -0000 Subject: [GHC] #11710: Fusion of a simple listArray call is very fragile In-Reply-To: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> References: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> Message-ID: <061.20d5553da1b94bf5420232ccc932c9a8@haskell.org> #11710: Fusion of a simple listArray call is very fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): And here's a quick quiz for those playing along at home: How much unrolling would you expect to happen in this case? {{{#!hs arr :: Array Int Int arr = listArray (0,10) [ 1,1,1,-1,1,1,1,1,1,1 ] }}} **Answer**: The first four elements will be unrolled; the remaining will be constructed by recursive pattern matching against a CAF `[Int]` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 11:57:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 11:57:58 -0000 Subject: [GHC] #11710: Fusion of a simple listArray call is very fragile In-Reply-To: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> References: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> Message-ID: <061.c3a1fb4bcd5eee90ee72f3c231352009@haskell.org> #11710: Fusion of a simple listArray call is very fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, the case in comment:1 results in this Core, {{{#!hs Test2.arr10 = GHC.Types.I# 1 Test2.arr11 = GHC.Types.I# (-1) Test2.arr1 = \ (@ s) (s1# :: GHC.Prim.State# s) -> case GHC.Prim.newArray# @Int @s 11 (GHC.Arr.arrEleBottom @Int) s1# of _ { (# ipv, ipv1 #) -> case GHC.Prim.writeArray# @s @Int ipv1 0 Test2.arr10 ipv of s4# { __DEFAULT -> case GHC.Prim.writeArray# @s @Int ipv1 1 Test2.arr10 s4# of s4#1 { __DEFAULT -> case GHC.Prim.writeArray# @s @Int ipv1 2 Test2.arr10 s4#1 of s4#2 { __DEFAULT -> case GHC.Prim.writeArray# @s @Int ipv1 3 Test2.arr11 s4#2 of s4#3 { __DEFAULT -> letrec { go :: [Int] -> GHC.Prim.Int# -> GHC.Prim.State# s -> GHC.Prim.State# s go = \ (ds :: [Int]) (eta :: GHC.Prim.Int#) (eta1 :: GHC.Prim.State# s) -> case ds of _ { [] -> eta1; : y ys -> case GHC.Prim.writeArray# @s @Int ipv1 eta y eta1 of s4#4 { __DEFAULT -> case eta of wild1 { __DEFAULT -> go ys (GHC.Prim.+# wild1 1) s4#4; 10 -> s4#4 } } }; } in case go Test2.arr4 4 s4#3 of wild4 { __DEFAULT -> case GHC.Prim.unsafeFreezeArray# @s @Int ipv1 wild4 of _ { (# ipv2, ipv3 #) -> (# ipv2, GHC.Arr.Array @Int @Int Test2.arr3 Test2.arr2 11 ipv3 #) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 12:14:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 12:14:35 -0000 Subject: [GHC] #11710: Fusion of a simple listArray call is very fragile In-Reply-To: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> References: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> Message-ID: <061.0eb7f2c5ef9391880abe9e7128df7fc9@haskell.org> #11710: Fusion of a simple listArray call is very fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The reason for this inconsistency appears to be the dynamic prefix log in `dsExplicitList`. Let's look at the desugared output that gave rise to comment:2, {{{#!hs arr = listArray GHC.Arr.$fIxInt (GHC.Types.I# 0, GHC.Types.I# 10) (GHC.Base.build (\ (@ a) (c [OS=OneShot] :: Int -> a -> a) (n [OS=OneShot] :: a) -> c (GHC.Types.I# 1) (c (GHC.Types.I# 1) (c (GHC.Types.I# 1) (c (negate GHC.Num.$fNumInt (GHC.Types.I# 1)) (GHC.Base.foldr c n (GHC.Types.: (GHC.Types.I# 1) (GHC.Types.: (GHC.Types.I# 1) (GHC.Types.: (GHC.Types.I# 1) (GHC.Types.: (GHC.Types.I# 1) (GHC.Types.: (GHC.Types.I# 1) (GHC.Types.: (GHC.Types.I# 1) (GHC.Types.[]))))))))))))) }}} We see that the desugarer took everything up to and including the `-1` element as the dynamic prefix. The dynamic prefix is defined in `dsExplicitList` as, {{{#!hs is_static :: CoreExpr -> Bool is_static e = all is_static_var (varSetElems (exprFreeVars e)) is_static_var :: Var -> Bool is_static_var v | isId v = isExternalName (idName v) -- Top-level things are given external names | otherwise = False -- Type variables (dynamic_prefix, static_suffix) = spanTail is_static xs' }}} That is, anything expression having a free variable with an external name (e.g. `negate` in the current example) is considered to be non-static, even if it will eventually be resolved to something static during simplification. If we consider that `foldr`/`build` is an optimization, the above behavior seems reasonable, preserving potential optimization opportunities by liberally applying `build` desugaring. This does, however, lead to slightly longer compilation times even in the case where fusion didn't fire as we need to rewrite `build` to a plain list during simplification. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 12:20:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 12:20:54 -0000 Subject: [GHC] #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on In-Reply-To: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> References: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> Message-ID: <062.a9722a9045d16b5f1da9dd2a6a1e58dc@haskell.org> #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: kcsongor Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: typefamilies Resolution: | trace hangs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D2006 -------------------------------------+------------------------------------- Changes (by kcsongor): * differential: => https://phabricator.haskell.org/D2006 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 12:52:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 12:52:08 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.9d9c4f2e11b58e82f1110057be9421bd@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've pushed a simple approach to avoid `build`-based list desugaring for large lists to Phab:D2007. Here we simply threshold on the list length. I have a few concerns about this approach, * This threshold introduces a "performance cliff", where users will suddenly see drastically different performance characteristics as their literal lists grow. * There isn't really a good way to choose this size. Ideally we'd want a smaller threshold with larger consumers and vice-versa, but we have no way of knowing what will be consuming our list in the desugaring. From a runtime performance perspective, applying `build` more liberally should rarely hurt (it can only expose further optimization opportunities; if no fusion is possible it will eventually get rule-rewritten back to a list) Consequently, the threshold we introduce here is a bit concerning since we are limiting contexts in which we'll use `build`, potentially hiding optimizations. Regardless, `nofib` shows no change in allocations after this change, so it at very least doesn't hurt any of the cases there. Moreover, it shows a 30% reduction in compiler allocations in `T9961` (from 745044392 to 745044392 bytes). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 12:52:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 12:52:21 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.825c5ab340dab2016a5cecc9d3068d9e@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2007 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2007 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 12:59:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 12:59:17 -0000 Subject: [GHC] #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on In-Reply-To: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> References: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> Message-ID: <062.6ccaa3bd2f5417b74cfcf2b5ce323c5c@haskell.org> #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: kcsongor Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: typefamilies Resolution: | trace hangs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2006 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: https://phabricator.haskell.org/D2006 => Phab:D2006 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 14:44:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 14:44:39 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.4c96a8f00d078c6d542a80ec0a418894@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11648{,b} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): A few comments for posterity on the commit above: A lot of the changes are due to moving decisions out from kcHsTyVarBndrs, and thus the need to store information in the AST: - It turned out to be more convenient to decide if a data decl has a CUSK in the renamed than on the fly. (It could be done on the fly, but it would have been a bit hairy and duplicated code in the renamer.) See the new bit in the manual for a description of what's going on here. - There also needed to be a decision about whether to use `Anon` or `Named` when building the `TcTyBinder`s of a tycon's kind. Previous to this patch, this was done in `kcHsTyVarBndrs`, but -- as Simon pointed out to me -- this was bogus (it looked at the free variables of a not-yet- solved-or-zonked type). So it's now done via a simple syntactic check in the renamer. But then the result of the check must be put in the AST, causing knock-on changes. See `Note [Dependent LHsQTyVars]` in !TcHsType and also a new bit in the manual. - One of this issues brought up in the ticket is the handling of CUSKs for associated type families. An associated type/data family's CUSKness must be inherited from the enclosing class. Previously, all associated families had CUSKs, but this was wrong. So the CUSK check is a bit more intricate to allow for this relationship. - Along the way, I made `(->)`, when used in a kind, have type `* -> * -> *`, instead of being polymorphic in `RuntimeRep`s. We don't have type- level representation polymorphism. - Also incidental to this patch, I made kind variables have kind `*` when `-XTypeInType` is not in effect. Not doing this earlier was an oversight. The check isn't perfect, as it's sometimes hard to tell what's a kind variable and what isn't; currently, only variables used in kinds in tycon `LHsQTyVars` are affected, and these are surely kind variables. (This is `mk_kv_kinds` in `kcHsTyVarBndrs`.) - There is a new function `anonymiseTyBinders`. This was necessary in an earlier version of this patch but is now redundant (and harmless). I will remove. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 15:25:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 15:25:36 -0000 Subject: [GHC] #11711: Typechecker assertion failure Message-ID: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> #11711: Typechecker assertion failure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've seen this program both fail with a typechecker assertion and Core lint violations with various GHC versions, {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ViewPatterns #-} {-# LANGUAGE TypeInType #-} module Hi where import Data.Kind (Type) data (:~~:) a b where HRefl :: a :~~: a data TypeRep (a :: k) where TrTyCon :: String -> TypeRep k -> TypeRep (a :: k) TrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). TypeRep (a :: k1 -> k2) -> TypeRep (b :: k1) -> TypeRep (a b) class Typeable (a :: k) where typeRep :: TypeRep a data TypeRepX where TypeRepX :: forall k (a :: k). TypeRep a -> TypeRepX eqTypeRep :: TypeRep a -> TypeRep b -> Maybe (a :~~: b) eqTypeRep = undefined typeRepKind :: forall k (a :: k). TypeRep a -> TypeRep k typeRepKind = undefined funResultTy :: TypeRepX -> TypeRepX -> Maybe TypeRepX funResultTy (TypeRepX f) (TypeRepX x) | Just HRefl <- (typeRep :: TypeRep Type) `eqTypeRep` typeRepKind f , TRFun arg res <- f , Just HRefl <- arg `eqTypeRep` x = Just (TypeRepX res) | otherwise = Nothing trArrow :: TypeRep (->) trArrow = undefined pattern TRFun :: forall fun. () => forall arg res. (fun ~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRFun arg res <- TrApp (TrApp (eqTypeRep trArrow -> Just HRefl) arg) res }}} The most recent type checker error is, {{{ $ ~/ghc/ghc-testing/inplace/bin/ghc-stage2 -dcore-lint ~/Hi.hs [1 of 1] Compiling Hi ( /home/ben/Hi.hs, /home/ben/Hi.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160315 for x86_64-unknown-linux): tcTyVarDetails cobox_a1Nm :: k_a1N4[ssk] ~# Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 15:25:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 15:25:47 -0000 Subject: [GHC] #11711: Typechecker assertion failure In-Reply-To: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> References: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> Message-ID: <061.5a67dfb7918a970773da8fca73fd4f0a@haskell.org> #11711: Typechecker assertion failure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 15:26:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 15:26:39 -0000 Subject: [GHC] #11711: Typechecker assertion failure In-Reply-To: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> References: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> Message-ID: <061.684a21333d2fa008b8aa4c5f1f4c3d12@haskell.org> #11711: Typechecker assertion failure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I believe the culprit is the pattern matches in `funResultTy`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 17:45:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 17:45:29 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.b893acd2e95c975e7513b00c5750f56e@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * status: closed => new * resolution: fixed => Comment: The example I attached after the february 8th patch still doesn't compile. The `ctev_dest` crash was masking a completely different blowup. That said, it may not be for this issue, but for something else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 17:57:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 17:57:09 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.ce01baa0f5bad59c7431f834e995419c@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Adding `p ~ Op (Op p)`) to the superclass constraints of `Category` in Categories.hs ''drastically'' reduces the size of the unresolved wanteds, but they never seem to go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 18:47:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 18:47:56 -0000 Subject: [GHC] #9405: Ticky results should be displayed even during interrupts (Ctrl-c) In-Reply-To: <052.9c2a439965f718a8964f4e460ff5ae13@haskell.org> References: <052.9c2a439965f718a8964f4e460ff5ae13@haskell.org> Message-ID: <067.0ff0c69d602b6f644432769fab8ec061@haskell.org> #9405: Ticky results should be displayed even during interrupts (Ctrl-c) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2008 Wiki Page: | -------------------------------------+------------------------------------- Changes (by archblob): * owner: => archblob * differential: => Phab:D2008 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 15 21:48:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Mar 2016 21:48:00 -0000 Subject: [GHC] #11642: Heterogeneous type equality evidence ignored In-Reply-To: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> References: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> Message-ID: <061.80cc12cc6df8e486cd1bf8a7fc2c881d@haskell.org> #11642: Heterogeneous type equality evidence ignored -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: invalid | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: A maze this is, indeed. But, happily(?), we humans were the ones lost, not GHC, which is spot on. The original code is {{{#!hs buildApp :: TypeRepX -> TypeRepX -> TypeRepX buildApp (TypeRepX f) (TypeRepX x) = case typeRepKind f of TRFun arg _ -> case eqTypeRep arg x of Just HRefl -> TypeRepX $ TypeApp f x }}} Let me augment with some kinds and such: {{{#!hs buildApp :: TypeRepX -> TypeRepX -> TypeRepX buildApp (TypeRepX f) (TypeRepX x) = -- f :: TypeRep kind_tf (tf :: kind_tf) -- x :: TypeRep kind_tx (tx :: kind_tx) case typeRepKind f of TRFun arg _ -> -- arg :: TypeRep kind_targ (targ :: kind_targ) -- _ :: TypeRep kind_tres (tres :: kind_tres) -- _ :: kind_tf ~ (targ -> tres) -- _ :: kind_targ ~ * -- _ :: kind_tres ~ * case eqTypeRep arg x of Just HRefl -> -- _ :: kind_targ ~ kind_tx (but kind_targ ~ *) -- _ :: targ ~ tx TypeRepX $ TypeApp f x -- NEED: exists k1 k2. -- kind_tf ~ k1 -> k2 -- kind_tx ~ k1 }}} At the end, we need to find `k1` and `k2` such that those two equalities are provable from our givens. The choice of `k1` and `k2` is quite clear: choose `k1 := targ` and `k2 := tres`. Now, we must prove `kind_tx ~ targ`. But we can't! We know that `targ ~ tx`, not `targ ~ kind_tx`. Note that, actually, `kind_tx` is really known to be `*`. So GHC helpfully reports {{{ T11642.hs:47:30: error: ? Could not deduce: arg ~ * from the context: k ~ (arg -> res) bound by a pattern with pattern synonym: TRFun :: forall fun arg res. (fun ~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun, in a case alternative at T11642.hs:37:5-15 or from: (* ~ k1, arg ~ a1) bound by a pattern with constructor: HRefl :: forall k2 (a :: k2). a :~~: a, in a case alternative at T11642.hs:44:14-18 ?arg? is a rigid type variable bound by a pattern with pattern synonym: TRFun :: forall fun arg res. (fun ~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun, in a case alternative at T11642.hs:37:5 Expected type: TypeRep a Actual type: TypeRep a ? In the first argument of ?TypeApp?, namely ?f? In the second argument of ?($)?, namely ?TypeApp f x? In the expression: TypeRepX $ TypeApp f x ? Relevant bindings include arg :: TypeRep arg (bound at T11642.hs:37:11) }}} Which is absolutely correct. Happily, fixing the code is easy: {{{#!hs -- ... case eqTypeRep arg (typeRepKind x) of -- ... }}} works like a charm. I do believe some intermediate work (between when this was reported and now) has improved this message. It's still not great, given that it took me the better part of an hour to deduce all of the above. But I don't see how we can do better without giving the user the trail of breadcrumbs that GHC used to find its result. (I ''do'' think we should give this ability to the user, somehow. It would be easy enough to implement -- just augment `CtLoc` to keep track of previous constraints and how they were transformed. The data is all there.) I'm thus closing this as invalid. I'm also not adding a regression test, because I'm not thrilled with the error message as it is, and there's no other unusual behavior here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 01:17:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 01:17:17 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.2b04ed42d11f0adea56c1f96e718094d@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11648{,b} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"19be5385e2875578c3a7d1154238580f0ef3c754/ghc" 19be5385/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="19be5385e2875578c3a7d1154238580f0ef3c754" Remove redundant anonymiseTyBinders (#11648) This was necessary in an earlier version of the patch for #11648, but not in the final version. I forgot to remove it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 01:17:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 01:17:17 -0000 Subject: [GHC] #11357: Regression when deriving Generic1 on poly-kinded data family In-Reply-To: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> References: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> Message-ID: <065.81cfc2e33d81297a062e073b474af4ef@haskell.org> #11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Generics, Resolution: | TypeInType, TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"1eefedf7371778d1721d9af9247c2eff12ae7417/ghc" 1eefedf7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1eefedf7371778d1721d9af9247c2eff12ae7417" Fix #11357. We were looking at a data instance tycon for visibility info, which is the wrong place to look. Look at the data family tycon instead. Also improved the pretty-printing near there to suppress kind arguments when appropriate. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 01:17:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 01:17:17 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.6cab973916b4b863b3ea080edcea2ba3@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"aade111248dce0834ed83dc4f18c234967b32024/ghc" aade1112/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aade111248dce0834ed83dc4f18c234967b32024" Fix #11473. I've added a check in the zonker for representation polymorphism. I don't like having this be in the zonker, but I don't know where else to put it. It can't go in TcValidity, because a clever enough user could convince the solver to do bogus representation polymorphism even though there's nothing obviously wrong in what they wrote. Note that TcValidity doesn't run over *expressions*, which is where this problem arises. In any case, the check is simple and it works. test case: dependent/should_fail/T11473 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 01:17:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 01:17:17 -0000 Subject: [GHC] #11614: document TypeInType In-Reply-To: <047.1743dce4e41c34187f3120f682a53edd@haskell.org> References: <047.1743dce4e41c34187f3120f682a53edd@haskell.org> Message-ID: <062.d36dbf32aee962e2a575bae528b9a1eb@haskell.org> #11614: document TypeInType -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1995 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"857e9b0231db80b838d78e341954d3e75db7e94b/ghc" 857e9b0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="857e9b0231db80b838d78e341954d3e75db7e94b" Incorporate bgamari's suggestions for #11614. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 01:17:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 01:17:17 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.71e113cac5f78d098db3734a20a02fbb@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"f602f4a6fbf40d1a3c3c02294e90fcb2d5866d04/ghc" f602f4a6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f602f4a6fbf40d1a3c3c02294e90fcb2d5866d04" Fix printing of "kind" vs. "type" This is as reported in #11471, though it's not the focus of that ticket. test case: polykinds/KindVType }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 01:17:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 01:17:17 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.67e553d7543524b310bd41176da618c3@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"5d98b8bf249fab9bb0be6c5d4e8ddd4578994abb/ghc" 5d98b8bf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5d98b8bf249fab9bb0be6c5d4e8ddd4578994abb" Clean up some pretty-printing in errors. It turns out that there were some pretty egregious mistakes in the code that suggested -fprint-explicit-kinds, which are fixed. This commit also reorders a bunch of error messages, which I think is an improvement. This also adds the test case for #11471, which is what triggered the cleanup in TcErrors. Now that #11473 is done, there is nothing more outstanding for #11471. test case: dependent/should_fail/T11471 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 01:17:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 01:17:17 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.64c65ea9402e48f862e4c25d2968cb79@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"5d98b8bf249fab9bb0be6c5d4e8ddd4578994abb/ghc" 5d98b8bf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5d98b8bf249fab9bb0be6c5d4e8ddd4578994abb" Clean up some pretty-printing in errors. It turns out that there were some pretty egregious mistakes in the code that suggested -fprint-explicit-kinds, which are fixed. This commit also reorders a bunch of error messages, which I think is an improvement. This also adds the test case for #11471, which is what triggered the cleanup in TcErrors. Now that #11473 is done, there is nothing more outstanding for #11471. test case: dependent/should_fail/T11471 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 01:19:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 01:19:39 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.cea5a0d7a771da41fb01598cfcde0c67@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11648{,b} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Don't forget to merge both 55577a9 (the main patch) and 19be5385. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 01:20:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 01:20:40 -0000 Subject: [GHC] #11357: Regression when deriving Generic1 on poly-kinded data family In-Reply-To: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> References: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> Message-ID: <065.b1d678bee16b9d334dc708da9344f27d@haskell.org> #11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Generics, Resolution: | TypeInType, TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T11357 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => deriving/should_compile/T11357 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 01:21:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 01:21:17 -0000 Subject: [GHC] #11614: document TypeInType In-Reply-To: <047.1743dce4e41c34187f3120f682a53edd@haskell.org> References: <047.1743dce4e41c34187f3120f682a53edd@haskell.org> Message-ID: <062.aee8f1185921190b01e4fa7004967546@haskell.org> #11614: document TypeInType -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: task | Status: merge Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1995 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => merge Comment: Please merge both e7a8cb14 and 857e9b0. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 01:25:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 01:25:42 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.7fef5cae0532872863e873b6dbf27167@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | dependent/should_fail/T11473 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => dependent/should_fail/T11473 Comment: All set now. Perhaps in the future we can find a better home for this check than in the zonker. But the check is very simple, and we know it will always get applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 01:26:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 01:26:42 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.64d660d595e4a341a7c6353ad26e9c45@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T11471 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => dependent/should_fail/T11471 Comment: In the end, there wasn't much to do here other than the `RuntimeRep` stuff. Still worth merging that last commit, but it's not all that important. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 08:05:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 08:05:04 -0000 Subject: [GHC] #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) In-Reply-To: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> References: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> Message-ID: <066.b313adef203416fd4f3592670964d1f2@haskell.org> #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): For posteriority: [http://blog.haskell-exists.com/yuras/posts/turn-ghc- into-frontend-for-ministg.html Turn GHC into a frontend for miniSTG] ([https://www.reddit.com/r/haskell/comments/4akub2/turn_ghc_into_a_frontend_for_ministg/ reddit post]). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 08:42:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 08:42:02 -0000 Subject: [GHC] #11407: -XTypeInType uses up all memory when used in data family instance In-Reply-To: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> References: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> Message-ID: <065.d8cd7598e23c1feb5c9a1ec55fbedbe9@haskell.org> #11407: -XTypeInType uses up all memory when used in data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: TypeInType, Resolution: fixed | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | dependent/should_fail/T11407 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as d23e9effcd23c9522e97eedc839c4ab819f4c1fb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 08:43:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 08:43:42 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.1756c3113bec3c054ecab8306f0a00d2@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | dependent/should_fail/T11334 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 44a95c6f2421c265da6d20af8c2968933b0d1878. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 08:44:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 08:44:44 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.4ed8cda08f83fcf6ee874bb6b98e9261@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11401 Blocked By: | Blocking: Related Tickets: #11523 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged comment:12 as e0ca94e3111349c0cef96a20950bdc591e586548. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 08:45:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 08:45:51 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic In-Reply-To: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> References: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> Message-ID: <066.ac66552a14b9aac16594de1929de1355@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | TypeApplications GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T11456 Blocked By: | Blocking: Related Tickets: #11329 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Merged comment:7 as 729320938b17a101c4a6b43c824edace9ebb53f6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 08:46:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 08:46:12 -0000 Subject: [GHC] #11699: Type families mistakingly report kind variables as unbound type variables In-Reply-To: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> References: <044.2cdcacd1da1f6f925fba3551e2c0559f@haskell.org> Message-ID: <059.e70992b22d63413269b97c75e5f4c656@haskell.org> #11699: Type families mistakingly report kind variables as unbound type variables -------------------------------------+------------------------------------- Reporter: mniip | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compiler/T11699 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 397362e6eaee30e0650dd8f8681160eaf5227407. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 08:47:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 08:47:31 -0000 Subject: [GHC] #11614: document TypeInType In-Reply-To: <047.1743dce4e41c34187f3120f682a53edd@haskell.org> References: <047.1743dce4e41c34187f3120f682a53edd@haskell.org> Message-ID: <062.02ed0747caae8b804b3defb4cee99f77@haskell.org> #11614: document TypeInType -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1995 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as ace3dd93ac0c3ba4214c6928df14a0eb3652822e and a96933017470d03a1c9414c9c90dfd5c0f0903ed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 08:49:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 08:49:04 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.26c23a957e98f735170805184ec95861@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11648{,b} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged comment:20 as eda74a7aa57f5de4157cac7202c4fdaf72fed76c and comment:23 as cbfebfb3937b1d69ea5786b87a60f5d9938d77bb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 09:02:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 09:02:28 -0000 Subject: [GHC] #11709: Merge some TypeInType fixes In-Reply-To: <047.8d0ecbfab650310ecba0e613108d8b2b@haskell.org> References: <047.8d0ecbfab650310ecba0e613108d8b2b@haskell.org> Message-ID: <062.009ed5b8f809e41bc1d79d60b36fa24f@haskell.org> #11709: Merge some TypeInType fixes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: These have all been merged. Thanks goldfire! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 09:05:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 09:05:08 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.84fea299217c3a46f010a236dfd74022@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T11471 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged comment:23 as 01777cc41af888f690ac57556362fcfc2749f305. Merged comment:24 as e00c581bc5e8cabac3abce9fe883d0688070cfff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 09:05:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 09:05:20 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.0fa8deb529083fe90757b3895b39ae83@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: fixed | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T11471 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 09:14:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 09:14:04 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.ccc38d3138f44902f5cfed9e0d51a92c@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2009 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => patch * differential: => Phab:D2009 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 09:20:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 09:20:42 -0000 Subject: [GHC] #11712: Very confusing error message with -fprint-explicit-kinds Message-ID: <046.05390a91e58122ea87d7f537d0159d7b@haskell.org> #11712: Very confusing error message with -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to work out a type error I encountered the following, {{{ compiler/utils/Binary.hs:607:59: error: ? Could not deduce: (~) * * arg * from the context: (~) * k (arg -> res) ... }}} Note how in the first line `(~)` is applied to four arguments whereas on the second it is applied to three. In general, it would be nice if we could make equalities a bit more readable, perhaps special-casing them in the pretty-printer as, {{{ (a :: k) ~ (b :: k') }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 10:32:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 10:32:40 -0000 Subject: [GHC] #11712: Very confusing error message with -fprint-explicit-kinds In-Reply-To: <046.05390a91e58122ea87d7f537d0159d7b@haskell.org> References: <046.05390a91e58122ea87d7f537d0159d7b@haskell.org> Message-ID: <061.630e4d966e0aa32101bf5bb967b98365@haskell.org> #11712: Very confusing error message with -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -11,1 +11,3 @@ - the second it is applied to three. + the second it is applied to three. Presuambly this is due to the former + being kind heterogeneous, so at very least I'd think that `~~` should be + used here. New description: While trying to work out a type error I encountered the following, {{{ compiler/utils/Binary.hs:607:59: error: ? Could not deduce: (~) * * arg * from the context: (~) * k (arg -> res) ... }}} Note how in the first line `(~)` is applied to four arguments whereas on the second it is applied to three. Presuambly this is due to the former being kind heterogeneous, so at very least I'd think that `~~` should be used here. In general, it would be nice if we could make equalities a bit more readable, perhaps special-casing them in the pretty-printer as, {{{ (a :: k) ~ (b :: k') }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 11:31:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 11:31:17 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.573dc5f3683a441995e5a6befe503b17@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2010 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2010 Comment: I've uploaded the current state of my [wip/ttypeable](https://github.com/ghc/ghc/compare/master...bgamari:wip/ttypeable) branch as Phab:D2010. It's still quite preliminary however it does give you a working stage2 compiler with functional type-indexed type representations and what I believe is a pretty reasonable set of interfaces. I've also written up a description of the proposal as I have implemented it at Typeable/BenGamari. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 12:23:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 12:23:54 -0000 Subject: [GHC] #11712: Very confusing error message with -fprint-explicit-kinds In-Reply-To: <046.05390a91e58122ea87d7f537d0159d7b@haskell.org> References: <046.05390a91e58122ea87d7f537d0159d7b@haskell.org> Message-ID: <061.694921ea126187dddca9160d6bdc6932@haskell.org> #11712: Very confusing error message with -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, that looks terribly inconsistent. I like printing equalities as `(a :: k) ~ (b :: k')`, at least with `-fprint-explicit-kinds`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 12:57:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 12:57:09 -0000 Subject: [GHC] #11712: Very confusing error message with -fprint-explicit-kinds In-Reply-To: <046.05390a91e58122ea87d7f537d0159d7b@haskell.org> References: <046.05390a91e58122ea87d7f537d0159d7b@haskell.org> Message-ID: <061.426dee4f4928e1009ef182a5360b25c4@haskell.org> #11712: Very confusing error message with -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The reason for the inconsistency is because, without `-fprint-equality- relations`, all of `(~)`, `(~~)`, and `(~#)` render as `(~)`. In a program that doesn't mention equality (or mentions only `(~)`), any of these may appear. In order not to scare users with three equality relations, I taught GHC to print just one. But I'm very uncertain about this decision. I asked on devs a while ago, and the best suggestion there was to render the heterogeneous ones as heterogeneous when, in fact, the kinds on their sides differ -- but only then. Perhaps I'll implement that alongside the other suggestion here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 14:07:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 14:07:29 -0000 Subject: [GHC] #11713: STM Finalizers Message-ID: <051.e60097434689e0df7cd503283058f128@haskell.org> #11713: STM Finalizers -------------------------------------+------------------------------------- Reporter: mc.schroeder | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is some work I did as part of my master's thesis [1]. It's an extension to GHC's STM implementation. The main idea is to introduce a new primitive function {{{#!hs atomicallyWithIO :: STM a -> (a -> IO b) -> IO b }}} Like the existing atomically operation, atomicallyWithIO performs an STM computation. Additionally, it takes a '''finalizer''', which is an arbitrary I/O action that can depend on the result of the STM computation, and combines it with the transaction in such a way that: 1. The finalizer is only performed if the STM transaction is guaranteed to commit. 2. The STM transaction only commits if the finalizer finishes without raising an exception. A detailed specification, including an operational semantics, as well as a discussion of the implementation, can be found in chapter 2 of my thesis [1]. ---- I actually did this work quite some time ago, and even announced it on the mailing list [2] to some positive feedback, but then never got around to actually submitting a patch. Last week Charles Strahan wrote me on GitHub and got me motivated again, so here I am :) I'm submitting a code review to Phabricator right now and will link it to this ticket. ---- [1] https://github.com/mcschroeder/thesis [2] https://mail.haskell.org/pipermail/haskell-cafe/2015-July/120589.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 14:19:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 14:19:36 -0000 Subject: [GHC] #11711: Typechecker assertion failure In-Reply-To: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> References: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> Message-ID: <061.f7eff53590e03e8f787367819c2b46ca@haskell.org> #11711: Typechecker assertion failure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Nope. The culprit is that we're calling `isMetaTyVar` on a coercion variable from `simpl_top`. I've got a fix locally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 14:43:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 14:43:28 -0000 Subject: [GHC] #11713: STM Finalizers In-Reply-To: <051.e60097434689e0df7cd503283058f128@haskell.org> References: <051.e60097434689e0df7cd503283058f128@haskell.org> Message-ID: <066.b15cfc3d81fc55aed5f2818f0c534156@haskell.org> #11713: STM Finalizers -------------------------------------+------------------------------------- Reporter: mc.schroeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): (2) looks as if it'd impose some pretty heavy constraints on the implementation. To implement it you have to hold locks on all the TVars from the transaction (to satisfy (1)). These would usually be held only very briefly. But the IO action could do anything, including more transactions. Which could take arbitrarily long, and themselves would deadlock if they affect any of those TVars. A multi-CAS implementation for transaction commit would not work any more. I'm unconvinced. I've always wanted some `onRetry` thing that would run a specified IO action if transaction retries, to allow users to check for starvation and take evasive action. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 14:52:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 14:52:36 -0000 Subject: [GHC] #11642: Heterogeneous type equality evidence ignored In-Reply-To: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> References: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> Message-ID: <061.a2bd124243aab5fb29b1cc9470cef1a7@haskell.org> #11642: Heterogeneous type equality evidence ignored -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: invalid | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh dear, what a silly mistake on my part. Thanks for tracking this down Richard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 15:00:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 15:00:40 -0000 Subject: [GHC] #11713: STM Finalizers In-Reply-To: <051.e60097434689e0df7cd503283058f128@haskell.org> References: <051.e60097434689e0df7cd503283058f128@haskell.org> Message-ID: <066.9bdb0e63b7abd33fd5f046feffbc0dc7@haskell.org> #11713: STM Finalizers -------------------------------------+------------------------------------- Reporter: mc.schroeder | Owner: mc.schroeder Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2011 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mc.schroeder): * owner: => mc.schroeder * differential: => Phab:D2011 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 15:13:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 15:13:26 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.a31521495f1ca2deb36f7547493be604@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2010 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I like the direction here. On deserialisation, let's make sure we have a compelling use-case before investing much time tilting at windmills. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 16:08:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 16:08:56 -0000 Subject: [GHC] #11710: Fusion of a simple listArray call is very fragile In-Reply-To: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> References: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> Message-ID: <061.2279c2d465ad23b40a3d7a0b30d18b87@haskell.org> #11710: Fusion of a simple listArray call is very fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, see `Note [Desugaring explicit lists]` in `DsExpr`, about the "static tail" of a list. For `listArray (1,100) [1,2` we get {{{ let { $dIx_aHr :: Ix Integer [LclId, Str=DmdType] $dIx_aHr = GHC.Arr.$fIxInteger } in let { $dNum_aSd :: Num Integer [LclId, Str=DmdType] $dNum_aSd = GHC.Num.$fNumInteger } in let { $dNum_aSh :: Num Integer [LclId, Str=DmdType] $dNum_aSh = $dNum_aSd } in let { $dNum_aSj :: Num Integer [LclId, Str=DmdType] $dNum_aSj = $dNum_aSh } in let { $dNum_aSf :: Num Integer [LclId, Str=DmdType] $dNum_aSf = $dNum_aSd } in letrec { alex_table_aSk :: Array Integer Integer [LclId, Str=DmdType] alex_table_aSk = listArray @ Integer @ Integer $dIx_aHr (0, 100) (GHC.Types.: @ Integer 1 (GHC.Types.: @ Integer 2 (GHC.Types.[] @ Integer))); } }}} (The dead `Num` dictionaries happen because the desugarer short-circuits the calls to `fromInteger @ Integer`.) Notice that the list has no free vars, so via the "static tail" trick in `DsExpr` we generate an explicit list. But for `listArray (0,100) [-1,2]` we get {{{ let { $dIx_aHs :: Ix Integer [LclId, Str=DmdType] $dIx_aHs = GHC.Arr.$fIxInteger } in let { $dNum_aSe :: Num Integer [LclId, Str=DmdType] $dNum_aSe = GHC.Num.$fNumInteger } in let { $dNum_aSi :: Num Integer [LclId, Str=DmdType] $dNum_aSi = $dNum_aSe } in let { $dNum_aSm :: Num Integer [LclId, Str=DmdType] $dNum_aSm = $dNum_aSi } in let { $dNum_aSk :: Num Integer [LclId, Str=DmdType] $dNum_aSk = $dNum_aSi } in let { $dNum_aSg :: Num Integer [LclId, Str=DmdType] $dNum_aSg = $dNum_aSe } in letrec { alex_table_aSn :: Array Integer Integer [LclId, Str=DmdType] alex_table_aSn = listArray @ Integer @ Integer $dIx_aHs (0, 100) (GHC.Base.build @ Integer (\ (@ a_d22o) (c_d22p :: Integer -> a_d22o -> a_d22o) (n_d22q :: a_d22o) -> c_d22p (negate @ Integer $dNum_aSi 1) (GHC.Base.foldr @ Integer @ a_d22o c_d22p n_d22q (GHC.Types.: @ Integer 2 (GHC.Types.[] @ Integer))))); } in }}} Now the calls to `negate` have a dictionary `$dNum_asi` which isn't top- level, so the "static tail" stuff fails and we generate a `build`. **This is obviously far too fragile. I think we should just drop the "static tail" idea entirely.** It's never bad to generate the build form, except for generating bloated code; see #11707. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 16:11:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 16:11:56 -0000 Subject: [GHC] #11710: Fusion of a simple listArray call is very fragile In-Reply-To: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> References: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> Message-ID: <061.3cc0b86f41bbc8c16903ebddff8a67a3@haskell.org> #11710: Fusion of a simple listArray call is very fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Then we can also get rid of `-fsimple-list-literals`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 16:12:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 16:12:01 -0000 Subject: [GHC] #11713: STM Finalizers In-Reply-To: <051.e60097434689e0df7cd503283058f128@haskell.org> References: <051.e60097434689e0df7cd503283058f128@haskell.org> Message-ID: <066.e055128449e01e0f3f72bd9ffbdd184a@haskell.org> #11713: STM Finalizers -------------------------------------+------------------------------------- Reporter: mc.schroeder | Owner: mc.schroeder Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2011 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mc.schroeder): Actually, instead of simply locking all TVars involved in a finalizing transaction, my implementation "freezes" them, meaning they can still be read by other transactions (preserving read-parallelism). Only when another transaction tries to commit a write to a frozen TVar is its thread blocked. It is woken up again when the finalizer that froze the TVar has finished. Of course, this could take a while (potentially forever), and all transactions waiting on frozen TVars are stalled in the meantime. However, I would say that this is exactly the point of finalizers: they create a serialization point. As for the potential of deadlocks due to nested transactions: a deadlock could only occur if the inner transaction writes a TVar used by the outer transaction. In my opinion, this is a rather artifical scenario, that is unlikely to happen by accident. It will also always be detected by the runtime system, which would then gracefully abort the transaction with a BlockedIndefinitelyOnSTM exception. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 16:13:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 16:13:38 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.48fbe0ace1b11c7a96b26d414bd67f6b@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2007 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See #11710; I think we should abandon the "static tail" idea described in `Note [Desugaring explicit lists]` entirely. Then, to avoid code bloat on very long lists, let's have the patch in this ticket, which ensures that if the list is long we revert to cons-list for. The goal here is just to eliminate mega-code-bloat in extreme cases. (Hence no real need for a flag to control `maxBuildLength`. I don't really like it; but I don't want BOTH hacks. One is enough! Not worth burning much midnight oil on this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 16:27:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 16:27:01 -0000 Subject: [GHC] #11713: STM Finalizers In-Reply-To: <051.e60097434689e0df7cd503283058f128@haskell.org> References: <051.e60097434689e0df7cd503283058f128@haskell.org> Message-ID: <066.ae24c959679396d5ed8954e075632bba@haskell.org> #11713: STM Finalizers -------------------------------------+------------------------------------- Reporter: mc.schroeder | Owner: mc.schroeder Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2011 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well, it may be unlikely but both the specification and the implementation must take care of these cases. Is all this complexity justified by the use-cases. Maybe, but I am not yet convinced. Eg for your serialisation example, I'd just transactionally commit the result to a buffer of things to be serialised by single serialisation thread. That is, in effect, what you are doing by other means. Let's see what Simon M and others GHC devs/users say. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 17:18:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 17:18:57 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.32babaa80dbe877f765258b4111c08c8@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The undecideable superclasses thing has the following property: * If you have a type error (a wanted that genuinely cannot be solved) * and you have an infinite number of superclasses then the typechecker will diverge, or at least complain about too many iterations. In this case, do you think that there is a finite tower of superclasses? I get {{{ [G] Category p +-> {add superclasses} Functor p Dom p ~ Op p Cod p ~ Nat p (->) Ob (Op p) ~ Ob p +-> {add superclasse of Functor} Category (Dom p) Cateogory (Cod p) }}} and now we merrily go round. Adding `p ~ Op (Op p)` will help, because `Dom p ~ Op p`. But we are still going to get `Cateogry (Cod p)`, `Category (Cod (Cod p))` and so on. Is that really what you intend? Actually we get a hand without "too many iterations", which is odd, but still I'd like to know the answer to the above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 17:35:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 17:35:27 -0000 Subject: [GHC] #11711: Typechecker assertion failure In-Reply-To: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> References: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> Message-ID: <061.50243efc2f06b0477f08188d95271a01@haskell.org> #11711: Typechecker assertion failure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Heh, I suppose I should have been more precise; I meant the `funResultTy` in the example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 17:44:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 17:44:20 -0000 Subject: [GHC] #11670: Can't infer type In-Reply-To: <051.c0c820eeed6752ec1594c0814ddee3a0@haskell.org> References: <051.c0c820eeed6752ec1594c0814ddee3a0@haskell.org> Message-ID: <066.e4bd324fd3c2caf6731a098fb1253392@haskell.org> #11670: Can't infer type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well this is confusing, I agree. It's useful to open up the question of what partial type signatures mean. Remember {{{ castPtr :: Ptr a -> Ptr b peekElemOff :: Storable a => Ptr a -> Int -> IO a }}} So what is the type of the sub-expression `peekElemOff (castPtr ptr) 0`? Clearly it is {{{ peekElemOff (castPtr ptr) :: forall a. Storable a => IO a }}} If, in the program in comment:1, we had tried this {{{ peekElemOff (castPtr ptr) 0 :: IO a }}} we would clearly expect the error message above, because that means {{{ peekElemOff (castPtr ptr) 0 :: forall a. IO a }}} and the sub-expression doesn't have that type. So what do we expect when we write {{{ peekElemOff (castPtr ptr) 0 :: IO _ }}} You intended "don't generalise this; just substitute `CLong` for `_`". But we ''do'' generalise even partial signatures. I did toy with ''not'' generalising partial signatures. So if you wrote {{{ f :: _ -> a -> _ }}} that would mean {{{ f :: forall a. _ -> a -> _ }}} and the `_` might get filled in with `a` or with `Int` or perhaps with some other type -- ''but it would not be generalised''. So if I wrote {{{ f :: _ -> _ f x = x }}} I'd get a ''monomorphic'' identity function, not a polymorphic one. Is that what we expect? On the whole I think that would be better. What do you think? However currently I ''do'' generalise those wildcards, for reasons explained towards the end of this Note. Maybe we should revisit this decision? {{{ {- Note [Which type variables to quantify] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When choosing type variables to quantify, the basic plan is to quantify over all type variables that are * free in the tau_tvs, and * not forced to be monomorphic (mono_tvs), for example by being free in the environment. However, for a pattern binding, or with wildcards, we might be doing inference *in the presence of a type signature*. Mostly, if there is a signature we use CheckGen, not InferGen, but with pattern bindings or wildcards we might do InferGen and still have a type signature. For example: f :: _ -> a f x = ... or g :: (Eq _a) => _b -> _b or p :: a -> a (p,q) = e In all these cases we use plan InferGen, and hence call simplifyInfer. But those 'a' variables are skolems, and we should be sure to quantify over them, regardless of the monomorphism restriction etc. If we don't, when reporting a type error we panic when we find that a skolem isn't bound by any enclosing implication. Moreover we must quantify over all wildcards that are not free in the environment. In the case of 'g' for example, silly though it is, we want to get the inferred type g :: forall t. Eq t => Int -> Int and then report ambiguity, rather than *not* quantifying over 't' and getting some much more mysterious error later. A similar case is h :: F _a -> Int That's why we pass sigs to simplifyInfer, and make sure (in quantify_tvs) that we do quantify over them. Trac #10615 is a case in point. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 17:52:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 17:52:17 -0000 Subject: [GHC] #11711: Typechecker assertion failure In-Reply-To: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> References: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> Message-ID: <061.cfc9450c6e7f32d896c134cab2e10044@haskell.org> #11711: Typechecker assertion failure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, I realized that after posting. In any case, the bug I fixed just masked a deeper, Core Lint issue that I'm working on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 18:26:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 18:26:14 -0000 Subject: [GHC] #11711: Typechecker assertion failure In-Reply-To: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> References: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> Message-ID: <061.a15e9681b0987b46afc992f3e9a0dfb9@haskell.org> #11711: Typechecker assertion failure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): And now, the Core Lint error is fixed, too. There was a `tcSubType` call in !TcPat that was the wrong way round. This fix will come in my next raft of fixes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 19:28:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 19:28:50 -0000 Subject: [GHC] #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on In-Reply-To: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> References: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> Message-ID: <062.90e4fb2b1246c69fec0fda53f8adc111@haskell.org> #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: kcsongor Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: typefamilies Resolution: | trace hangs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2006 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I actually hit this bug locally and so merged @kcsongor's patch. Will push in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 20:26:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 20:26:32 -0000 Subject: [GHC] #11695: On GHCi prompt the arrow (movement) keys create strange character sequences In-Reply-To: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> References: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> Message-ID: <063.1e619d34ee11a0aa1723789a9e3487c0@haskell.org> #11695: On GHCi prompt the arrow (movement) keys create strange character sequences ---------------------------------+-------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by heisenbug): Replying to [comment:4 judahj]: > By any chance are you using tmux or a similar program? If so, check out the instructions here (your symptoms sound similar): > > https://github.com/judah/haskeline/wiki/UsingTmux No `tmux`. My terminal is a simple `xterm`. There are 3 computers involved: * a windows laptop visualizing a VNC session (by RealVNC) * a linux machine (say, `hostA`) running `vncserver` * another linux server on which I am `slogin`-ed named `hostB`. `hostB` runs `ghci` and has `export DISPLAY=hostA:2` in effect. So all X visuals are being painted into the `vncserver` session. > > Otherwise, can you give a little more information about your setup? > - What is the value of $TERM > - What terminal program (e.g. xterm) you're using > - To try to figure out exactly what's confusing ghci: can you explain more what "$DISPLAY is a vnc session on a different box" means? I'm not familiar with that kind of setup. Which machine are you actually typing text into, and how is that text being relayed to the server that's actually running ghci? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 20:41:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 20:41:13 -0000 Subject: [GHC] #11684: Fix tests with Clang In-Reply-To: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> References: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> Message-ID: <059.b7611f4dc70ef2991e4963d8b51ab691@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ?Phab:D1988 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"46f9a476e17714e27d893b491cc0dcf68c745249/ghc" 46f9a47/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="46f9a476e17714e27d893b491cc0dcf68c745249" DriverPipeline: Fix 'unused arguments' warnings from Clang When using Clang as the C compiler, over 100 tests were failing due to Clang reporting that some command line arguments were not being used. These warnings only occur when Clang is compiling assembler files which happens in two places, one of which already conditionally adding `-Qunused-arguments` to the command line when the compiler was Clang. This fixes the other. Test Plan: validate with clang as the C compiler Reviewers: bgamari, hvr, austin, rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1998 GHC Trac Issues: #11684 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 22:20:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 22:20:32 -0000 Subject: [GHC] #8132: Warning for Typeable instances misplaced In-Reply-To: <046.14a03f533dbc77b45f9192db7d06ef76@haskell.org> References: <046.14a03f533dbc77b45f9192db7d06ef76@haskell.org> Message-ID: <061.7a2181c623932607b551c0be3680fb29@haskell.org> #8132: Warning for Typeable instances misplaced -------------------------------------+------------------------------------- Reporter: scottgw | Owner: dreixel Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In the new type-indexed `Typeable` scheme (see #11011) we will hide `typeOf#` altogether. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 23:00:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 23:00:53 -0000 Subject: [GHC] #11714: Kind of (->) type constructor is overly constrained Message-ID: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> #11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the `(->)` type constructor has kind `* -> * -> *` (with some magic to make infix work for unlifted types. To quote the comment attached to `TysPrim.funTyCon`, > You might think that `(->)` should have type `?? -> ? -> *`, and you'd be right. But if we do that we get kind errors when saying > {{{ > instance Control.Arrow (->) > }}} > because the expected kind is `* -> * -> *`. The trouble is that the expected/actual stuff in the unifier does not go contra-variant, whereas the kind sub-typing does. Sigh. It really only matters if you use `(->)` in a prefix way, thus: `(->) Int# Int#`. And this is unusual. because they are never in scope in the source }}} This seems to imply that the restrictive kind arose out of the old subkinding story. Now that we have a more principled way of dealing with non-lifted kinds it seems we allow prefix uses to be as polymorphic as infix uses. Something like, {{{#!hs (->) :: forall (rep1 :: RuntimeRep) (rep2 :: RuntimeRep). TYPE rep1 -> TYPE rep2 -> * }}} Not only would this be a win for consistency, but it may also address some of the Core Lint issues that I'm seeing in #11011. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 23:04:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 23:04:17 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.d197a1292975868180055436662cf1a3@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2010 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The Core Lint violation in `T11120` appears to be the result of `(->)` overly constrained kind when used in prefix position, `* -> * -> *`, {{{ Kind application error in type ?(->) Char#? Function kind = * -> * -> * Arg kinds = [(Char#, TYPE 'WordRep)] }}} Where this type appears in a use of `mkTrApp`, {{{#!hs mkTrApp @* @* @((->) Char#) @CharHash ... }}} which was produced as evidence for the `Typeable` representation for, {{{#!hs data CharHash = CharHash Char# }}} I've opened #11714 to track the overly constrained kind of `(->)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 23:10:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 23:10:38 -0000 Subject: [GHC] #11714: Kind of (->) type constructor is overly constrained In-Reply-To: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> References: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> Message-ID: <061.8642cc4eb42148005a2723168ddaac68@haskell.org> #11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): As described in ticket:11011#comment:39, the current constrained kind of `(->)` causes Core lint violations on my `wip/ttypeable` branch. The Core lint violation in `T11120` mentioned appears to be the result of `(->)` overly constrained kind when used in prefix position, `* -> * -> *`, {{{ Kind application error in type ?(->) Char#? Function kind = * -> * -> * Arg kinds = [(Char#, TYPE 'WordRep)] }}} Where this type appears in a use of `mkTrApp`, {{{#!hs mkTrApp @* @* @((->) Char#) @CharHash ... }}} which was produced as evidence for the `Typeable` representation for, {{{#!hs data CharHash = CharHash Char# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 23:55:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 23:55:53 -0000 Subject: [GHC] #11715: There's something fishy going on with Constraint Message-ID: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> #11715: There's something fishy going on with Constraint -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I first noticed something was a bit odd with `Constraint` when chasing #11334. Consider this testcase, {{{#!hs import Data.Typeable main = do print $ typeRep (Proxy :: Proxy Eq) print $ typeOf (Proxy :: Proxy Eq) }}} With `ghc-8.0` this will produce, {{{ Eq Proxy (* -> *) Eq }}} Notice the second line; GHC seems to be claiming that `Eq :: * -> *`, which is clearly nonsense. I believe this issue may be the cause of some of the testsuite failures that I'm seeing on #11011. Unfortunately I haven't the foggiest where this issue might originate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 16 23:58:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Mar 2016 23:58:00 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.6a3535c0fb067a2a583d928c988154a1@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2010 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I believe the failure of the `TypeOf` test (which claims that things of kind `Constraint` are instead of kind `*`) may be related to a latent bug that I noticed a while back when working on #11334. I've posted a description and reproduction case as #11715. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 00:10:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 00:10:58 -0000 Subject: [GHC] #11715: There's something fishy going on with Constraint In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.cb4231d2f356c237a9e835f0fe3f2bc8@haskell.org> #11715: There's something fishy going on with Constraint -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I just remembered another little nugget that I noticed during #11334: There is a bizarre order dependence to this bug. For instance, {{{#!hs main = do print $ typeof (proxy :: proxy (Eq int)) print $ typeof (proxy :: proxy Eq) }}} will emit, {{{ Proxy Constraint (Eq Int) Proxy (Constraint -> Constraint) Eq }}} Whereas if you flip the order of the `print`s (presumably such that the solver encounters `*` first rather than `Constraint`) you see what I reported in the ticket description, {{{ Proxy (* -> *) Eq Proxy * (Eq Int) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 00:21:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 00:21:56 -0000 Subject: [GHC] #11695: On GHCi prompt the arrow (movement) keys create strange character sequences In-Reply-To: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> References: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> Message-ID: <063.9edd180db9480ed50a72387e21295129@haskell.org> #11695: On GHCi prompt the arrow (movement) keys create strange character sequences ---------------------------------+-------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by judahj): Thanks for the details. To clarify, what machine are you slogin'd *from* into hostB, is it your laptop or hostA? If your laptop, what Windows program are you using to do the connection? (More details: I'm trying to reason about the chain of events from you pressing your key to it getting received by gghci as the character sequence "\ESC[A" (or similar). The problem is that gghci (really, haskeline) expects to read those characters in a single block, but in your setup they're arriving separately for some reason.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 00:38:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 00:38:51 -0000 Subject: [GHC] #11715: There's something fishy going on with Constraint In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.641e32811f114e09bda70ec39510855f@haskell.org> #11715: There's something fishy going on with Constraint -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So I believe that the culprit lies somewhere in the simplifier since the `dump-ds` output looks reasonable but `dump-simpl` reveals that the `Typeable Proxy` dictionary has been floated to the top level and has been applied to either `*` or `Constraint`, depending upon the order of the `print` statements, and that the same dictionary is used in both `print`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 00:47:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 00:47:33 -0000 Subject: [GHC] #11715: There's something fishy going on with Constraint In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.1c393a40efbca81850ab0611c8eac58c@haskell.org> #11715: There's something fishy going on with Constraint -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -2,1 +2,1 @@ - #11334. Consider this testcase, + #11334. Consider this testcase (`-O0` is sufficient), New description: I first noticed something was a bit odd with `Constraint` when chasing #11334. Consider this testcase (`-O0` is sufficient), {{{#!hs import Data.Typeable main = do print $ typeRep (Proxy :: Proxy Eq) print $ typeOf (Proxy :: Proxy Eq) }}} With `ghc-8.0` this will produce, {{{ Eq Proxy (* -> *) Eq }}} Notice the second line; GHC seems to be claiming that `Eq :: * -> *`, which is clearly nonsense. I believe this issue may be the cause of some of the testsuite failures that I'm seeing on #11011. Unfortunately I haven't the foggiest where this issue might originate. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 00:57:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 00:57:12 -0000 Subject: [GHC] #11715: There's something fishy going on with Constraint In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.9b0ac1b19abd841b4fa29c7f3e750d23@haskell.org> #11715: There's something fishy going on with Constraint -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I haven't looked at the code surrounding this, but here's a plausible story: - {{{* `eqType` Constraint}}} evaluates to `True`, in case you didn't know. This fact is necessary in order to simplify Core more aggressively, as I understand it. - The instance lookup mechanism looks for cached values. (See !TcInteract, line 1306.) An instance for `*` will serve nicely as an instance for `Constraint`. - So once an instance for `*` is found, that one is used for `Constraint` as well. This does not lead to any Core Lint problems (that is, it's perfectly type safe), because of my first bullet point. Of course, `*` and `Constraint` are not equal in Haskell! One long-term solution I have for this is to make `* ~R Constraint` but not `* ~N Constraint`, as we have it now. But roles in kinds are most certainly a story for another day. I do believe that a working solution is easy enough, though: just add a check, using `tcEqType`, in `TcSMonad.findDict`. `tcEqType` is careful ''not'' to relate `*` and `Constraint`. Recall that Core Lint can never check that we're doing this right, sadly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 02:27:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 02:27:22 -0000 Subject: [GHC] #11716: Make TypeInType stress test work Message-ID: <047.dab3e539603ee118886dc0a739516c12@haskell.org> #11716: Make TypeInType stress test work -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I used the attached file during my job talk. It is good `TypeInType` stress test. This bug is to track several fixes that have been necessary to get it working. I have these fixes locally and will push in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 02:29:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 02:29:20 -0000 Subject: [GHC] #11716: Make TypeInType stress test work In-Reply-To: <047.dab3e539603ee118886dc0a739516c12@haskell.org> References: <047.dab3e539603ee118886dc0a739516c12@haskell.org> Message-ID: <062.e81c1f8b1ba40241fe57dd716355a053@haskell.org> #11716: Make TypeInType stress test work -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * Attachment "RaeJobTalk.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 02:44:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 02:44:08 -0000 Subject: [GHC] #11714: Kind of (->) type constructor is overly constrained In-Reply-To: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> References: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> Message-ID: <061.8fba0886351e6ce945fa4a2eeebdf77c@haskell.org> #11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): > {{{#!hs > (->) :: forall (rep1 :: RuntimeRep) (rep2 :: RuntimeRep). > TYPE rep1 -> TYPE rep2 -> * > }}} Yes, this is exactly what we need. But I daresay this will be a performance disaster, littering Core with extra `RuntimeRep` arguments at every arrow, and requiring a substitution to get `->`'s kind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 06:39:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 06:39:59 -0000 Subject: [GHC] #11702: Constant folding on 'mod/Word' - incorrect result In-Reply-To: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> References: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> Message-ID: <060.2a11b77018599f82fb900b0305687b6a@haskell.org> #11702: Constant folding on 'mod/Word' - incorrect result -------------------------------------+------------------------------------- Reporter: ondrap | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Prelude | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2004 Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): FWIW, T11702 passes unexpectedly on powerpc64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 08:09:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 08:09:40 -0000 Subject: [GHC] #11695: On GHCi prompt the arrow (movement) keys create strange character sequences In-Reply-To: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> References: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> Message-ID: <063.e96882abbd7d45bf9a59da6fcafddab5@haskell.org> #11695: On GHCi prompt the arrow (movement) keys create strange character sequences ---------------------------------+-------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by heisenbug): Replying to [comment:6 judahj]: > Thanks for the details. To clarify, what machine are you slogin'd *from* into hostB, is it your laptop or hostA? If your laptop, what Windows program are you using to do the connection? It is not the laptop. The keystroke/mousing/visualization chain is: {{{ laptop <--vnc--> hostA <--ssh--> hostB }}} > > (More details: I'm trying to reason about the chain of events from you pressing your key to it getting received by gghci as the character sequence "\ESC[A" (or similar). The problem is that ghci (really, haskeline) expects to read those characters in a single block, but in your setup they're arriving separately for some reason.) So `ghci` actually utilizes `haskeline`? I heard something to the contrary before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 08:41:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 08:41:01 -0000 Subject: [GHC] #11714: Kind of (->) type constructor is overly constrained In-Reply-To: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> References: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> Message-ID: <061.74d3bf9684a1d0c10109ae4cfcee6681@haskell.org> #11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Maybe we can have * Saturated applications of arrow, with its own kinding rule. Actually it's represented as `ForAllTy (Anon ty1) ty2` so looks nothing like `TyConApp`, and there is no `TyCon` involved. * `(->)` with the complicated kind you give above, used for unsaturated partial applications. Now `splitTyConApp` on a `ForallTy (Anon _) _` would have to add those missing kind `RuntimeRep` arguments, but it can do that easily enough. Might that get the best of both worlds? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 08:53:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 08:53:50 -0000 Subject: [GHC] #11715: There's something fishy going on with Constraint In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.47c79126a1209719354a011a1881154a@haskell.org> #11715: There's something fishy going on with Constraint -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Indeed; see this (in `Kind.hs`) {{{ Note [Kind Constraint and kind *] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The kind Constraint is the kind of classes and other type constraints. The special thing about types of kind Constraint is that * They are displayed with double arrow: f :: Ord a => a -> a * They are implicitly instantiated at call sites; so the type inference engine inserts an extra argument of type (Ord a) at every call site to f. However, once type inference is over, there is *no* distinction between Constraint and *. Indeed we can have coercions between the two. Consider class C a where op :: a -> a For this single-method class we may generate a newtype, which in turn generates an axiom witnessing C a ~ (a -> a) so on the left we have Constraint, and on the right we have *. See Trac #7451. Bottom line: although '*' and 'Constraint' are distinct TyCons, with distinct uniques, they are treated as equal at all times except during type inference. }}} This is a true wart, which I have always longed to expunge. And actually, now we heterogeneous equalities, maybe we can!! Perhaps we could have {{{ newtype C a :: Constraint = MkC (a->a) -- Not legal source code }}} leading to an axiom {{{ axC :: forall (a:*). (C a :: Constraint) ~R (a->a :: *) }}} That is, `*` and `Constraint` both classify values, but different kinds of values. Is that ok? Or, I suppose we could say {{{ type Constraint = TYPE ConstraintRep }}} That would be even better, because we can certainly have `Ord a -> a` (at least in Core), and even `((->) (Ord a))`. Does that seem plausible? I like it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 09:08:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 09:08:44 -0000 Subject: [GHC] #11715: There's something fishy going on with Constraint In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.d93a8c73023c6d2c63c2cba533354089@haskell.org> #11715: There's something fishy going on with Constraint -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) Comment: The current behaviour definitely sounds suspicious. I notice that 8.0 RC2 accepts the following: {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies #-} import Data.Kind type family F (a :: *) :: * type instance F Type = Int type instance F Constraint = Bool }}} But surely if `Type ~ Constraint` in Core, and this definition is accepted, then Core is unsound? I'm not sure if this can be exploited in surface Haskell, but Ben's example makes me think it might. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 10:04:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 10:04:18 -0000 Subject: [GHC] #11580: panic on incompatible options In-Reply-To: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> References: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> Message-ID: <059.6df3a17315dea95864e5df0a7bee7407@haskell.org> #11580: panic on incompatible options -------------------------------------+------------------------------------- Reporter: dougm | Owner: kaiha Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1925 Wiki Page: | -------------------------------------+------------------------------------- Changes (by kaiha): * owner: => kaiha -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 11:11:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 11:11:25 -0000 Subject: [GHC] #11580: panic on incompatible options In-Reply-To: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> References: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> Message-ID: <059.3df940f34f2a5467031cfb2ab7aaedfe@haskell.org> #11580: panic on incompatible options -------------------------------------+------------------------------------- Reporter: dougm | Owner: kaiha Type: bug | Status: patch Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1925 Wiki Page: | Phab:D2013 -------------------------------------+------------------------------------- Changes (by kaiha): * status: new => patch * differential: Phab:D1925 => Phab:D1925 Phab:D2013 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 11:22:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 11:22:49 -0000 Subject: [GHC] #11670: Generalisation behaviour of partial type signatures (was: Can't infer type) In-Reply-To: <051.c0c820eeed6752ec1594c0814ddee3a0@haskell.org> References: <051.c0c820eeed6752ec1594c0814ddee3a0@haskell.org> Message-ID: <066.d8be584c1435f72bea465ab6499c232d@haskell.org> #11670: Generalisation behaviour of partial type signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 12:59:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 12:59:41 -0000 Subject: [GHC] #9803: Poor error message for unbound variable in pattern synonym In-Reply-To: <047.24e2cdf338c6978d0128990061b5e44d@haskell.org> References: <047.24e2cdf338c6978d0128990061b5e44d@haskell.org> Message-ID: <062.7078431d8a6e4e76c967886d497a15c2@haskell.org> #9803: Poor error message for unbound variable in pattern synonym -------------------------------------+------------------------------------- Reporter: goldfire | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed Comment: Simon got to this whilst doing some other cleanup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 12:59:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 12:59:59 -0000 Subject: [GHC] #10303: Make it easier to print stack traces when debugging GHC itself In-Reply-To: <047.fb5dc8e7e9aecf901551c4f1b06d6dc4@haskell.org> References: <047.fb5dc8e7e9aecf901551c4f1b06d6dc4@haskell.org> Message-ID: <062.d75126f37ff84c439ba1ac7e6accede8@haskell.org> #10303: Make it easier to print stack traces when debugging GHC itself -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: mpickering => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 13:38:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 13:38:57 -0000 Subject: [GHC] #11713: STM Finalizers In-Reply-To: <051.e60097434689e0df7cd503283058f128@haskell.org> References: <051.e60097434689e0df7cd503283058f128@haskell.org> Message-ID: <066.5c3f96e992918a411047b980b755a445@haskell.org> #11713: STM Finalizers -------------------------------------+------------------------------------- Reporter: mc.schroeder | Owner: mc.schroeder Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2011 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): This looks like a big extra burden on the implementation - an extra field in every TVar, two fields in the atomically frame, and lots of complexity. I'd really rather avoid this if we can. e.g. for serialization, I would do it exactly the way that Simon suggests, the transaction should add its serialization instructions to a TQueue or something that is processed by a separate thread. If you want to also have the current thread wait until the serialization has completed, then you can program that too using a TVar. This also allows more concurrency than your finalizer, because it doesn't have to freeze any TVars. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 14:05:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 14:05:13 -0000 Subject: [GHC] #11711: Typechecker assertion failure In-Reply-To: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> References: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> Message-ID: <061.5abbce4636b5dbdf6fb1f371b40ff7f4@haskell.org> #11711: Typechecker assertion failure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"b5565f1a79fd24fc45a6f1a58821a317852d4b89/ghc" b5565f1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b5565f1a79fd24fc45a6f1a58821a317852d4b89" Fix #11711. There were two bugs here, both simple: we need to filter out covars before calling isMetaTyVar in the solver, and TcPat had a tcSubType the wrong way round. test case: dependent/should_compile/T11711 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 14:05:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 14:05:13 -0000 Subject: [GHC] #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on In-Reply-To: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> References: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> Message-ID: <062.37b0c8061fb72e8a5a1d850718be357f@haskell.org> #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: kcsongor Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: typefamilies Resolution: | trace hangs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2006 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c5ed41cbcaa40068763c8bd01badcada38cdbd03/ghc" c5ed41c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c5ed41cbcaa40068763c8bd01badcada38cdbd03" typechecker: fix trac issue #11708 Summary: Fixes T11708 Reviewers: austin, bgamari, goldfire, simonpj Reviewed By: goldfire, simonpj Subscribers: simonpj, goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2006 GHC Trac Issues: #11708 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 14:05:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 14:05:13 -0000 Subject: [GHC] #11716: Make TypeInType stress test work In-Reply-To: <047.dab3e539603ee118886dc0a739516c12@haskell.org> References: <047.dab3e539603ee118886dc0a739516c12@haskell.org> Message-ID: <062.a4a995df82a688b6ece55b3784534644@haskell.org> #11716: Make TypeInType stress test work -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"3fe87aa00ac05f1abea22ea58d51ecc1e3073d19/ghc" 3fe87aa0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3fe87aa00ac05f1abea22ea58d51ecc1e3073d19" Fix #11716. There were several smallish bugs here: - We had too small an InScopeSet when rejigging GADT return types. - When adding the extra_tvs with a datatype kind signature, we were sometimes changing Uniques of an explicitly bound kind var. - Using coercionKind in the flattener got the wrong visibility for a binder. Now we just zonk to get what we need. Test case: dependent/should_compile/RaeJobTalk }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 14:05:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 14:05:13 -0000 Subject: [GHC] #11512: An unwritten kind variable is "specified", when it shouldn't be. In-Reply-To: <047.7a36187500c6876edf467692a28ef5b3@haskell.org> References: <047.7a36187500c6876edf467692a28ef5b3@haskell.org> Message-ID: <062.c1c2202a52b092f76b00320f8e5bb135@haskell.org> #11512: An unwritten kind variable is "specified", when it shouldn't be. -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"f4f315a37470ce86e3eadeb328d0d3a9242f3097/ghc" f4f315a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f4f315a37470ce86e3eadeb328d0d3a9242f3097" Fix #11512 by getting visibility right for methods Test case: typecheck/should_compile/T11512 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 14:07:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 14:07:15 -0000 Subject: [GHC] #11713: STM Finalizers In-Reply-To: <051.e60097434689e0df7cd503283058f128@haskell.org> References: <051.e60097434689e0df7cd503283058f128@haskell.org> Message-ID: <066.cc5dfb435b051986bdfbf48e271be602@haskell.org> #11713: STM Finalizers -------------------------------------+------------------------------------- Reporter: mc.schroeder | Owner: mc.schroeder Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2011 Wiki Page: | -------------------------------------+------------------------------------- Comment (by fryguybob): I also am not convinced that the cost of the implementation changes are worth the feature. It isn't completely clear to me how to write the IO actions safely. Programmers might not always know what `TVar`s they are depending on and there also might be some other ways to deadlock due to transitive dependencies on `TVar`s (Data invariants, blocked transactions). I will take some time to look through everything very closely and hopefully run some performance comparisons as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 14:41:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 14:41:31 -0000 Subject: [GHC] #11713: STM Finalizers In-Reply-To: <051.e60097434689e0df7cd503283058f128@haskell.org> References: <051.e60097434689e0df7cd503283058f128@haskell.org> Message-ID: <066.1f66a95a112f6c52caba11ccee3cc733@haskell.org> #11713: STM Finalizers -------------------------------------+------------------------------------- Reporter: mc.schroeder | Owner: mc.schroeder Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2011 Wiki Page: | -------------------------------------+------------------------------------- Changes (by fryguybob): * cc: fryguybob (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 15:24:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 15:24:03 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.d56465fdafb881dc3e4c49326e62f4b7@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: kaiha Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1514 Wiki Page: | -------------------------------------+------------------------------------- Changes (by kaiha): * owner: => kaiha -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 15:50:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 15:50:54 -0000 Subject: [GHC] #11717: Way to dump cmm only once Message-ID: <046.147581339d89f71c221c940bc7bdc90a@haskell.org> #11717: Way to dump cmm only once -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (CodeGen) | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The current way to dump Cmm output is `-ddump-cmm`, but that dumps Cmm repeatedly, of every stage, similar to `-ddump-verbose-core2core`. This is often confusing. I propose that `-ddump-cmm` dumps only the initial Cmm code, that the flag `-ddump-simpl-cmm` dumps the final Cmm code, and that `-ddump-verbose-cmm` dumps every stage. Shoudn?t be hard to do for a newcomer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 15:52:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 15:52:22 -0000 Subject: [GHC] #11717: Way to dump cmm only once In-Reply-To: <046.147581339d89f71c221c940bc7bdc90a@haskell.org> References: <046.147581339d89f71c221c940bc7bdc90a@haskell.org> Message-ID: <061.f7171edfae51cabad60d11a3818784ba@haskell.org> #11717: Way to dump cmm only once -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (CodeGen) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Also note that there currently seems to be a {{{ -ddump-opt-cmm Dump the results of C-- to C-- optimising passes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 16:14:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 16:14:52 -0000 Subject: [GHC] #11715: There's something fishy going on with Constraint In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.723570fcc70a82983b689260e93d37f3@haskell.org> #11715: There's something fishy going on with Constraint -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): NB: as things stand, from `axC` we could deduce `Constraint ~N *`, which we definitely don't want. To solve this we could restrict the coercion language a little, so that you can't extract a kind equality from a representational type equality. (This might be good anyway. It's weird that you can currently get a ''nominal'' kind equality from a ''representational'' type equality. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 18:29:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 18:29:43 -0000 Subject: [GHC] #11714: Kind of (->) type constructor is overly constrained In-Reply-To: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> References: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> Message-ID: <061.a12f4993a24c05f7d67bdcd44b826813@haskell.org> #11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Maybe. We'd have to write it and test its performance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 18:31:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 18:31:42 -0000 Subject: [GHC] #10075: Muddling Constraint and * means that Core is inconsistent In-Reply-To: <047.b702f44c1941de44349c325db22c80fd@haskell.org> References: <047.b702f44c1941de44349c325db22c80fd@haskell.org> Message-ID: <062.2e85b89336723e0fe76107d18748f8ab@haskell.org> #10075: Muddling Constraint and * means that Core is inconsistent -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: This has been re-reported as #11715, but the discussion there is better than the discussion here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 18:32:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 18:32:36 -0000 Subject: [GHC] #11715: There's something fishy going on with Constraint In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.5eee522fd36b3a8c550d58a7d8e38ae9@haskell.org> #11715: There's something fishy going on with Constraint -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This was previously reported as #10075, but the commentary on that ticket adds little to the discussion here. I've closed the other ticket as a dup of this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 18:33:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 18:33:09 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.7489ba21624f62df232727f068c6ef52@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: kaiha Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2015 Wiki Page: | -------------------------------------+------------------------------------- Changes (by kaiha): * status: new => patch * differential: Phab:D1514 => Phab:D2015 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 18:37:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 18:37:27 -0000 Subject: [GHC] #11698: GHC's tct_closed flag is not being set correctly In-Reply-To: <046.7686f983b8149fd1d6dcacf21545b08a@haskell.org> References: <046.7686f983b8149fd1d6dcacf21545b08a@haskell.org> Message-ID: <061.f7d049ba25f64b629d5cbf06a154201c@haskell.org> #11698: GHC's tct_closed flag is not being set correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11656 Related Tickets: | Differential Rev(s): Phab:D2016 Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch * differential: => Phab:D2016 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 18:37:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 18:37:43 -0000 Subject: [GHC] #11711: Typechecker assertion failure In-Reply-To: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> References: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> Message-ID: <061.63de9fbc92ff08be99a6e4726da92a82@haskell.org> #11711: Typechecker assertion failure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | dependent/should_compile/T11711 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_compile/T11711 * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 18:38:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 18:38:19 -0000 Subject: [GHC] #11512: An unwritten kind variable is "specified", when it shouldn't be. In-Reply-To: <047.7a36187500c6876edf467692a28ef5b3@haskell.org> References: <047.7a36187500c6876edf467692a28ef5b3@haskell.org> Message-ID: <062.b8db659168716dc9e25e3dded188645d@haskell.org> #11512: An unwritten kind variable is "specified", when it shouldn't be. -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11512 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compile/T11512 * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 18:38:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 18:38:27 -0000 Subject: [GHC] #11512: An unwritten kind variable is "specified", when it shouldn't be. In-Reply-To: <047.7a36187500c6876edf467692a28ef5b3@haskell.org> References: <047.7a36187500c6876edf467692a28ef5b3@haskell.org> Message-ID: <062.c7dc32d687f4b09fa7f98bc979dffba9@haskell.org> #11512: An unwritten kind variable is "specified", when it shouldn't be. -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11512 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 18:38:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 18:38:55 -0000 Subject: [GHC] #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on In-Reply-To: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> References: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> Message-ID: <062.44af951fb4722588b001a1213cbeff27@haskell.org> #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: kcsongor Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: typefamilies Resolution: | trace hangs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2006 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => merge * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 18:39:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 18:39:22 -0000 Subject: [GHC] #11716: Make TypeInType stress test work In-Reply-To: <047.dab3e539603ee118886dc0a739516c12@haskell.org> References: <047.dab3e539603ee118886dc0a739516c12@haskell.org> Message-ID: <062.d1b8cddab429d14bcbc266efab67a388@haskell.org> #11716: Make TypeInType stress test work -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/RaeJobTalk Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_compile/RaeJobTalk * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 17 21:23:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Mar 2016 21:23:42 -0000 Subject: [GHC] #11542: Profiling call count frequently 0 when it shouldn't be In-Reply-To: <047.b0ecc7025940d726f91548515350f7d9@haskell.org> References: <047.b0ecc7025940d726f91548515350f7d9@haskell.org> Message-ID: <062.720149d25a7135d47edadad40864589d@haskell.org> #11542: Profiling call count frequently 0 when it shouldn't be -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nad): I don't know if this is related, but I've encountered an example where the entries count is 0, but the ''individual'' %time and %alloc numbers are substantial. This is using GHC 7.10.3. I found a report of a similar problem: Profiling trouble by Ferenc Wagner (https://mail.haskell.org/pipermail/glasgow-haskell- users/2003-January/004727.html). The code attached to the report compiles if you modify some haskell98 imports: {{{ sed -ri -e 's/import Complex/import Data.Complex/' -e 's/import qualified List/import qualified Data.List as List/' *hs ghc --make Show2.hs -O -auto-all -prof ./Show2 +RTS -p }}} When I ran this sequence of commands now I obtained a profiling report with the following line: {{{ main Main 109 0 10.5 0.8 10.5 0.8 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 18 00:40:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Mar 2016 00:40:03 -0000 Subject: [GHC] #11635: Higher-rank kind in datatype definition rejected In-Reply-To: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> References: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> Message-ID: <060.4834ed562484faf5d7605dd3734070c5@haskell.org> #11635: Higher-rank kind in datatype definition rejected -------------------------------------+------------------------------------- Reporter: phadej | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ocharles): * cc: ocharles (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 18 09:48:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Mar 2016 09:48:41 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.97f7c74968e6a3d1fc8085e10b14e1e7@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Nooo, where is the longish text I wrote here yesterday? :-( I hate it when that happens. Darn, let?s see what I can remember. grnrl. > I thought I only enabled it for thunks, but it also seems to be present for two functions, and only there count multiple entries... Weird. Still weird. If I add my counting indirection to everything, I get segfaults. So I guard it with `idRepArity id == 0` for now, thinking I would only add it to thunks. But the above report shows some that have ?Non-void arguments?, but still `idRepArity id == 0`; this is one example: {{{ let { sat_s7uy [Occ=Once] :: GHC.Types.Double -> GHC.Types.Double [LclId, Str=DmdType] = \r srt:SRT:[] [x_s7ux] GHC.Float.timesDouble x_s7ux y_s7uu; } in case Main.$wintegrate1D 0.0## ww3_s7uw sat_s7uy of ww4_s7uz { __DEFAULT -> GHC.Types.D# [ww4_s7uz]; }; }}} Why does this have a zero `idRepArity`? Why does it not crash? Is it because it is used as an argument to a function, and hence no fast calls occur? > Also, these 500000-times allocated thunks are not really unused, are they?. No, they are not. These are constructors, where entries are not counted. I extended the ticky report to be a bit more explicit about the kind of things these names are, i.e. distinguish cons from thunks, and for thunks, indicate which are one-shot and which are static. > Two total entries for a thunk (sat_s7vH) that has been allocated once and called once? Maybe there was a heap check inbetween? No, this is simply a bug in the ticky code, where there are two calls to `tickyEnterThunk` (likely introduced by 99d4e5b4a0bd32813ff8c74e91d2dcf6b3555176, possibly due to a merge mistake). The latter two improvements are at Phab:D2014, mostly to get phab to test the commit (which does not seem to happen... why?). I now need to wrap my head around how to do the counting for functions. My counting indirection does not work as it is, because functions are entered differently. So I either have to create a counting indirection that works for functions (but I don?t know yet if a single one would work for all types of functions), or add the counting code to the function itself. In this case, the function closure needs an additional field for the counter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 18 09:59:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Mar 2016 09:59:35 -0000 Subject: [GHC] #11718: Disable the Preview button on trac Message-ID: <046.b5e86a3072a06a03ef6505634f79ef6f@haskell.org> #11718: Disable the Preview button on trac -------------------------------------+------------------------------------- Reporter: nomeata | Owner: hvr Type: feature | Status: new request | Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- More than once, I lost comments to track. My current hypothesis is that I accidentally clicked ?Preview? instead of ?Send changes? and closed the tab or browser afterwards, without noticing that I did not actually submit them. With the live preview, the Preview button is not as useful as it could be anyways. So maybe simply removing that button would do more good than harm. Erikd +1ed my request on IRC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 18 10:16:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Mar 2016 10:16:14 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.41cf8c809ba0e1369ec8a38edd50d110@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If you want to count how many times a function is entered, why not just put a ticky counter at the start of the function's code? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 18 10:17:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Mar 2016 10:17:58 -0000 Subject: [GHC] #11718: Disable the Preview button on trac In-Reply-To: <046.b5e86a3072a06a03ef6505634f79ef6f@haskell.org> References: <046.b5e86a3072a06a03ef6505634f79ef6f@haskell.org> Message-ID: <061.2c7d2ae48024903ac82e6641c4ef5204@haskell.org> #11718: Disable the Preview button on trac -------------------------------------+------------------------------------- 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 | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I quite often lose edits and it's infuriating. Eg accidentally hitting the back button, or thinking I'm in emacs and typing some key combination that does something incomprehensible but ends up nuking my edit buffer. I wish Trac remembered drafts, like say Gmail does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 18 10:18:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Mar 2016 10:18:18 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.019b6e4412b974f96f02b380dc81be4a@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > If you want to count how many times a function is entered, why not just put a ticky counter at the start of the function's code? The problem is that I need to count each dynamic instance separately. So I need a separate counter for each allocated closure, so the only place it can go is inside the closer as another non-pointer argument. (For static functions, things are easier of course.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 18 10:20:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Mar 2016 10:20:11 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.7fb6bc7fdbaaa3b5b2b2bedbddec975c@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Oh ok, well, same deal. When you enter a (dynamically allocated) function there's a register pointing to the function closure. So the ticky code at the start of the function's code can bump the count in `ClosurePtr[4]` (or whatever the appropriate offset is. No? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 18 10:22:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Mar 2016 10:22:15 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.670f16850721c79c82f63cdac7cec55e@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Yes! That?s the idea, and conceptually straight-forward. I?m just a bit worried that the change will be too invasive to the compiler?s code (info tables, offset calculation etc.) But I guess I should just do it, and see how bad it is. In the worst case we keep it on a separate branch just for the investigation for the paper. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 18 11:19:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Mar 2016 11:19:26 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families Message-ID: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket came out of a discussion with Richard in this mailing list post: https://mail.haskell.org/pipermail/haskell- cafe/2016-March/123462.html Here's the code that should work, but doesn't: {{{ import Data.Kind data TyFun :: * -> * -> * type a ~> b = TyFun a b -> * type family (f :: a ~> b) @@ (x :: a) :: b data Null a = Nullable a | NotNullable a type family ((f :: b ~> c) ? (g :: a ~> b)) (x :: a) :: c where (f ? g) x = f @@ (g @@ x) type family BaseType (k :: forall a. a ~> Type) (x :: b) :: Type where -- this fails :( -- BaseType k x = (@@) k x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 18 14:46:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Mar 2016 14:46:43 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.b713fcc2124dc0e0873ea9c620710034@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Ok, I implemented it, and nofib still runs (yay). The code is yet unrepresentable, though :-) Preliminary observations (gotta run now): In all of nofib, there is one single entry thunk that is entered multiple times (something in `gamteb`, allocated 2048 times, each time with two entries). Did not investigate yet, though. On first glance, plenty of thunks which appear to be single-entry, but are not marked as such. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 18 16:44:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Mar 2016 16:44:14 -0000 Subject: [GHC] #11715: There's something fishy going on with Constraint In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.ddee25bb7c73366cf8b3c4ae2ab407d9@haskell.org> #11715: There's something fishy going on with Constraint -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In a phone conversation yesterday we also developed an alternative plan to comment:5, namely '''make `Constraint` and `*` the same in Haskell'''. Thus: * `type Constraint = *`. So the two are the same even in source Haskell. * A type sig like `f :: Int => Int` becomes kind-correct. But we can still rejects it in `checkValidType`, in the same way that we reject higher-rank types when that extension is not enabled. Ditto `f :: Ord a -> Int` '''Disadvantages''' This signature for `f` is currently rejected as ill-kinded: {{{ type family F a :: Constraint type instance F Int = Ord Bool ... f :: F a -> a -- Currently ill-kinded }}} but would now be accepted, because `checkValidType` could not easily reject it. More seriously {{{ g :: F a => a -> a }}} would also be accepted even if `F` plainly returned types not constraints. '''Advantages''' * The proposal would eliminate the need for constraint tuples distinct from ordinary value tuples, which would be good. * If we were to silence `checkValidType` (with a language extension), it would also allow functions like {{{ reify :: c => c with :: c -> (c => r) -> r }}} which allow you to get a dictionary as a value, and use it elsewhere. Currently this requires the "Dict trick": {{{ data Dict c where Dict :: c => Dict c reifyD :: c => Dict c reifyD = Ditc withD :: Dict c -> (c => r) -> r withD Dict k = k }}} but the Dict trick actually does boxing and unboxing because it involves a `data` type. It would be more direct not to require this. * Another example: perhaps `TypeRep a` (the type) and `Typeable a` (the constraint) could be the same thing. Thus {{{ f :: TypeRep a => TypeRep b -> blah }}} would mean that the first arg was passed implicitly and the second implicitly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 18 16:45:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Mar 2016 16:45:21 -0000 Subject: [GHC] #11715: Constraint vs * (was: There's something fishy going on with Constraint) In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.c95e5cdd51e4228914a01e86016cb548@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 18 17:41:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Mar 2016 17:41:05 -0000 Subject: [GHC] #9898: Wanted: higher-order type-level programming In-Reply-To: <045.8f7b834957773169b7810af17c757a81@haskell.org> References: <045.8f7b834957773169b7810af17c757a81@haskell.org> Message-ID: <060.73aa89f3980bf944ab68ede21f798937@haskell.org> #9898: Wanted: higher-order type-level programming -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: kcsongor (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 01:46:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 01:46:03 -0000 Subject: [GHC] #11702: Constant folding on 'mod/Word' - incorrect result In-Reply-To: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> References: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> Message-ID: <060.59b122d5f929437b1b65ba973e6ac224@haskell.org> #11702: Constant folding on 'mod/Word' - incorrect result -------------------------------------+------------------------------------- Reporter: ondrap | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Prelude | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2004 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:5 trommler]: > FWIW, T11702 passes unexpectedly on powerpc64. And on my Mac. And on [https://s3.amazonaws.com/archive.travis- ci.org/jobs/116645450/log.txt Travis]. (The framework failures there are my fault. Will be fixed in my next raft, due tomorrow.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 02:49:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 02:49:11 -0000 Subject: [GHC] #1012: ghc panic with mutually recursive modules and template haskell In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@haskell.org> References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@haskell.org> Message-ID: <059.cabb9c3da7025aca99a8cadbe7b7856e@haskell.org> #1012: ghc panic with mutually recursive modules and template haskell -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | TH_import_loop Blocked By: | Blocking: Related Tickets: #9032 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * cc: mgsloan (added) Comment: I just ran into this as well. There is a fairly generic usecase that requires this: defining TH that generates instances of a class, and then using that TH to generate non-orphan instances. Pretty much the same as the usecase Richard outlines above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 15:14:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 15:14:08 -0000 Subject: [GHC] #11720: pureMD5: Simplifier ticks exhausted Message-ID: <047.b040aecf5498d7034551332304a09b9c@haskell.org> #11720: pureMD5: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC panics with simplifier ticks exhausted on powerpc, powerpc64, and powerpc64le compiling pureMD5: {{{ [ 43s] [1 of 1] Compiling Data.Digest.Pure.MD5 ( Data/Digest/Pure/MD5.hs, dist/build/Data/Digest/Pure/MD5.o ) [...] [ 46s] ghc: panic! (the 'impossible' happened) [ 46s] (GHC version 8.0.0.20160204 for powerpc64le-unknown-linux): [ 46s] Simplifier ticks exhausted [ 46s] When trying UnfoldingDone $ [ 46s] To increase the limit, use -fsimpl-tick-factor=N (default 100) [ 46s] If you need to do this, let GHC HQ know, and what factor you needed [ 46s] To see detailed counts use -ddump-simpl-stats [ 46s] Total ticks: 168807 }}} pureMD5 compiles on i586 and x86_64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 16:56:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 16:56:02 -0000 Subject: [GHC] #11357: Regression when deriving Generic1 on poly-kinded data family In-Reply-To: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> References: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> Message-ID: <065.68b18d7fe09ed1b85b9b88e738e4f4d0@haskell.org> #11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Generics, Resolution: | TypeInType, TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T11357 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, that patch seemed to fix that problem, but it introduced another one. Vanilla datatypes and data family instances are still inconsistent w.r.t. which type variables are considered "instantiated" in a `Generic1` instance. For instance, this is rejected: {{{ ?> data Proxy k (a :: k) = ProxyCon deriving Generic1 :32:43: error: ? Can't make a derived instance of ?Generic1 (Proxy *)?: Proxy must not be instantiated; try deriving `Proxy k a' instead ? In the data declaration for ?Proxy? }}} And rightfully so, since the visible kind binder `k` is instantiated to `*`. But now it's possible to have an equivalent instance for a data family that squeaks past this check! {{{ ?> data family ProxyFam (a :: y) (b :: z) ?> data instance ProxyFam k (a :: k) = ProxyFamCon deriving Generic1 ==================== Derived instances ==================== Derived instances: instance GHC.Generics.Generic1 (Ghci13.ProxyFam *) where ... }}} I need to investigate further to see why this is the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 16:57:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 16:57:56 -0000 Subject: [GHC] #10338: GHC Forgets Constraints In-Reply-To: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> References: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> Message-ID: <062.9b9761cf17630ba1682277082060fe84@haskell.org> #10338: GHC Forgets Constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): If you're not using overlapping instances, then you can solve the problem by imposing {{{#!hs class (Functor t, Num r) => T t r where }}} In that context, the only (hypothetical) downside is that you don't have the option of hiding the constraint. I don't know if that's a real concern. If you are using overlapping instances, ~~you've dug yourself into a hole and I don't have much sympathy for you~~ the `ScopedTypeVariables` work- around doesn't seem too onerous. It would be interesting to see if this can be reproduced using code that makes sense ''without'' `OverlappingInstances`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 18:17:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 18:17:09 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.4e79fb35dd30ea956a561d9cfdbc5615@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): If people want to go forward with desugaring fundeps to type families (sounds great to me), I think it would be lovely to add naming syntax: {{{#!hs class Foo a b c d | (Q, R :: a -> b c), (S :: b d -> a) }}} would desugar to {{{#!hs class (b ~ Q a, c ~ R a, a ~ S b d) => Foo a b c d where type family Q a type family R a type family S b d }}} To work with classes that lack named fundeps, some nasty names could be made available. {{{#!hs class Foo a b c d | a -> b c, b d -> a }}} could desugar to use type families with (exposed, but unlikely) names like `Foo__1_DET_2#`, `Foo__1_DET_3#`, and `Foo__2_4_DET_1#`, naming the positions that determine other positions. It might be good to add dysfunctional "soft dependencies" at the same time, with `~>` syntax and vague semantics to be pinned down later (the idea being that soft dependencies would only guide inference, as best they could, without being relied upon for type checking). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 18:36:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 18:36:57 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.2ce76f6000168f8628e7e0a7b4da1144@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Addendum to the magic name idea: the ordering of fundeps would be irrelevant. So {{{#!hs class Bar a b c | a b -> c }}} and {{{#!hs class Bar a b c | b a -> c }}} would both generate a family named `Bar__1_2_DET_3#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 18:55:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 18:55:27 -0000 Subject: [GHC] #11721: GADT-syntax data constructors don't work well with TypeApplications Message-ID: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> #11721: GADT-syntax data constructors don't work well with TypeApplications -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ data X a where MkX :: b -> Proxy a -> X a }}} According to the rules around specified vs. generalized variables around `TypeApplications`, the type of `MkX` should be {{{ MkX :: forall {k} (b :: *) (a :: k). b -> Proxy a -> X a }}} A few things to note: * The `k` isn't available for `TypeApplications` (that's why it's in braces), because it is not user-written. * The `b` is quantified before the `a`, because `b` comes before `a` in the user-written type signature for `MkX`. Both of these bullets are currently violated. GHCi reports `MkX`'s type as {{{ MkX :: forall k (a :: k) b. b -> Proxy a -> X a }}} It turns out that this is a hard to fix. The problem is that GHC expects data constructors to have their universal variables followed by their existential variables, always. And yet that's violated in the desired type for `MkX`. Furthermore, given the way that GHC deals with GADT return types ("rejigging", in technical parlance), it's inconvenient to get the specified/generalized distinction correct. Given time constraints, I'm afraid fixing this all won't make it for 8.0. Happily, there is are easy-to-articulate rules governing GHC's current (wrong) behavior. In a GADT-syntax data constructor: * All kind and type variables are considered specified and available for visible type application. * Universal variables always come first, in precisely the order they appear in the tycon. Note that universals that are constrained by a GADT return type are missing from the datacon. * Existential variables come next. Their order is determined by a user- written `forall`; or, if there is none, by taking the left-to-right order in the datacon's type and doing a stable topological sort. (This stable topological sort step is the same as for other user-written type signatures.) Despite the existence of these rules, it would still be better not to have special rules for GADT-syntax data constructors. This ticket is intended to capture that eventual goal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 19:23:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 19:23:19 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.5073f173a2943f70c549403184436104@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2009 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"220a0b934c71a8844a14dd8cd67fa0e23f807182/ghc" 220a0b93/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="220a0b934c71a8844a14dd8cd67fa0e23f807182" Add test for #9646 Test Plan: Test that it passes git HEAD and fails with GHC 7.8. Reviewers: bgamari, hvr, austin, goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2009 GHC Trac Issues: #9646 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 19:23:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 19:23:46 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.0f6e65edfa97066ae1da4da64c64886e@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime | Test Case: performance bug | testsuite/tests/simplCore/T9646 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2009 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * testcase: => testsuite/tests/simplCore/T9646 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 19:26:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 19:26:13 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.0b46195acfaebc47d20f27c9a7202752@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: fixed | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T11471 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm a bit confused as to how unboxed tuples fit into this scheme. I bring this up since this now crashes on GHC HEAD: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module Main where import Data.Typeable import GHC.Exts main :: IO () main = print $ typeOf (Proxy :: Proxy (# Int, Int #)) }}} {{{ $ /opt/ghc/head/bin/ghc -O2 -fforce-recomp Example.hs [1 of 1] Compiling Main ( Example.hs, Example.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160317 for x86_64-unknown-linux): tyConRep (#,#) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} (Previously, this was rejected with an error message, since you couldn't put an unlifted type as the argument of `Proxy`.) I notice that there's a single constructor of `RuntimeRep` for unboxed tuples (`UnboxedTupleRep`). Does this mean something like this should be allowed? {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} module Example where import Data.Typeable import GHC.Exts data Wat (a :: TYPE 'UnboxedTupleRep) = Wat a }}} Currently, that fails to compile due to a separate GHC panic: {{{ $ /opt/ghc/head/bin/ghc -O2 -fforce-recomp Example.hs [1 of 1] Compiling Example ( Example.hs, Example.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160317 for x86_64-unknown-linux): unboxed tuple PrimRep Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} But wouldn't this be dangerous anyway? After all, unboxed tuples are supposed to represent arguments on the stack, so couldn't unboxed tuple polymorphic potentially lead to the RTS miscalculating how much data to read? Or am I misreading this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 19:34:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 19:34:56 -0000 Subject: [GHC] #11722: No TypeRep for unboxed tuples Message-ID: <047.62aa410ace38ef8cf0e4ab854da20597@haskell.org> #11722: No TypeRep for unboxed tuples -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This now crashes on GHC HEAD: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module Main where import Data.Typeable import GHC.Exts main :: IO () main = print $ typeOf (Proxy :: Proxy (# Int, Int #)) }}} {{{ $ /opt/ghc/head/bin/ghc -O2 -fforce-recomp Example.hs [1 of 1] Compiling Main ( Example.hs, Example.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160317 for x86_64-unknown-linux): tyConRep (#,#) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} (Previously, this was rejected with an error message, since you couldn't put an unlifted type as the argument of `Proxy`.) (Copied from comment:28:ticket:11471.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 19:36:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 19:36:18 -0000 Subject: [GHC] #11723: TYPE 'UnboxedTupleRep is a lie Message-ID: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> #11723: TYPE 'UnboxedTupleRep is a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From @RyanGlScott, comment:28:ticket:11471: I notice that there's a single constructor of `RuntimeRep` for unboxed tuples (`UnboxedTupleRep`). Does this mean something like this should be allowed? {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} module Example where import Data.Typeable import GHC.Exts data Wat (a :: TYPE 'UnboxedTupleRep) = Wat a }}} Currently, that fails to compile due to a separate GHC panic: {{{ $ /opt/ghc/head/bin/ghc -O2 -fforce-recomp Example.hs [1 of 1] Compiling Example ( Example.hs, Example.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160317 for x86_64-unknown-linux): unboxed tuple PrimRep Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} But wouldn't this be dangerous anyway? After all, unboxed tuples are supposed to represent arguments on the stack, so couldn't unboxed tuple polymorphic potentially lead to the RTS miscalculating how much data to read? Or am I misreading this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 19:37:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 19:37:03 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.cbad1efb9c859258ef3d0766bde807c3@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: fixed | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T11471 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): comment:28 introduces two new, mostly-unrelated bugs. I've spun them off into #11722 and #11723. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 19:38:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 19:38:32 -0000 Subject: [GHC] #11723: TYPE 'UnboxedTupleRep is a lie In-Reply-To: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> References: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> Message-ID: <062.9158303080a6c3c2489e30a8aa513dfa@haskell.org> #11723: TYPE 'UnboxedTupleRep is a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): You're absolutely right. Not only can we not have representation- polymorphic things, we can't have things -- other than plain unboxed tuples -- that have `UnboxedTupleRep`. Thanks for poking on this. Fix to come shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 19:39:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 19:39:52 -0000 Subject: [GHC] #11724: Must check for representation polymorphism in datatype declarations Message-ID: <047.e984e50f4246346ca88e79b8cc73fa2e@haskell.org> #11724: Must check for representation polymorphism in datatype declarations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data Foo (r :: RuntimeRep) (a :: TYPE r) = Foo a }}} panics. It should error instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 19:52:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 19:52:09 -0000 Subject: [GHC] #11723: TYPE 'UnboxedTupleRep is a lie In-Reply-To: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> References: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> Message-ID: <062.068e05f9c136f7ce5d7478efb1bb3bd0@haskell.org> #11723: TYPE 'UnboxedTupleRep is a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Would it be sensible to just change the constructor to: {{{#!hs data RuntimeRep = ... | UnboxedTupleRep [RuntimeRep] }}} Or if we want to avoid conflating `Void#` and `UnboxedTupleRep []`, we could use `UnboxedtupleRep (NonEmpty RuntimeRep)`? That way, {{{#!hs typeOf (Proxy :: Proxy (# Int, Int #)) }}} would give {{{#!hs Proxy (TYPE ('UnboxedTupleRep '[PtrRepLifted, PtrRepLifted])) (# Int, Int #) }}} and thus have unambiguous size? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 19:55:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 19:55:13 -0000 Subject: [GHC] #11722: No TypeRep for unboxed tuples In-Reply-To: <047.62aa410ace38ef8cf0e4ab854da20597@haskell.org> References: <047.62aa410ace38ef8cf0e4ab854da20597@haskell.org> Message-ID: <062.f98e012e40d2ecc68f091b5bca45d964@haskell.org> #11722: No TypeRep for unboxed tuples -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: bgamari (added) Comment: Suspiciously similar shenanigans: {{{#!hs {-# LANGUAGE UnboxedTuples #-} module Main where import Data.Typeable main :: IO () main = print $ typeOf (Proxy :: Proxy (# #)) }}} {{{ $ /opt/ghc/head/bin/ghc -O2 -fforce-recomp Example.hs [1 of 1] Compiling Main ( Example.hs, Example.o ) Example.hs:7:24: error: ? Couldn't match kind ?'GHC.Types.VoidRep? with ?'GHC.Types.UnboxedTupleRep? When matching the kind of ?(# #)? ? In the first argument of ?typeOf?, namely ?(Proxy :: Proxy (# #))? In the second argument of ?($)?, namely ?typeOf (Proxy :: Proxy (# #))? In the expression: print $ typeOf (Proxy :: Proxy (# #)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 19:56:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 19:56:43 -0000 Subject: [GHC] #11723: TYPE 'UnboxedTupleRep is a lie In-Reply-To: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> References: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> Message-ID: <062.ce26569de143c6c521f5a0ab2af0c7a6@haskell.org> #11723: TYPE 'UnboxedTupleRep is a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I thought of that. But GHC's current story around `PrimRep`s -- which is what the code generator uses -- keeps unboxed tuples entirely separate. So I think it's best to echo that here, too. Perhaps we can revisit this later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 20:42:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 20:42:04 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.7b08eb3082b092e86d260079e0bdc6be@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: goldfire => Comment: I'm afraid I have to declare defeat against this ticket. :( I've spent the better part of the last few days trying to understand what's going on here, but failed utterly. I simply cannot find the source of the slowdown. It just seems like ''everything'' is doing more allocation, making it rather hard to find a culprit. I tried putting SCCs on low-level functions, too, but to no avail. The one moment of glory was finding that `tcMatchTys` was taking up 25% of the allocations on T9872c. I identified that the cause was a check to make sure that we don't match with a local, forall-bound variable. Of course, local forall-bound variables are rare, so I optimized the check by seeing if there are any forall-bound variables. This led to a whopping improvement of 20%! But then, inexplicably, when I turn off profiling, the exact same optimization led to no improvement. My tinkering led to a few tiny optimizations, leading to 5% reduction in two test cases. This is a small victory, but doesn't really undo the sting of defeat. (Optimizations to land in the next day or so.) My best guess is that the extra variables due to runtime polymorphism are what's gumming up the works. Previously, every binder without a type signature (including all local ones) were given a type `alpha :: OpenKind`. Now, every binder is given `alpha :: TYPE rho`; two metavariables where there was once one. And even when the type is solved, the kind now takes up more space than it did previously. But I have no data to back this up. I'm very happy to advise someone who wants to take this on. As usual with performance problems, the devil is in the data collecting and pinpointing -- the fix (if there is one) is usually quite easy. But I'm sad to say that I'm formally giving up on this one. I have simply timed out if I am to graduate. I will say that I don't believe this ticket needs to be a release blocker. * T5631 still is worse by 30% in bytes allocated. This is a happy- generated file with lots of mutually-recursive functions with no type signatures, exactly the pathological case for representation polymorphism. I doubt we can bring this one back to 7.10 levels. * T5837 is off from before `TypeInType`. But it's still better than 7.10 was! * T9675 has regressed in peak memory usage, but not allocations. This one doesn't seem to be representation polymorphism. But I couldn't nail it. * T9872 is an utter abuse of type families and looks nothing like a typical Haskell program. And those are the only cases that are worse than before `TypeInType`. Work between when this ticket was posted and now cleared up the others. I'll leave it to someone else to agree with me that this needn't be a release blocker before changing the priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 19 22:17:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Mar 2016 22:17:34 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.d3750f7fa76c08bc5806e06e30561975@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime | Test Case: performance bug | testsuite/tests/simplCore/T9646 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2009 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: patch => closed * resolution: => fixed Comment: Since the test has new been commited to master, this can be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 08:13:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 08:13:00 -0000 Subject: [GHC] #11725: Performance Regression from 7.8.3 to 7.10.3 Message-ID: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> #11725: Performance Regression from 7.8.3 to 7.10.3 -------------------------------------+------------------------------------- Reporter: dominic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Some time ago I wrote a little test program for random number generation. Under 7.8.3 I get {{{ Total time 9.03s ( 9.15s elapsed) }}} Under 7.10.3 I get {{{ Total time 24.773s ( 25.288s elapsed) }}} Now of course it could be the libraries that I am using rather than GHC itself so I have tried to make them as similar as possible. For 7.8.3 I have {{{ build-depends: base ==4.7.0.1, mtl ==2.1.3.1, primitive == 0.6, mwc-random == 0.13.3.2, vector == 0.10.12.3, random ==1.1, random-fu == 0.2.6.2, random-source == 0.3.0.6 }}} For 7.10.3 I have {{{ build-depends: base ==4.8.2.0, mtl ==2.2, primitive == 0.6, mwc-random == 0.13.3.2, vector == 0.10.12.3, random ==1.1, random-fu == 0.2.6.2, random-source == 0.3.0.6 }}} So the only differences are in mtl and base. I don?t seem to be able to coax cabal into using mtl-2.2 for 7.8.3 with all the other required libraries. {{{ dominic at ghcPerformance:~$ cabal install 'random-source ==0.3.0.6' 'random- fu ==0.2.6.2' 'random ==1.1' 'primitive ==0.6' 'mwc-random ==0.13.3.2' 'mtl ==2.2' 'vector ==0.10.12.3' --with-ghc=ghc-7.10.3 Resolving dependencies... All the requested packages are already installed: mtl-2.2 mwc-random-0.13.3.2 primitive-0.6 random-1.1 random-fu-0.2.6.2 random-source-0.3.0.6 vector-0.10.12.3 Use --reinstall if you want to reinstall anyway. dominic at ghcPerformance:~$ cabal install 'random-source ==0.3.0.6' 'random- fu ==0.2.6.2' 'random ==1.1' 'primitive ==0.6' 'mwc-random ==0.13.3.2' 'mtl ==2.2' 'vector ==0.10.12.3' --with-ghc=ghc-7.8.3 Resolving dependencies... cabal: Could not resolve dependencies: trying: random-source-0.3.0.6/installed-70e... (user goal) next goal: mtl (user goal) rejecting: mtl-2.2.1, 2.2.0.1 (global constraint requires ==2.2) rejecting: mtl-2.2/installed-cc5..., 2.2 (conflict: random-source => mtl==2.1.3.1/installed-8bc...) rejecting: mtl-2.1.3.1/installed-8bc..., 2.1.3.1, 2.1.2, 2.1.1, 2.1, 2.0.1.1, 2.0.1.0, 2.0.0.0, 1.1.1.1, 1.1.1.0, 1.1.0.2, 1.1.0.1, 1.1.0.0, 1.0 (global constraint requires ==2.2) Backjump limit reached (change with --max-backjumps). }}} Cabal seems to be telling me that random-source-0.3.0.6 is the problem but if I look at the constraints for that package here https://hackage.haskell.org/package/random-source then I see {{{ mtl (>=1 && <3) }}} I am not sure how to proceed from here. I?d like to solve this myself but I don?t want to start building versions of ghc to see which change caused the regression without first eliminating mtl. Any ideas would be gratefully received. {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE FlexibleInstances #-} import Data.Random import Data.Random.Source import qualified System.Random.MWC as MWC import Control.Monad.Reader import Control.Monad.Primitive $(monadRandom [d| instance (PrimMonad m, s ~ PrimState m) => MonadRandom (ReaderT (MWC.Gen s) m) where getRandomWord16 = ask >>= lift . MWC.uniform getRandomWord32 = ask >>= lift . MWC.uniform getRandomWord64 = ask >>= lift . MWC.uniform |]) testUniform :: MonadRandom m => Int -> m [Double] testUniform n = replicateM (fromIntegral n) (sample stdUniform) n :: Int n = 10^7 main :: IO () main = do seed <- MWC.create xs <- runReaderT (testUniform n) seed print (sum xs / fromIntegral n) }}} This cabal file will build this on 7.8.3 {{{ name: PerfTest8 version: 0.1.0.0 homepage: TBD license: MIT author: Dominic Steinitz maintainer: idontgetoutmuch at gmail.com category: System build-type: Simple cabal-version: >=1.10 executable Random8 main-is: TestMwcViaRandomSource.hs build-depends: base ==4.7.0.1, mtl ==2.1.3.1, primitive == 0.6, mwc-random == 0.13.3.2, vector == 0.10.12.3, random ==1.1, random-fu == 0.2.6.2, random-source == 0.3.0.6 default-language: Haskell2010 }}} This cabal file will build this on 7.10.3 {{{ name: PerfTest10 version: 0.1.0.0 homepage: TBD license: MIT author: Dominic Steinitz maintainer: idontgetoutmuch at gmail.com category: System build-type: Simple cabal-version: >=1.10 executable Random10 main-is: TestMwcViaRandomSource.hs build-depends: base ==4.8.2.0, mtl ==2.2, primitive == 0.6, mwc-random == 0.13.3.2, vector == 0.10.12.3, random ==1.1, random-fu == 0.2.6.2, random-source == 0.3.0.6 default-language: Haskell2010 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 08:17:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 08:17:16 -0000 Subject: [GHC] #11725: Performance Regression from 7.8.3 to 7.10.3 In-Reply-To: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> References: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> Message-ID: <061.799f22f5664e28ffe7eef23f14ac9ced@haskell.org> #11725: Performance Regression from 7.8.3 to 7.10.3 -------------------------------------+------------------------------------- Reporter: dominic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): It's entirely possible that this has been solved in 8.0.1 so I have built this compiler on OS X 10.11.3. At the moment I can't build one of the packages on which my example depends {{{ ~/Dropbox/Private/Random8 $ ~/Library/Haskell/ghc-7.10.3/lib/cabal- install-1.25.0.0/bin/cabal install flexible-defaults --constraint ="template-haskell==2.11.0.0" --with-ghc=/Users/dom/ghc/inplace/bin/ghc- stage2 ~/Library/Haskell/ghc-7.10.3/lib/cabal-install-1.25.0.0/bin/cabal install flexible-defaults --constraint="template-haskell==2.11.0.0" --with- ghc=/Users/dom/ghc/inplace/bin/ghc-stage2 Resolving dependencies... cabal: Entering directory '/var/folders/3p/m593dprn5snbjz6sc45c77f80000gn/T/cabal-tmp-99610 /flexible-defaults-0.0.0.2' Configuring flexible-defaults-0.0.0.2... Building flexible-defaults-0.0.0.2... Preprocessing library flexible-defaults-0.0.0.2... [1 of 3] Compiling Language.Haskell.TH.FlexibleDefaults.Solve ( src/Language/Haskell/TH/FlexibleDefaults/Solve.hs, dist/dist-sandbox- 59d6d2c7/build/Language/Haskell/TH/FlexibleDefaults/Solve.o ) src/Language/Haskell/TH/FlexibleDefaults/Solve.hs:13:1: warning: The import of ?Data.Monoid? is redundant except perhaps to import instances from ?Data.Monoid? To import instances alone, use: import Data.Monoid() [2 of 3] Compiling Language.Haskell.TH.FlexibleDefaults.DSL ( src/Language/Haskell/TH/FlexibleDefaults/DSL.hs, dist/dist-sandbox- 59d6d2c7/build/Language/Haskell/TH/FlexibleDefaults/DSL.o ) src/Language/Haskell/TH/FlexibleDefaults/DSL.hs:79:82: error: Not in scope: type constructor or class ?InlineSpec? src/Language/Haskell/TH/FlexibleDefaults/DSL.hs:90:32: error: Not in scope: type constructor or class ?InlineSpec? src/Language/Haskell/TH/FlexibleDefaults/DSL.hs:121:14: error: Not in scope: type constructor or class ?InlineSpec? cabal: Leaving directory '/var/folders/3p/m593dprn5snbjz6sc45c77f80000gn/T /cabal-tmp-99610/flexible-defaults-0.0.0.2' Failed to install flexible-defaults-0.0.0.2 cabal: Error: some packages failed to install: flexible-defaults-0.0.0.2 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 09:19:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 09:19:49 -0000 Subject: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC In-Reply-To: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> References: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> Message-ID: <059.7eb47f98149d02dd3874ea288905bf60@haskell.org> #4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: kaiha Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kaiha): * owner: => kaiha -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 10:58:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 10:58:02 -0000 Subject: [GHC] #11725: Performance Regression from 7.8.3 to 7.10.3 In-Reply-To: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> References: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> Message-ID: <061.53d9cf1b932cc420f05ddad01f99c3f3@haskell.org> #11725: Performance Regression from 7.8.3 to 7.10.3 -------------------------------------+------------------------------------- Reporter: dominic | Owner: dominic Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dominic): * owner: => dominic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 10:58:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 10:58:12 -0000 Subject: [GHC] #11725: Performance Regression from 7.8.3 to 7.10.3 In-Reply-To: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> References: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> Message-ID: <061.7efad764367d5873a7c8fdadad27ba78@haskell.org> #11725: Performance Regression from 7.8.3 to 7.10.3 -------------------------------------+------------------------------------- Reporter: dominic | Owner: dominic Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): See also https://ghc.haskell.org/trac/ghc/ticket/6166 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 10:58:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 10:58:44 -0000 Subject: [GHC] #6166: Performance regression in mwc-random since 7.0.x In-Reply-To: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> References: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> Message-ID: <057.8e76d0540b1990760276f72d31c46854@haskell.org> #6166: Performance regression in mwc-random since 7.0.x -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): See also https://ghc.haskell.org/trac/ghc/ticket/11725 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 12:31:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 12:31:25 -0000 Subject: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC In-Reply-To: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> References: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> Message-ID: <059.2ac1e658209d2e6ad58cd8ea4b6c4b39@haskell.org> #4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: kaiha Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2258 | Differential Rev(s): Phab:D2021 Wiki Page: | -------------------------------------+------------------------------------- Changes (by kaiha): * status: new => patch * differential: => Phab:D2021 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 12:39:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 12:39:49 -0000 Subject: [GHC] #11574: schedule: re-entered unsafely on minimal hello world program on arm In-Reply-To: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> References: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> Message-ID: <066.34365a8cef6ad9b1e929ea23406b0619@haskell.org> #11574: schedule: re-entered unsafely on minimal hello world program on arm ----------------------------------+---------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Comment (by andrewufrank): i found a different way to resolve the issue and report it here; perhaps it helps others: i used the ghc from debian stretch (testing), which has uses a different version of llvm (namely 1:3.2.5-3) which works. this confirm the suggestion above that the llvm version in debian jessie backports is the cause to the problem. now things work nicely! thanks to the team that brought ghc to armhf (it runs smoothly and fast on an odroid xu4) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 16:32:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 16:32:56 -0000 Subject: [GHC] #11702: Constant folding on 'mod/Word' - incorrect result In-Reply-To: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> References: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> Message-ID: <060.5273249e147c83cee1a8d4aeb41f315a@haskell.org> #11702: Constant folding on 'mod/Word' - incorrect result -------------------------------------+------------------------------------- Reporter: ondrap | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Prelude | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2004 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3ddfcc95cd41dac19c8f4d55e8fc03128b77b738/ghc" 3ddfcc95/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3ddfcc95cd41dac19c8f4d55e8fc03128b77b738" PrelRules: Fix constant folding for WordRemOp Test Plan: Validate with testcase in D2002 Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2004 GHC Trac Issues: #11702 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 16:32:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 16:32:56 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.6834a924f00aa7bda3f8e753954d6440@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | dependent/should_fail/T11473 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c0f628dc6f604028acc665e5b37019750a30c852/ghc" c0f628dc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c0f628dc6f604028acc665e5b37019750a30c852" Revert "Add test for #11473" This reverts commit 89bdac7635e6ed08927d760aa885d3e7ef3edb81 as this test is duplicated with dependent/should_fail/T11473, added by aade111248dce0834ed83dc4f18c234967b3202. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 16:32:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 16:32:56 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.4dc9d153b870f7f28c11e69cfc35283b@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime | Test Case: performance bug | testsuite/tests/simplCore/T9646 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2009 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"08d254bc8452cdb12f852805f20d346ad4181ed8/ghc" 08d254bc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="08d254bc8452cdb12f852805f20d346ad4181ed8" Fix T9646 For #9646. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 16:32:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 16:32:56 -0000 Subject: [GHC] #11701: ghc generates significant slower code In-Reply-To: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> References: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> Message-ID: <064.2d58559073425387296feedc3ba09fb5@haskell.org> #11701: ghc generates significant slower code -------------------------------------+------------------------------------- Reporter: HuStmpHrrr | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: efficiency Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1997 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2841ccab595ce38fb86b789574f057c3abe3d630/ghc" 2841ccab/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2841ccab595ce38fb86b789574f057c3abe3d630" Mark GHC.Real.even and odd as INLINEABLE Previously they were merely specialised at Int and Integer. It seems to me that these are cheap enough to be worth inlining. See #11701 for motivation. Test Plan: Validate Reviewers: austin, hvr, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1997 GHC Trac Issues: #11701 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 18:30:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 18:30:14 -0000 Subject: [GHC] #11726: Document change in implicit quantification Message-ID: <047.b3f24e15febbe2b1b55713b5bd16ee41@haskell.org> #11726: Document change in implicit quantification -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: Documentation | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Simon's big wildcard refactor (1e041b7382b6aa329e4ad9625439f811e0f27232) changed the way GHC does implicit quantification. I don't see documentation for this, however. (That patch doesn't touch the manual, and there are no release notes, at least.) This report was prompted by [https://mail.haskell.org/pipermail/haskell- cafe/2016-March/123487.html this Haskell-Caf? post], where Tom Ellis asks why we need {{{ -data PackMap a b s t = PackMap (Applicative f => (a -> f b) -> s -> f t) +data PackMap a b s t = PackMap (forall f. Applicative f => (a -> f b) -> s -> f t) }}} to update for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 19:09:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 19:09:14 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.258bdba2b7ccc7ff92f5ab67aaf62016@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:27 dfeuer]: > If people want to go forward with desugaring fundeps to type families (sounds great to me), I think it would be lovely to add naming syntax: > > {{{#!hs > class Foo a b c d | (Q, R :: a -> b c), (S :: b d -> a) > }}} > I tend to like the option to give names, but I cringe at this syntax. The `::` in there activates my brain's type parser. Then, that parser successfully processes `a -> b c`. But then my brain experiences quite a jarring type error when it tries to treat the result of that parse as a functional dependency. I have no better suggestion here, and I would probably admit that this is the best available syntax. I just hate experiencing type errors in my brain just as much as in my running programs! Haskell generally prevents the latter. I have no good idea how to prevent the former, in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 19:30:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 19:30:26 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.3ebd25faed540d70406f176d8312e5d2@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I feel your pain. I think the choice to reuse `->` was a bit fishy from the start. I'd have no objection to using some symbol other than `::` if you'd prefer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 21:11:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 21:11:47 -0000 Subject: [GHC] #11580: panic on incompatible options In-Reply-To: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> References: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> Message-ID: <059.4b399fb79968e0cbbe8d00d83a02ce25@haskell.org> #11580: panic on incompatible options -------------------------------------+------------------------------------- Reporter: dougm | Owner: kaiha Type: bug | Status: patch Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1925 Wiki Page: | Phab:D2013 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"289d57a6894b5d3eb5daf696a75275a8146f0092/ghc" 289d57a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="289d57a6894b5d3eb5daf696a75275a8146f0092" Add test for incompatible flags (issue #11580) Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2013 GHC Trac Issues: #11580 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 21:11:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 21:11:47 -0000 Subject: [GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc) In-Reply-To: <045.274c910606d60239cadf6f398a2dd711@haskell.org> References: <045.274c910606d60239cadf6f398a2dd711@haskell.org> Message-ID: <060.22c211295b42263e345eb0d225965303@haskell.org> #11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: jme Type: bug | Status: patch Priority: high | Milestone: Component: Profiling | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | perf/space_leaks/space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2005 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ba95f22eb98cc2ee2d8d76e56df80769c379413d/ghc" ba95f22e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ba95f22eb98cc2ee2d8d76e56df80769c379413d" prof: Fix heap census for large ARR_WORDS (#11627) The heap census now handles large ARR_WORDS objects which have been shrunk by shrinkMutableByteArray# or resizeMutableByteArray#. Test Plan: ./validate && make test WAY=profasm Reviewers: hvr, bgamari, austin, thomie Reviewed By: thomie Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2005 GHC Trac Issues: #11627 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 21:11:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 21:11:47 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.ec7263590ea18961dfd261b0d07d1a04@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2007 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b735e99d79448bd7f416b35d8b0473d8eb5271f1/ghc" b735e99d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b735e99d79448bd7f416b35d8b0473d8eb5271f1" DsExpr: Don't build/foldr huge lists Desugaring long lists with build trades large static data for large code, which is likely a poor trade-off. See #11707. Test Plan: Validate, nofib Reviewers: simonpj, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2007 GHC Trac Issues: #11707 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 21:22:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 21:22:19 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.73a8c6adc0c222a6e9763208a7036068@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Another thought: this might be more efficient if dependencies that determine multiple types could be represented by a single type family. However, I know nothing about type checking efficiency matters. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 21:54:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 21:54:38 -0000 Subject: [GHC] #11727: Allow one type signature for multiple pattern synonyms Message-ID: <049.0fba9aba358ebb714117eb166e00090c@haskell.org> #11727: Allow one type signature for multiple pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There's no reason why we shouldn't allow the same type signature for multiple pattern synonyms just like ordinary functions. For example, {{{ pattern A,B,C,D :: Int pattern A = 5 pattern B = 6 pattern C = 7 pattern D = 8 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 22:11:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 22:11:04 -0000 Subject: [GHC] #11728: Core lint errors Message-ID: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> #11728: Core lint errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have an older version (8.1.20160117), does this still occur? Compiling with `ghci -dcore-lint -ignore-dot-ghci` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 22:11:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 22:11:28 -0000 Subject: [GHC] #11728: Core lint errors In-Reply-To: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> References: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> Message-ID: <066.0d249499d49b74a147ddf350b34947ee@haskell.org> #11728: Core lint errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "error.hs" added. source file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 22:12:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 22:12:10 -0000 Subject: [GHC] #11728: Core lint errors In-Reply-To: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> References: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> Message-ID: <066.9b052418281f9250e0ef1d4178e7b35f@haskell.org> #11728: Core lint errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "error.log" added. Error log from running "ghci -dcore-lint -ignore-dot-ghci /tmp/error.hs &> error.log" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 22:12:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 22:12:32 -0000 Subject: [GHC] #11728: Core lint errors In-Reply-To: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> References: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> Message-ID: <066.951fd95675159899e3d8206315b8e4d1@haskell.org> #11728: Core lint errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 22:15:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 22:15:36 -0000 Subject: [GHC] #11728: Core lint errors In-Reply-To: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> References: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> Message-ID: <066.c92b851209b9a7e8cda4437cf541226e@haskell.org> #11728: Core lint errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, it still happens. :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 22:43:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 22:43:52 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.accca581654d76762ccb2e689fea0634@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2007 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 23:39:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 23:39:43 -0000 Subject: [GHC] #10510: Testsuite driver does not run tests in parallel on Windows In-Reply-To: <045.f7051a2be634cd79e52b8850db4fc44f@haskell.org> References: <045.f7051a2be634cd79e52b8850db4fc44f@haskell.org> Message-ID: <060.667eda095b61deb6ddeb3d567a6b8981@haskell.org> #10510: Testsuite driver does not run tests in parallel on Windows ---------------------------------+---------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): I have also been unable to reproduce the hang on Windows 10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 23:57:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 23:57:09 -0000 Subject: [GHC] #11512: An unwritten kind variable is "specified", when it shouldn't be. In-Reply-To: <047.7a36187500c6876edf467692a28ef5b3@haskell.org> References: <047.7a36187500c6876edf467692a28ef5b3@haskell.org> Message-ID: <062.af513b3f134dfe10ca16734a0299945e@haskell.org> #11512: An unwritten kind variable is "specified", when it shouldn't be. -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11512 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged as c1d6cd4d0c80a671c3bc837e0446b62813cfc124. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 23:57:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 23:57:13 -0000 Subject: [GHC] #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on In-Reply-To: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> References: <047.a5115252f9f8cbf23ed0516e9189da49@haskell.org> Message-ID: <062.03569b55fbc7c9c149cf508f13ec80cc@haskell.org> #11708: Typechecker hangs when checking type families with -ddump-tc-trace turned on -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: kcsongor Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: typefamilies Resolution: fixed | trace hangs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2006 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as f7eb12f72303cc2c6229b9d94da263ca17b5cf35. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 23:57:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 23:57:15 -0000 Subject: [GHC] #11716: Make TypeInType stress test work In-Reply-To: <047.dab3e539603ee118886dc0a739516c12@haskell.org> References: <047.dab3e539603ee118886dc0a739516c12@haskell.org> Message-ID: <062.99850cf09c07b98d6b5bf2aee67227c0@haskell.org> #11716: Make TypeInType stress test work -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/RaeJobTalk Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged as 26fce95067e4a4ad71e0931af333d44df7763346. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 23:58:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 23:58:05 -0000 Subject: [GHC] #11711: Typechecker assertion failure In-Reply-To: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> References: <046.44b7dd85ff634044673f724546d6ff65@haskell.org> Message-ID: <061.cd82da5ba544c3f6f116e7a06837c9a4@haskell.org> #11711: Typechecker assertion failure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | dependent/should_compile/T11711 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as a5bdf423efe23bdd7f2eabd7ee7a4a862b8f3b48. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 20 23:59:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Mar 2016 23:59:04 -0000 Subject: [GHC] #11329: Visible type applications: failing tests with WAY=hpc In-Reply-To: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> References: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> Message-ID: <060.fe267e9a572cf17ea269c02c872d4350@haskell.org> #11329: Visible type applications: failing tests with WAY=hpc -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/VtaParse | typecheck/should_compile/Vta1 | typecheck/should_compile/Vta2 | ghci/scripts/T11456 Blocked By: | Blocking: Related Tickets: #11456 | Differential Rev(s): Phab:D1824 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Refactoring of comment:11 merged as 729320938b17a101c4a6b43c824edace9ebb53f6.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 00:00:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 00:00:21 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.ec3cd4150ea0a15913123f24ba74100e@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | dependent/should_fail/T11473 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 00:14:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 00:14:55 -0000 Subject: [GHC] #11729: `make sdist` target fails Message-ID: <044.fb56a4d177682d7be236a48a26caf9dc@haskell.org> #11729: `make sdist` target fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the top level `Makefile` the comment above the `sdist` target says: {{{ # Just running `./boot && ./configure && make sdist` should work, so skip # phase 0 and 1 and don't build any dependency files. }}} but when I try that (both for `master` and the `ghc-8.0` branch, I get: {{{ cd sdistprep/ghc/ghc-8.1.20160320 && for i in mk rules docs distrib bindisttest libffi includes utils docs rts compiler ghc driver libraries libffi- tarballs iserv; do mkdir -p $i; ( cd $i && lndir /home/erikd/Git/ghc- upstream/$i ); done /bin/bash: lndir: command not found /bin/bash: lndir: command not found /bin/bash: lndir: command not found /bin/bash: lndir: command not found /bin/bash: lndir: command not found /bin/bash: lndir: command not found /bin/bash: lndir: command not found /bin/bash: lndir: command not found /bin/bash: lndir: command not found /bin/bash: lndir: command not found /bin/bash: lndir: command not found /bin/bash: lndir: command not found /bin/bash: lndir: command not found /bin/bash: lndir: command not found /bin/bash: lndir: command not found /bin/bash: lndir: command not found ghc.mk:1205: recipe for target 'sdist-ghc-prep-tree' failed make[1]: *** [sdist-ghc-prep-tree] Error 127 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 00:32:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 00:32:54 -0000 Subject: [GHC] #11710: Fusion of a simple listArray call is very fragile In-Reply-To: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> References: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> Message-ID: <061.0f3259d64a2784e400c8f5c35aa92e85@haskell.org> #11710: Fusion of a simple listArray call is very fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2023 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2023 * milestone: => 8.0.1 Comment: The fix from #11707, Phab:D2007, has been merged. Phab:D2023 removes the static tail business, as suggested by Simon in comment:4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 00:38:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 00:38:32 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.9ed9384ea90d46db49ca7f4c1821519a@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: highest => high * milestone: 8.0.1 => 8.0.2 Comment: Alright, the reasons cited here seem reasonable. Demoting to high. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 00:49:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 00:49:23 -0000 Subject: [GHC] #11729: `make sdist` target fails In-Reply-To: <044.fb56a4d177682d7be236a48a26caf9dc@haskell.org> References: <044.fb56a4d177682d7be236a48a26caf9dc@haskell.org> Message-ID: <059.3b42288b0e873607c6181a45d8993718@haskell.org> #11729: `make sdist` target fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Still fails after the tree is built. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 00:56:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 00:56:19 -0000 Subject: [GHC] #11729: `make sdist` target fails In-Reply-To: <044.fb56a4d177682d7be236a48a26caf9dc@haskell.org> References: <044.fb56a4d177682d7be236a48a26caf9dc@haskell.org> Message-ID: <059.f6c59bb555c7daad3cbb4363b0922bc2@haskell.org> #11729: `make sdist` target fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 7.10.3 => 8.0.1-rc2 Comment: Hmm, not really sure what to say about this. It seems to work fine for me. What operating system are you on? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 00:57:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 00:57:09 -0000 Subject: [GHC] #11729: `make sdist` target fails In-Reply-To: <044.fb56a4d177682d7be236a48a26caf9dc@haskell.org> References: <044.fb56a4d177682d7be236a48a26caf9dc@haskell.org> Message-ID: <059.39b472d819831261d8ad5bd9541a5c73@haskell.org> #11729: `make sdist` target fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * version: 8.0.1-rc2 => 7.10.3 Comment: Seems my make was missing the `lndir` executable which in Debian is part of the `xutils-dev` package. Would be nice of the build system failed more gracefully when it hits this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 03:50:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 03:50:15 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.6695a32b361e56c8846212d570c52935@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:9 simonpj]: > * If we were to silence `checkValidType` (with a language extension), it would also allow functions like > {{{ > reify :: c => c > with :: c -> (c => r) -> r > }}} This was one of my use cases for #11441, this would be an interesting solution and may supersede that part of the proposal. Would this be enabled for each module or as a pragma: {{{#!hs {-# ALLOWINVALIDTYPE f #-} f :: Int => Int f = undefined }}} Heck, it could go as far as *require* an ill-kinded type ? `{-# INVALIDTYPE f #-}` ? such that this would not compile: {{{#!hs {-# INVALIDTYPE f #-} f :: Int -> Int f = undefined }}} What would be the use of that? It's machine checkable and who knows what changed during refactoring, a reader won't have to guess if there is some funny business going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 03:52:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 03:52:40 -0000 Subject: [GHC] #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) In-Reply-To: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> References: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> Message-ID: <066.7763797d9bf647ac89d58c9592e96009@haskell.org> #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): ticket:11715#comment:9 covers some of the same ground -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 06:46:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 06:46:24 -0000 Subject: [GHC] #11730: GHC panics ('unload: no interpreter") during T10052 test Message-ID: <042.b5a574f763a8972e0dd59e722775b101@haskell.org> #11730: GHC panics ('unload: no interpreter") during T10052 test -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- T10052.hs currently results in a runtime panic on interpreter-less GHCs: {{{ =====> T10052(normal) 7 of 8 [0, 5, 0] cd ./T10052 && $MAKE -s --no-print-directory T10052 T10052.run.stdout 2> T10052.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Makefile:9: recipe for target 'T10052' failed Stderr: when making flags consistent: warning: -O conflicts with --interactive; -O ignored. T10052: T10052: panic! (the 'impossible' happened) (GHC version 8.1.20160320 for x86_64-unknown-linux): unload: no interpreter Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [T10052] Error 1 *** unexpected failure for T10052(normal) }}} I'm creating this ticket in order to reference this ticket via a `expect_broken()` annotation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 08:26:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 08:26:23 -0000 Subject: [GHC] #11731: Demand analysis: Thunk wrongly determined single-entry Message-ID: <046.a5918d80f4707137661067c33245f819@haskell.org> #11731: Demand analysis: Thunk wrongly determined single-entry -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While working on #10613, I looked a bit more closely at the ticky numbers of single-entry thunks. In all of nofib, I found exactly one fishy result: A thunk, marked as single entry, but entered multiple times, in gameteb. I?ll write a preliminary analysis in the comments and either found a bug or a misunderstanding on my side. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 08:27:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 08:27:16 -0000 Subject: [GHC] #11731: Demand analysis: Thunk wrongly determined single-entry In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.b4cba672a697dcf3e87768e65808ef68@haskell.org> #11731: Demand analysis: Thunk wrongly determined single-entry -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): {{{ Entries Alloc Alloc'd #Alloc Single Multiple Non- void Arguments STG Name 4096 0 65536 2048 0 2048 0 sat_s2vw{v} (main at main:GamtebMain) (thk,se) in r2uq }}} The relevant `-ddump-prep` code is this: {{{ let { sat_s2vw [Occ=Once, Dmd=] :: GamtebType.Random [LclId, Str=DmdType] = \s srt:SRT:[r4K :-> Utils.$wgenRand] [] case Utils.$wgenRand w_s2ux of _ [Occ=Dead] { (#,#) ww5_s2vu [Occ=Once] _ [Occ=Dead] -> ww5_s2vu; }; } in TransPort.$wtransPort lvl2_r2ut lvl2_r2ut lvl2_r2ut lvl2_r2ut lvl1_r2us lvl2_r2ut lvl1_r2us w1_s2uz ww2_s2vk lvl_r2ur sat_s2vw ww17_s2vn ww19_s2vp ww22_s2vs; }}} The relevant code for `$wtransPort` ist {{{ TransPort.$wtransPort [InlPrag=[0], Occ=LoopBreaker] :: GamtebType.Coord -> GamtebType.Coord -> GamtebType.Coord -> GamtebType.Coord -> GamtebType.Coord -> GamtebType.Coord -> GamtebType.Weight -> GamtebType.Energy -> GamtebType.Indx -> GHC.Types.Int -> GamtebType.Random -> GamtebType.Prob -> GamtebType.Prob -> GHC.Prim.Double# -> (# [GamtebType.Result], [GamtebType.Stat] #) [GblId, Arity=14, Str=DmdType , Unf=OtherCon []] = \r srt:SRT:[r4K :-> Utils.$wgenRand, r5x :-> Compton.$wcompton, r5O :-> Pair.$wpair, r3Df :-> TransPort.$wtransPort, r3Dr :-> lvl11_r3Dr] [ww_s3Dy ww1_s3Dz ww2_s3DA ww3_s3DB ww4_s3DC ww5_s3DD ww6_s3DE ww7_s3DF ww8_s3DG ww9_s3DH ww10_s3DI ww11_s3DJ ww12_s3DK ww13_s3DL] case Utils.$wgenRand ww10_s3DI of _ [Occ=Dead] { (#,#) ww15_s3DN [Occ=Once!] ww16_s3DO -> }}} Note how the strictness signature say that the `Random` argument is used at most once (`1*U(U)`). The call to `$wgenRand` is indeed the only use of `ww10_s3DI`. So here is the code of `$wgenRand`: {{{ Utils.$wgenRand [InlPrag=[0]] :: GamtebType.Random -> (# GamtebType.Random, GamtebType.Random #) [GblId, Arity=1, Str=DmdType , Unf=OtherCon []] = \r srt:SRT:[015 :-> GHC.Integer.Type.timesInteger, 017 :-> GHC.Integer.Type.negateInteger, 01j :-> GHC.Integer.Type.divInteger, 01x :-> GHC.Integer.Type.shiftLInteger] [w_s3BX] let { sat_s3CT [Occ=Once] :: GamtebType.Random [LclId, Str=DmdType] = \u srt:SRT:[015 :-> GHC.Integer.Type.timesInteger, 017 :-> GHC.Integer.Type.negateInteger, 01j :-> GHC.Integer.Type.divInteger, 01x :-> GHC.Integer.Type.shiftLInteger] [] case w_s3BX of _ [Occ=Dead] { GHC.Types.D# y_s3Cs [Occ=Once] -> ... }; } in let { sat_s3Cq [Occ=Once] :: GamtebType.Random [LclId, Str=DmdType] = \u srt:SRT:[015 :-> GHC.Integer.Type.timesInteger, 017 :-> GHC.Integer.Type.negateInteger, 01j :-> GHC.Integer.Type.divInteger, 01x :-> GHC.Integer.Type.shiftLInteger] [] case w_s3BX of _ [Occ=Dead] { GHC.Types.D# y_s3BZ [Occ=Once] -> ... }; } in (#,#) [sat_s3Cq sat_s3CT]; }}} So `$wgenRand` may evaluate its argument more than once (as its strictness signature says). On what grounds does `$wtransPort` then claim the argument is used at most once? Now if the argument to `$wgenRand` were a complex expression, this would be valid reasoning, as it would be let-bound and then shared. But trivial expressions, when passed as arguments, are _not_ shared at this point, so the information that the argument may be used multiple times should be propagated out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 09:16:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 09:16:51 -0000 Subject: [GHC] #11731: Demand analysis: Thunk wrongly determined single-entry In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.2a88584270dd0075a32f4cb9e6efa3b9@haskell.org> #11731: Demand analysis: Thunk wrongly determined single-entry -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): It seems that on its own, the demand analysis is correct. Here is the relevant bit from `transPort`, as the demand analysis sees it: {{{ transPort = \ (p_ayV [Dmd=] :: Particle) (prob_ayW [Dmd=] :: Probability) -> let { seed_s33f [Dmd=] :: Random [LclId, Str=DmdType {ayV->}, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 0}] seed_s33f = case p_ayV of _ [Occ=Dead, Dmd=] { Part pos_X21Q [Dmd=] dir_X21S [Dmd=] w_X21U [Dmd=] e_X21W [Dmd=] eIndx_X21Y [Dmd=] cell_X220 [Dmd=] seed_X22n [Dmd=] -> seed_X22n } } in case Utils.$wgenRand seed_s33f ... }}} Note that the demand on `seed` is *not* one-shot (because there are two calls to `wgenRand seed_s33f` in the body below, but the demand on the corresponding member of `Particle` is. As long as `seed_s33f` is shared, this is fine. But after the next simplifier run, which includes worker-wrappering the `Particle` argument, CSE?ing the various calls to `$wgenRand` as well as subsequent simplifications, we get: {{{ [LclId, Arity=14, Str=DmdType , Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=NEVER}] $wtransPort_s3nF = \ (ww_s3nb :: Coord) (ww_s3nc :: Coord) (ww_s3nd :: Coord) (ww_s3ni :: Coord) (ww_s3nj :: Coord) (ww_s3nk :: Coord) (ww_s3nm :: Weight) (ww_s3nn :: Energy) (ww_s3no :: Indx) (ww_s3np :: Int) (ww_s3nq :: Random) (ww_s3nu :: Prob) (ww_s3nw :: Prob) (ww_s3nA :: GHC.Prim.Double#) -> case Utils.$wgenRand ww_s3nq of _ [Occ=Dead, Dmd=] { (# ww1_a2WR [Dmd=], ww2_a2WS [Dmd=] #) -> }}} and behold: The sharing-ensuring let is gone, the field member `ww_s3nq` is passed directly to `$wgenRand` and now the strictness signature is a lie! Tracing the simplifier is not easy, but I expect the sequence of actions to be roughly this: After WW we have {{{ \ (ww_s3nb [Dmd=] :: Coord) (ww_s3nc [Dmd=] :: Coord) (ww_s3nd [Dmd=] :: Coord) (ww_s3ni [Dmd=] :: Coord) (ww_s3nj [Dmd=] :: Coord) (ww_s3nk [Dmd=] :: Coord) (ww_s3nm [Dmd=] :: Weight) (ww_s3nn [Dmd=] :: Energy) (ww_s3no :: Indx) (ww_s3np [Dmd=] :: Int) (ww_s3nq [Dmd=] :: Random) (ww_s3nu [Dmd=] :: Prob) (ww_s3nw [Dmd=] :: Prob) (ww_s3nA [Dmd=] :: GHC.Prim.Double#) -> ... let { w_s3n4 [Dmd=] :: Particle [LclId, Str=DmdType] w_s3n4 = GamtebType.Part ww_s3n8 ww_s3nf ww_s3nm ww_s3nn ww_s3no ww_s3np ww_s3nq } in ... case (\ (p_ayV [Dmd=] :: Particle) (prob_ayW [Dmd=] :: Probability) -> let { seed_s33f [Dmd=] :: Random [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 0}] seed_s33f = case p_ayV of _ [Occ=Dead, Dmd=] { Part pos_X21Q [Dmd=] dir_X21S [Dmd=] w_X21U [Dmd=] e_X21W [Dmd=] eIndx_X21Y [Dmd=] cell_X220 [Dmd=] seed_X22n [Dmd=] -> seed_X22n } } in case Utils.$wgenRand seed_s33f ... w_s3n4 w_s3n5 }}} and then (beta-reduction) {{{ let { seed_s33f [Dmd=] :: Random [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 0}] seed_s33f = case w_s3n4 -- ? here of _ [Occ=Dead, Dmd=] { Part pos_X21Q [Dmd=] dir_X21S [Dmd=] w_X21U [Dmd=] e_X21W [Dmd=] eIndx_X21Y [Dmd=] cell_X220 [Dmd=] seed_X22n [Dmd=] -> seed_X22n } } in case Utils.$wgenRand seed_s33f }}} and then (inlining of constructor application into interesting context, and case of known constructor) {{{ let { seed_s33f [Dmd=] :: Random seed_s33f = ww_s3nq case Utils.$wgenRand seed_s33f }}} and then (inline trivial let) {{{ case Utils.$wgenRand seed_s3nq }}} and there we have the salad (German idiom). My gut feeling is that in order to fix this problem, either all trivial lets must be preserved, or any simplification that turns a non-trivial let into a trivial let needs to somehow mark this let as ?need to be preserved until STG?. This is very much related to the trap that I fell into with Call Arity in #11064. Seems to be quite a nasty trap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 09:26:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 09:26:56 -0000 Subject: [GHC] #11731: Demand analysis: Thunk wrongly determined single-entry In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.bc664e4eb302d6213bf62ec68b87bf12@haskell.org> #11731: Demand analysis: Thunk wrongly determined single-entry -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by nomeata: @@ -3,1 +3,1 @@ - A thunk, marked as single entry, but entered multiple times, in gameteb. + A thunk, marked as single entry, but entered multiple times, in gametb. New description: While working on #10613, I looked a bit more closely at the ticky numbers of single-entry thunks. In all of nofib, I found exactly one fishy result: A thunk, marked as single entry, but entered multiple times, in gametb. I?ll write a preliminary analysis in the comments and either found a bug or a misunderstanding on my side. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 09:38:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 09:38:31 -0000 Subject: [GHC] #11720: pureMD5: Simplifier ticks exhausted In-Reply-To: <047.b040aecf5498d7034551332304a09b9c@haskell.org> References: <047.b040aecf5498d7034551332304a09b9c@haskell.org> Message-ID: <062.b71b64dcfa554a32a75b6792b0148021@haskell.org> #11720: pureMD5: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Does increasing `-fsimpl-tick-factor` help? How much do you need to increase it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 09:41:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 09:41:46 -0000 Subject: [GHC] #11721: GADT-syntax data constructors don't work well with TypeApplications In-Reply-To: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> References: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> Message-ID: <062.f6e1e2aa1effaa1b7ebac126e2d88dd3@haskell.org> #11721: GADT-syntax data constructors don't work well with TypeApplications -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Could we avoid having the special rules by embodying the type the user wrote in the ''wrapper'' for `MkX`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 09:45:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 09:45:32 -0000 Subject: [GHC] #11723: TYPE 'UnboxedTupleRep is a lie In-Reply-To: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> References: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> Message-ID: <062.04fb930b0651735f7feaa588026f9375@haskell.org> #11723: TYPE 'UnboxedTupleRep is a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => goldfire Comment: Sounds as though Richard is already working on a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 10:00:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 10:00:57 -0000 Subject: [GHC] #11725: Performance Regression from 7.8.3 to 7.10.3 In-Reply-To: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> References: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> Message-ID: <061.3ae1dc48bd5c2b45a50be4de64895511@haskell.org> #11725: Performance Regression from 7.8.3 to 7.10.3 -------------------------------------+------------------------------------- Reporter: dominic | Owner: dominic Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): A 3x performance regression looks bad. If you can pin it down more precisely it would be a big help. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 10:10:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 10:10:17 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.b3191535ccaa2c64edb813b5b2fdd68a@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2007 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What of comment:9? I'd prefer not to remove complexity as we add it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 10:40:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 10:40:30 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.0a6b8497ee671a21b5d78f63ac3a70ca@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"2cb55772c5359e5d71d34e5d42a4a7deb6a5d3db/ghc" 2cb5577/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2cb55772c5359e5d71d34e5d42a4a7deb6a5d3db" Remove unnecessary Ord instance for ConLike The Ord instance for ConLike uses Unique order which is bad for determinism. Fortunately it's not used, so we can just delete it. The is part of the effort to make Unique comparisons explicit. Test Plan: ./validate Reviewers: austin, simonmar, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2018 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 11:02:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 11:02:16 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.681a07571fc5fcfe2eb51f0eb873830d@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2007 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah: see Phab:D2023 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 11:27:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 11:27:11 -0000 Subject: [GHC] #11725: Performance Regression from 7.8.3 to 7.10.3 In-Reply-To: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> References: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> Message-ID: <061.2d2059e3a8ac9a3c074bbe3ec7ff2a7d@haskell.org> #11725: Performance Regression from 7.8.3 to 7.10.3 -------------------------------------+------------------------------------- Reporter: dominic | Owner: dominic Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): Here's my proposed approach to pinning it down. 1. Build ghc-8.0.1-rc2 and run my program under it. If the regression is gone then I propose to do no further investigation. 2. git bisect the sources from 7.8.3 to 7.10.3 until I find the change that causes the regression. Does that sound reasonable? Is there any guidance on how to do (2) efficiently and effectively? At the moment I cannot get my sources to compile under ghc-8.0.1-rc2 so my first mini-step is to solve this. I should point out that this is somewhat tangential to my day job although we use RNGs extremely heavily in our application. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 12:21:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 12:21:01 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.4bbfa275cac94e862972141b0f3eb1d9@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I just thought of a way to make forward progress on here: I still have the very long and very tortuous commit history of my development of `TypeInType`. (It's at [https://github.com/goldfirere/ghc/tree/nokinds the nokinds branch of my github fork].) Someone (including perhaps a future me) could just bisect. This would be complicated by the fact that many commits in there do not compile. But git's bisect mechanism has a way of dealing with that (`git bisect skip`). So this process would be quite long, but it also seems quite likely to lead to a solution. Unlike my previous attempts. If anyone has written a script for use with `git bisect run` that might aid in this process, do post! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 12:31:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 12:31:44 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.182a2a56e6a75e24170f9ac029f65ea1@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"c37a583fb9059053f83f1ab0c3cb7eb7047b1a31/ghc" c37a583/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c37a583fb9059053f83f1ab0c3cb7eb7047b1a31" Remove unused substTyWithBinders functions Originally I wanted to only remove substTyWithBindersUnchecked, but since both of them are unused maybe we don't need them. Test Plan: ./validate Reviewers: austin, goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D2025 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 12:49:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 12:49:36 -0000 Subject: [GHC] #11721: GADT-syntax data constructors don't work well with TypeApplications In-Reply-To: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> References: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> Message-ID: <062.db4786a5ba1471622a020ab27690a002@haskell.org> #11721: GADT-syntax data constructors don't work well with TypeApplications -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, we could. Then the wrapper implementation would just match up the tyvars. I don't think it would be that hard. But I've grown increasingly worried about my ability to graduate before my new job starts, and I've just had to draw the line somewhere. I am currently validating my last round of patches and hope very much to focus primarily on my dissertation immediately thereafter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 12:50:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 12:50:38 -0000 Subject: [GHC] #11721: GADT-syntax data constructors don't work well with TypeApplications In-Reply-To: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> References: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> Message-ID: <062.21f1619e08ae9e004f0ffa38308377ee@haskell.org> #11721: GADT-syntax data constructors don't work well with TypeApplications -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That's fine. I just wanted to lay out a design alternative. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 14:27:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 14:27:37 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.faeaba476261a3d4a0eca484b9d3e32f@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I hacked together WorkingConventions/Bisection many months ago while trying to track down #11528 (IIRC). It worked reasonably well, although these things are always bit fiddly. In your case things are a bit trickier still as you don't quite have a nice thumbs-up or thumbs-down result; really you want to be able to look at testsuite allocations and plot them over time. I recently been working on tools for this, although it requires input in the form produced by nomeata's [[https://github.com/nomeata/ghc- speed-logs|ghc-speed builder]] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 14:54:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 14:54:10 -0000 Subject: [GHC] #11165: Testsuite framework failures are too easy to ignore and too hard to find In-Reply-To: <046.b1d93186c62e1a3de1b9e3c053f1008e@haskell.org> References: <046.b1d93186c62e1a3de1b9e3c053f1008e@haskell.org> Message-ID: <061.b8b8fd80583e7da87b861af608c60975@haskell.org> #11165: Testsuite framework failures are too easy to ignore and too hard to find -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2026 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2026 Comment: Phab:D2026 teaches the testsuite driver to at least show the names of the failing tests in the summary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 14:59:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 14:59:24 -0000 Subject: [GHC] #11720: pureMD5: Simplifier ticks exhausted In-Reply-To: <047.b040aecf5498d7034551332304a09b9c@haskell.org> References: <047.b040aecf5498d7034551332304a09b9c@haskell.org> Message-ID: <062.c7ecd85e8b981e89b7515f2b76bc54a2@haskell.org> #11720: pureMD5: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Yes, I need at least a factor of 106. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 15:13:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 15:13:57 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.9023ba41b7b9104133dd47cc1f1b86d1@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I started to put my code on `wip/T10613`. Currently, the extra counters require `-ticky -ticky-allocd -ticky-dyn-thunk` to be shown. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 15:14:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 15:14:47 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.e3c44e6af5c7fdd060af7a1559220e32@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Edward, we are stalled on this ticket, pending input from you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 15:28:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 15:28:36 -0000 Subject: [GHC] #11339: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> References: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> Message-ID: <057.7803f03f31372998c870a93b13d8cf38@haskell.org> #11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interestingly, the code in the Description typechecks fine in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 15:30:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 15:30:17 -0000 Subject: [GHC] #11357: Regression when deriving Generic1 on poly-kinded data family In-Reply-To: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> References: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> Message-ID: <065.013382ca05a24c5837c48aa39b3e0757@haskell.org> #11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Generics, Resolution: | TypeInType, TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T11357 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): So, is comment:9 a release blocker? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 15:30:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 15:30:48 -0000 Subject: [GHC] #11357: Regression when deriving Generic1 on poly-kinded data family In-Reply-To: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> References: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> Message-ID: <065.49d7461af7f892d76ec4147370184d7b@haskell.org> #11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Generics, Resolution: fixed | TypeInType, TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T11357 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 1cbab8baccaf5be0d2938c869aa43a7e227f1395. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 15:31:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 15:31:06 -0000 Subject: [GHC] #11357: Regression when deriving Generic1 on poly-kinded data family In-Reply-To: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> References: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> Message-ID: <065.56b82a3d74aa4024441777715699294d@haskell.org> #11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Generics, Resolution: | TypeInType, TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T11357 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * owner: goldfire => * resolution: fixed => Comment: Re-opening due to comment:9. Richard, do you think you could have a look at this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 15:32:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 15:32:02 -0000 Subject: [GHC] #11723: TYPE 'UnboxedTupleRep is a lie In-Reply-To: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> References: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> Message-ID: <062.b18d4fd63fae852207c7fda1b3dac2bc@haskell.org> #11723: TYPE 'UnboxedTupleRep is a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: high => highest Comment: I'm going to make this 'highest' because Richard's fix sounds imminent. If not, is it a release blocker? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 15:39:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 15:39:11 -0000 Subject: [GHC] #10512: Generic instances missing for Int32, Word64 etc. In-Reply-To: <051.eb2fd15ce978c34ac9303293c51292d1@haskell.org> References: <051.eb2fd15ce978c34ac9303293c51292d1@haskell.org> Message-ID: <066.191770a1f065f3a51ad389fa3a2a6b63@haskell.org> #10512: Generic instances missing for Int32, Word64 etc. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: wontfix | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => wontfix Comment: I'm going to close this, since we have already moved in the direction of not providing `Generic` instances for primitive types with [changeset:"700c42b5e0ffd27884e6bdfa9a940e55449cff6f/ghc" 700c42b5/ghc]. Please re-open if you feel strongly otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 15:39:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 15:39:53 -0000 Subject: [GHC] #9526: Add missing Generic instances in base In-Reply-To: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> References: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> Message-ID: <057.cd595c555455da8df013ae0dc3c412d0@haskell.org> #9526: Add missing Generic instances in base -------------------------------------+------------------------------------- Reporter: nh2 | Owner: dreixel Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: wontfix | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => wontfix Comment: I'm going to close this for the same reasons that I closed #10512. Please re-open if you feel strongly otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 15:43:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 15:43:10 -0000 Subject: [GHC] #11357: Regression when deriving Generic1 on poly-kinded data family In-Reply-To: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> References: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> Message-ID: <065.b7e1fae1c8e59d516f11d72f7e621952@haskell.org> #11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Generics, Resolution: | TypeInType, TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T11357 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:10 simonpj]: > So, is comment:9 a release blocker? I say "no". It seems to be triggered only when you're deriving `Generic1` for a datatype parameterized over mixed type and kind variables. This last bit is possible only with `-XTypeInType` and thus is not a regression. I'm frankly unsure (without more research) as to what the desired behavior should be here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 15:45:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 15:45:16 -0000 Subject: [GHC] #7255: Wrong suggestion when deriving Generic on an instantiated type In-Reply-To: <046.c68e8808a46ffb98e2545098103b8f62@haskell.org> References: <046.c68e8808a46ffb98e2545098103b8f62@haskell.org> Message-ID: <061.ce4ebc2aea6338cf702da8c1789fc456@haskell.org> #7255: Wrong suggestion when deriving Generic on an instantiated type -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | GenCannotDoRep0 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 15:45:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 15:45:49 -0000 Subject: [GHC] #5939: Standalone deriving Generic on type with instantiated arguments In-Reply-To: <046.39c4656124687218c6452298280d108a@haskell.org> References: <046.39c4656124687218c6452298280d108a@haskell.org> Message-ID: <061.89fcee6106944a6f6787421d39f19d14@haskell.org> #5939: Standalone deriving Generic on type with instantiated arguments -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | GenCannotDoRep0 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 15:45:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 15:45:59 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType Message-ID: <047.27a25c470c88bbba69595642672c1832@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: TypeInType, | Operating System: Unknown/Multiple Generics | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From @RyanGlScott, comment:9:ticket:11357: Vanilla datatypes and data family instances are still inconsistent w.r.t. which type variables are considered "instantiated" in a `Generic1` instance. For instance, this is rejected: {{{ ?> data Proxy k (a :: k) = ProxyCon deriving Generic1 }}} {{{ :32:43: error: ? Can't make a derived instance of ?Generic1 (Proxy *)?: Proxy must not be instantiated; try deriving `Proxy k a' instead ? In the data declaration for ?Proxy? }}} And rightfully so, since the visible kind binder `k` is instantiated to `*`. But now it's possible to have an equivalent instance for a data family that squeaks past this check! {{{ ?> data family ProxyFam (a :: y) (b :: z) ?> data instance ProxyFam k (a :: k) = ProxyFamCon deriving Generic1 ==================== Derived instances ==================== Derived instances: instance GHC.Generics.Generic1 (Ghci13.ProxyFam *) where ... }}} [Ryan needs] to investigate further to see why this is the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 15:46:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 15:46:44 -0000 Subject: [GHC] #11357: Regression when deriving Generic1 on poly-kinded data family In-Reply-To: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> References: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> Message-ID: <065.c10786802f69ccb58eb09967e23d971b@haskell.org> #11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Generics, Resolution: fixed | TypeInType, TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T11357 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: I've spun off comment:9 into #11732. I don't think it's closely related to the original problem reported here, which was a real regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 16:02:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 16:02:30 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.80b298d8a70f686bfd9e3c2f99534247@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [https://ghc.haskell.org/trac/ghc/ticket/11357#comment:13 goldfire]: > I'm frankly unsure (without more research) as to what the desired behavior should be here. The reason for this restriction dates back to #5939, when someone wanted to try to standalone derive this: {{{#!hs data T a = T a deriving instance Generic (T Bool) }}} This seems intuitive, but [https://ghc.haskell.org/trac/ghc/ticket/5939#comment:1 Pedro couldn't find a way to make it work], since the generated `Rep` type only uses information from `T`'s `TyCon`, so there was no good way to relate the `TyVar` `a` with `Bool`. He then declared that [https://ghc.haskell.org/trac/ghc/ticket/5939#comment:2 such instances should be rejected altogether], hence this instantiation check. Whether the instantiation check is a good idea (and ways to get around it) are a side issue, I feel like. The real issue is that data family instances classify their types as visible/invisible in a completely different manner than vanilla datatypes. I did a bit of digging into the `ProxyFam` example above. With this: {{{#!hs data Proxy k (a :: k) = ProxyCon deriving Generic1 }}} [http://git.haskell.org/ghc.git/blob/c37a583fb9059053f83f1ab0c3cb7eb7047b1a31:/compiler/types/Type.hs#l1456 partitionInvisibles user_tc id tc_args] yields `([],[*])`, like you'd expect (where `k` has been instantiated to `*` due to `Generic1` being of kind `(* -> *) -> Constraint`). But with this: {{{#!hs data family ProxyFam (a :: y) (b :: z) data instance ProxyFam k (a :: k) = ProxyFamCon deriving Generic1 }}} [http://git.haskell.org/ghc.git/blob/c37a583fb9059053f83f1ab0c3cb7eb7047b1a31:/compiler/types/Type.hs#l1456 partitionInvisibles user_tc id tc_args] yields `([*],[])`! Somehow, `k` is being treated as invisible when it clearly shouldn't. It's beyond my pay grade to speculate on //why// that is, but it's definitely [https://ghc.haskell.org/trac/ghc/ticket/11376#comment:12 not the only] `-XTypeInType`-related data family discrepancy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 16:22:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 16:22:49 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.d84914cee65e46ce0a4c5753bcda8e7f@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I claim that {{{ data Proxy k (a :: k) = ProxyCon deriving Generic1 }}} should fail outright. I don't think GHC should be in the business of inferring values for visible parameters like `k`, even when it could. Instead, it should be this: {{{ deriving instance Generic1 (Proxy *) }}} Note that this applies to `Functor` as much as it does to `Generic1`. As for the `partitionInvisibles` piece: yes, that is all suspicious. I conjecture that we should never call `partitionInvisibles` on a data ''instance'' tycon, but only on the data ''family'' tycon. Perhaps we need to teach `partitionInvisibles` how to work on data instances. But not today, I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 16:25:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 16:25:41 -0000 Subject: [GHC] #11723: TYPE 'UnboxedTupleRep is a lie In-Reply-To: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> References: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> Message-ID: <062.92439b89d327190a0412718ed8d75393@haskell.org> #11723: TYPE 'UnboxedTupleRep is a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Imminent Imminent Yes Yes. Validating (again) right this very moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 16:38:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 16:38:30 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.c9fb1b3eeecb23985944c5c89e25bbdb@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:2 goldfire]: > I claim that > > {{{ > data Proxy k (a :: k) = ProxyCon deriving Generic1 > }}} > > should fail outright. I don't think GHC should be in the business of inferring values for visible parameters like `k`, even when it could. Agreed. > Instead, it should be this: > > {{{ > deriving instance Generic1 (Proxy *) > }}} I'm OK with this idea, but we'd need to be able to teach `gen_Generic_binds` about substituting type variables for user-supplied types somehow, since they are reflected in the generated `Rep`/`Rep1` associated type instance. I have no idea how challenging that would be to implement. > Note that this applies to `Functor` as much as it does to `Generic1`. So you'd propose applying an instantiation check to every class in a `deriving` clause, then? > As for the `partitionInvisibles` piece: yes, that is all suspicious. I conjecture that we should never call `partitionInvisibles` on a data ''instance'' tycon, but only on the data ''family'' tycon. That's what we're doing at the moment, no? We're calling `filterOutInvisibleTypes` in `canDoGenerics` [http://git.haskell.org/ghc.git/blob/c37a583fb9059053f83f1ab0c3cb7eb7047b1a31:/compiler/typecheck/TcGenGenerics.hs#l155 here] (which indirectly invokes `partitionInvisibles`), and your [https://git.haskell.org/ghc.git/commitdiff/1eefedf7371778d1721d9af9247c2eff12ae7417 earlier patch] changed the `TyCon` being passed to `filterOutInvisibleTypes` to the data family tycon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 17:00:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 17:00:56 -0000 Subject: [GHC] #11733: Undeclared identifier 'CLOCK_PROCESS_CPUTIME_ID' on OS X Message-ID: <044.34d6ef1f50509835f04a609c09b1a0b3@haskell.org> #11733: Undeclared identifier 'CLOCK_PROCESS_CPUTIME_ID' on OS X -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems cb3456d82eaa8cea6b3 breaks OSX: {{{ ClockGetTime.hsc:24:16: error: use of undeclared identifier 'CLOCK_PROCESS_CPUTIME_ID' ..../inplace/lib/template-hsc.h:36:41: note: expanded from macro 'hsc_const' hsc_printf ("%lld", (long long)(x)); }}} Probably also a problem on *BSD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 17:01:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 17:01:57 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.9bdee330bc6ccd761fd49122174b245e@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): No instantiation check. But what GHC does right now is, for every class in a datatype's `deriving` clause, drop as many type parameters as there are arguments to the class being derived. For example {{{ data Foo a deriving (Show, Functor) }}} GHC knows that we mean `instance Show (Foo a)` and `instance Functor Foo`. But {{{ data Proxy k (a :: k) deriving Functor }}} would try `instance Functor (Proxy k)`, which is ill-kinded. GHC is surely clever enough to figure out that it should really do `instance Functor (Proxy *)`, but I think it should refrain from doing this. More to the point of this ticket: I have a bad feeling my fix for #11357 is utterly broken, in that it uses the `tc_args` from the instance tycon despite using visibilities from the parent tycon. Of course, the `tc_args` don't match up. I suppose a `mkFamilyTyConApp` would work nicely here. But you seem to know much more about generics in GHC than I do. Do you think you could make this fix? I really do think we just need to use `mkFamilyTyConApp` in the right spot here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 17:03:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 17:03:25 -0000 Subject: [GHC] #11733: Undeclared identifier 'CLOCK_PROCESS_CPUTIME_ID' on OS X In-Reply-To: <044.34d6ef1f50509835f04a609c09b1a0b3@haskell.org> References: <044.34d6ef1f50509835f04a609c09b1a0b3@haskell.org> Message-ID: <059.a21512d976d06ed20ee9d53019bde897@haskell.org> #11733: Undeclared identifier 'CLOCK_PROCESS_CPUTIME_ID' on OS X -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): This may help: http://stackoverflow.com/questions/5167269/clock-gettime- alternative-in-mac-os-x -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 17:03:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 17:03:31 -0000 Subject: [GHC] #11339: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> References: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> Message-ID: <057.575f963443813a775d7f2f38d18bd453@haskell.org> #11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): So it does. How maddening. I don't know why. I stand by my analysis that the original program should be rejected according to the monomorphism restriction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 17:13:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 17:13:08 -0000 Subject: [GHC] #11734: coercionKind and coercionKindRole do potentially inefficient repeated substitutions Message-ID: <046.d367fee0cb0a16696c2ac5d1b5577dd1@haskell.org> #11734: coercionKind and coercionKindRole do potentially inefficient repeated substitutions -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As pointed out by @simonpj in phab:D2024: > I hate the idea of substituting for a single type variable at a time. Its a recipe for non-linear behaviour. Maybe we should gather the foralls and the type args and try to do it all at once? > > Anyway, that's not the fault of this patch, although this patch may make it worse. Because when substituting into a monotype, the inscope set is not used; but if we do it one at a time we substitute into a`ForallCo` so we do inspect the inscope set. > > See Type.piResultTys. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 17:13:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 17:13:33 -0000 Subject: [GHC] #11735: Optimize coercionKind Message-ID: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, the `ForAllCo` case of `coercionKind` does an inefficient one- variable substitution. This could be improved by looking for nested `ForAllCo`s. Furthermore, perhaps we don't need an in-scope set and the full substitution machinery here. The subst is simply propagating the update of a tyvar's kind. No structural changes at all. No need for smart coercion constructors or other processing. So if we're going to optimize this, it might be worth making a specialized version of `subst_ty` and `subst_co` that operate over a `VarEnv Var` instead of a full substitution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 17:47:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 17:47:08 -0000 Subject: [GHC] #11734: coercionKind and coercionKindRole do potentially inefficient repeated substitutions In-Reply-To: <046.d367fee0cb0a16696c2ac5d1b5577dd1@haskell.org> References: <046.d367fee0cb0a16696c2ac5d1b5577dd1@haskell.org> Message-ID: <061.4039ca7a736e9b11eef2553097e4bcef@haskell.org> #11734: coercionKind and coercionKindRole do potentially inefficient repeated substitutions -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: I'm arbitrarily deciding #11735 as the canonical home for this idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 17:47:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 17:47:38 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.c6259b8bba9bc7c054de264dfb40d5dd@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This originated from commentary on Phab:D2024, though you don't have to read that to understand this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 18:04:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 18:04:10 -0000 Subject: [GHC] #11165: Testsuite framework failures are too easy to ignore and too hard to find In-Reply-To: <046.b1d93186c62e1a3de1b9e3c053f1008e@haskell.org> References: <046.b1d93186c62e1a3de1b9e3c053f1008e@haskell.org> Message-ID: <061.d0622460c30f33c3a0eee82c5bcc6b09@haskell.org> #11165: Testsuite framework failures are too easy to ignore and too hard to find -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2026 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Hooray! I just got caught by this trap. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 18:33:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 18:33:09 -0000 Subject: [GHC] #11736: Allow unsaturated uses of unlifted types in Core Message-ID: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> #11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently Core Lint checks for unsaturated uses of unlifted types in . These are easily produced in the new type-indexed `Typeable` scheme. For instance, consider solving for `Typeable # (Array# Int)`: * We decompose the application into wanteds `Typeable (* -> #) Array#` and `Typeable * Int` * We construct dictionaries for both, giving us a term `typeRepArray# :: TypeRep (* -> #) Array#` While nothing seems to blow up with this patch, {{{#!patch diff --git a/compiler/coreSyn/CoreLint.hs b/compiler/coreSyn/CoreLint.hs index 99625c9..2c401de 100644 --- a/compiler/coreSyn/CoreLint.hs +++ b/compiler/coreSyn/CoreLint.hs @@ -1040,7 +1040,7 @@ lintType ty@(TyConApp tc tys) = lintType ty' -- Expand type synonyms, so that we do not bogusly complain -- about un-saturated type synonyms - | isUnliftedTyCon tc || isTypeSynonymTyCon tc || isTypeFamilyTyCon tc + | isTypeSynonymTyCon tc || isTypeFamilyTyCon tc -- Also type synonyms and type families , length tys < tyConArity tc = failWithL (hang (text "Un-saturated type application") 2 (ppr ty)) }}} I otherwise have no reason to believe that this is safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 18:34:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 18:34:41 -0000 Subject: [GHC] #11736: Allow unsaturated uses of unlifted types in Core In-Reply-To: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> References: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> Message-ID: <061.9d0e30757872a1c581bd059f2932f000@haskell.org> #11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I believe this is OK. But we're beyond the scope of any proof I'm aware of for safety -- none have considered unlifted types, to my knowledge. Simon? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 18:41:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 18:41:32 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.5802287ca4122cd610593fe62b7cf1a9@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2010 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've consolidated some notes on the status of my implementation on the [[wiki:Typeable/BenGamari#Status|Wiki page]]. I've included a list of related tickets for things which need to be fixed elsewhere in the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 18:45:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 18:45:45 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.b9cb73d89aca8d20f12af8eca973e861@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D669, Wiki Page: | Phab:D2027 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: Phab:D669 => Phab:D669, Phab:D2027 @@ -6,1 +6,1 @@ - {{{ + {{{#!hs New description: Since record construction binds more tightly than function application, no parentheses are needed when passing a constructor with record syntax to a function constructor. As a result, we can pass {{{Just A {x = 5}}}} as shown below. {{{#!hs module Main where data A = A {x :: Int} deriving (Show) main :: IO () main = print $ Just A {x = 5} }}} But we get the result in the GHCi session below: {{{ *Main> main Just (A {x = 5}) }}} I tried looking through {{{TcGenDeriv}}}, but didn't figure out quite where the parenifying was done. {{{nested_compose_Expr}}}? {{{show_thingies}}}? I just wanted to make a ticket for general knowledge. Of course, this is not a real bug. Perhaps you could reclassify it as a feature. Either way, it would be nice to have. -- Comment: Phab:D2027 reverts to the previous behavior including redundant parens as described in comment:36. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 19:15:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 19:15:43 -0000 Subject: [GHC] #11737: Make validate --testsuite-only behave correctly w.r.t. bindisttest Message-ID: <047.2e7bc1a52ac540caae205e25ca4d0fee@haskell.org> #11737: Make validate --testsuite-only behave correctly w.r.t. bindisttest -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm in the process of validating. One of the error messages is a bit wrong, so I change the error message code. But the change is more than just the phrasing of the message; it's conceivable that a mistake in this edit will cause misbehavior, but only on rejected programs. So I determine that I don't need to re-run the full validation, but just recompile and run the testsuite. I recompile. I say `validate --testsuite-only`. And then, after I read the results, I realize that validation uses the bindist version of the GHC, which isn't the one that I just built. So have to do it all again. Thus, request: have `--testsuite-only` not use the bindist version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:10:09 -0000 Subject: [GHC] #11635: Higher-rank kind in datatype definition rejected In-Reply-To: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> References: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> Message-ID: <060.e7f3b2d48ce27be687c510f2c39d8778@haskell.org> #11635: Higher-rank kind in datatype definition rejected -------------------------------------+------------------------------------- Reporter: phadej | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"1701255c06fed2aa2811f7f29f108d88fc4d6f26/ghc" 1701255/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1701255c06fed2aa2811f7f29f108d88fc4d6f26" Fix #11635 / #11719. Instead of creating a new meta-tyvar and then unifying it with a known kind in a KindedTyVar in a LHsQTyVars, just use the known kind. Sadly, this still doesn't make #11719 usable, because while you can now define a higher-kinded type family, you can't write any equations for it, which is a larger problem. test cases: dependent/should_compile/T{11635,11719} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:10:09 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.ab16e0be674e46a44abfa37287478448@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"0706a103ae8c9c61e6bbaadd16b32da76aa5a749/ghc" 0706a103/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0706a103ae8c9c61e6bbaadd16b32da76aa5a749" Add two small optimizations. (#11196) - Optimize zonking * to avoid allocation. - Try to avoid looking at the free variables of a type in the pure unifier. We need look at the variables only in the case of a forall. The performance results updates included in this also include a regression, but the regression is not due to this patch. When validating previous patches, the test case failed, but I was unable to reproduce outside of validation, so I let it go by, thinking the failure was spurious. Upon closer inspection, the perf number was right at the line, and the wibble between a valiation environment and a regular test run was enough to make the difference. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:10:09 -0000 Subject: [GHC] #11712: Very confusing error message with -fprint-explicit-kinds In-Reply-To: <046.05390a91e58122ea87d7f537d0159d7b@haskell.org> References: <046.05390a91e58122ea87d7f537d0159d7b@haskell.org> Message-ID: <061.4346f13c093a97e2dcb05c6b084cf26c@haskell.org> #11712: Very confusing error message with -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"0b89064cc67cb4fbdba0044ab59a17b20bbde1db/ghc" 0b89064/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0b89064cc67cb4fbdba0044ab59a17b20bbde1db" Make equality print better. (#11712) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:10:09 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.601f290c9c1691a5e7c532a42c26fe29@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"1701255c06fed2aa2811f7f29f108d88fc4d6f26/ghc" 1701255/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1701255c06fed2aa2811f7f29f108d88fc4d6f26" Fix #11635 / #11719. Instead of creating a new meta-tyvar and then unifying it with a known kind in a KindedTyVar in a LHsQTyVars, just use the known kind. Sadly, this still doesn't make #11719 usable, because while you can now define a higher-kinded type family, you can't write any equations for it, which is a larger problem. test cases: dependent/should_compile/T{11635,11719} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:10:09 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.1a5c559d5c92b702863946f7a9c8438e@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | dependent/should_fail/T11334 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"f8ab575404b726b499e72343b7220e9213880dd4/ghc" f8ab575/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f8ab575404b726b499e72343b7220e9213880dd4" Rename test for #11334 to 11334b, fixing conflict }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:10:09 -0000 Subject: [GHC] #11512: An unwritten kind variable is "specified", when it shouldn't be. In-Reply-To: <047.7a36187500c6876edf467692a28ef5b3@haskell.org> References: <047.7a36187500c6876edf467692a28ef5b3@haskell.org> Message-ID: <062.c34e0186070fabf38c99d816e4b0a437@haskell.org> #11512: An unwritten kind variable is "specified", when it shouldn't be. -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11512 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"35e937973f61a7e5534ecd0b1c67111cd82d4238/ghc" 35e93797/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="35e937973f61a7e5534ecd0b1c67111cd82d4238" Track specified/invisible more carefully. In particular, this allows correct tracking of specified/invisible for variables in Haskell98 data constructors and in pattern synonyms. GADT-syntax constructors are harder, and are left until #11721. This was all inspired by Simon's comments to my fix for #11512, which this subsumes. Test case: ghci/scripts/TypeAppData [skip ci] (The test case fails because of an unrelated problem fixed in the next commit.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:10:09 -0000 Subject: [GHC] #11723: TYPE 'UnboxedTupleRep is a lie In-Reply-To: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> References: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> Message-ID: <062.de78608a97223660ea5b1ba9e75e11b4@haskell.org> #11723: TYPE 'UnboxedTupleRep is a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"d978c5ed93482473b81bbe52bedf37d45d1e1029/ghc" d978c5e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d978c5ed93482473b81bbe52bedf37d45d1e1029" Fix #11723 and #11724. Test cases: typecheck/should_fail/T1172{3,4} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:10:09 -0000 Subject: [GHC] #11721: GADT-syntax data constructors don't work well with TypeApplications In-Reply-To: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> References: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> Message-ID: <062.9c538da9241a1dd58087937fbf217c15@haskell.org> #11721: GADT-syntax data constructors don't work well with TypeApplications -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"35e937973f61a7e5534ecd0b1c67111cd82d4238/ghc" 35e93797/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="35e937973f61a7e5534ecd0b1c67111cd82d4238" Track specified/invisible more carefully. In particular, this allows correct tracking of specified/invisible for variables in Haskell98 data constructors and in pattern synonyms. GADT-syntax constructors are harder, and are left until #11721. This was all inspired by Simon's comments to my fix for #11512, which this subsumes. Test case: ghci/scripts/TypeAppData [skip ci] (The test case fails because of an unrelated problem fixed in the next commit.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:10:09 -0000 Subject: [GHC] #11724: Must check for representation polymorphism in datatype declarations In-Reply-To: <047.e984e50f4246346ca88e79b8cc73fa2e@haskell.org> References: <047.e984e50f4246346ca88e79b8cc73fa2e@haskell.org> Message-ID: <062.7dd2f427ea655e3e462a336655079f26@haskell.org> #11724: Must check for representation polymorphism in datatype declarations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"d978c5ed93482473b81bbe52bedf37d45d1e1029/ghc" d978c5e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d978c5ed93482473b81bbe52bedf37d45d1e1029" Fix #11723 and #11724. Test cases: typecheck/should_fail/T1172{3,4} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:28:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:28:48 -0000 Subject: [GHC] #11635: Higher-rank kind in datatype definition rejected In-Reply-To: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> References: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> Message-ID: <060.278a87d25e5ed3c118afcb4c374ccfea@haskell.org> #11635: Higher-rank kind in datatype definition rejected -------------------------------------+------------------------------------- Reporter: phadej | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T11635 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => dependent/should_compile/T11635 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:32:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:32:38 -0000 Subject: [GHC] #11595: Merge some TypeInType fixes In-Reply-To: <047.0b5fec0bd3fc52dea06510ee7b852368@haskell.org> References: <047.0b5fec0bd3fc52dea06510ee7b852368@haskell.org> Message-ID: <062.83bce931979c1c0e84af5b9c635aefae@haskell.org> #11595: Merge some TypeInType fixes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: closed => merge Comment: More in the same vein. * af2f7f90dd0aaae0e33d1f8064377d1657f180a6 * 01b29ebd25aceef8c35ea1cc3eabb6dafbb55daa * 0706a103ae8c9c61e6bbaadd16b32da76aa5a749 * f8ab575404b726b499e72343b7220e9213880dd4 * 3e1b8824c849d063c7354dbdf63ae2910cf0fdfc * 35e937973f61a7e5534ecd0b1c67111cd82d4238 * 5c0c751ab2deb4b03b8a2055d4f60d2574cae32f -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:33:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:33:22 -0000 Subject: [GHC] #11712: Very confusing error message with -fprint-explicit-kinds In-Reply-To: <046.05390a91e58122ea87d7f537d0159d7b@haskell.org> References: <046.05390a91e58122ea87d7f537d0159d7b@haskell.org> Message-ID: <061.394b75300c4f1152e8bab0ed4d3cb3f5@haskell.org> #11712: Very confusing error message with -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:33:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:33:56 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.962df417e7201e327368fe320ba0932f@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_compile/T11719 * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:34:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:34:24 -0000 Subject: [GHC] #11723: TYPE 'UnboxedTupleRep is a lie In-Reply-To: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> References: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> Message-ID: <062.1adb2285e8b1c61a9b128813bf9e11a7@haskell.org> #11723: TYPE 'UnboxedTupleRep is a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11723 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_fail/T11723 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:35:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:35:19 -0000 Subject: [GHC] #11724: Must check for representation polymorphism in datatype declarations In-Reply-To: <047.e984e50f4246346ca88e79b8cc73fa2e@haskell.org> References: <047.e984e50f4246346ca88e79b8cc73fa2e@haskell.org> Message-ID: <062.997b825284a6d7f44164c929f7e11c6e@haskell.org> #11724: Must check for representation polymorphism in datatype declarations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11724 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_fail/T11724 * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 20:46:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 20:46:49 -0000 Subject: [GHC] #11738: A command to remove modules from the target list Message-ID: <045.65676ccdbab0a07c8eeb4e3b8e859349@haskell.org> #11738: A command to remove modules from the target list -------------------------------------+------------------------------------- Reporter: jh3141 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Maybe it's because I'm a newbie, or possibly just because having the separate lists is a little confusing generally, but I quite often accidentally add a module to the target list (:a modulename) when I meant to add it to the current scope (:m +modulename). A way of *removing* the module after doing this would be useful, because it often results in errors when I use :reload. The following stack overflow question contains an answer with a suggested implementation, which could be useful: http://stackoverflow.com/questions/36139011/how-to-remove-module-from- target-list-in-ghci -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 21:36:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 21:36:21 -0000 Subject: [GHC] #11739: Simplify axioms; should be applied to types Message-ID: <047.1dec82d6884084079fbacd762d819ea8@haskell.org> #11739: Simplify axioms; should be applied to types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Simon PJ says: In `Note [Coercion axioms applied to coercions]` in Coercion, we find the justification for allowing coercions as arguments to axioms. The goal is to add a bit of extra expressiveness, so that optimisations can be done pair-wise. But the example shows that the new expressiveness is not expressive enough! Rather than give up (as you do in !OptCoercion) maybe we should re-examine the assumption. How could we optimise if axioms could only be instantiated with types, not coercions. Which would be a LOT simpler! Let's take the example from the Note: {{{ C a : t[a] ~ F a g : b ~ c }}} and we want to optimize {{{ sym (C b) ; t[g] ; C c :: F b ~ F c }}} One possibility is to perform a 3-component optimisation, but that's a bit horrible. But what about this: push the `t[g]` ''past'' the axiom rather than ''into'' it. For example {{{ t[g] ; C c ==> C b ; F g where t[g] : t[b]~t[c] C c : t[c] ~ F c }}} If we use this to move axioms to the right, I think we'll get the same optimisations as now, but with a simpler system. Does that seem right? Now it becomes clearer that you can't always commute the things. {{{ ax : F a a ~ a; F a b ~ b co :: Id Bool ~ Bool }}} If we have {{{ (F co ; ax[1] Int Bool) : F Int (Id Bool) ~ Bool }}} then we might try to commute `co` past the axiom thus: {{{ ax[1] Int (Id Bool) ; co }}} but now (as you point out) the ax[1] is not necessarily OK. But I hazard that the lack of the commuting isn't going to lose useful optimisations. So in some ways we are no further forward (an optimisation is only sometimes OK), but I feel MUCH happier about simplifying the axiom- applied-to-coercion stuff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 22:14:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 22:14:46 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.073e3947951673a0543372bf734d1155@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"685398ebc5c8377597714cd8c3e97439d32e3a02/ghc" 685398eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="685398ebc5c8377597714cd8c3e97439d32e3a02" Use the correct in-scope set in coercionKind The free vars of `ty2` need to be in scope to satisfy the substitution invariant. As far as I can tell we don't have the free vars of `ty2` when substituting, so unfortunately we have to compute them. Test Plan: ./validate Reviewers: austin, bgamari, simonpj, goldfire Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D2024 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 22:27:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 22:27:09 -0000 Subject: [GHC] #11740: RFC kind synonyms Message-ID: <051.0e72c4f1c3d54cad33a28cc5a9b7fcc3@haskell.org> #11740: RFC kind synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Are any of these useful now that we have kind synonyms: {{{#!hs -- Control.Category type Cat k = k -> k -> Type -- Data.Kind type Kind = Type type Types = [Type] type TypeClass = Type -> Constraint }}} `Cat` is not limited to `Control.Category` but applies in all [https://github.com/ekmett/hask/blob/master/src/Hask/Category.hs#L68 hask], [https://github.com/mikeizbicki/subhask/blob/b5433b959914d8214bcc4f130ff1b3ddbe589e50/src/SubHask/Category.hs#L108 subhask] and is defined by [https://github.com/ttuegel/recategorize/blob/master/src/Category/Category.hs#L81 recategorize]. It lets you rewrite: {{{#!hs -- newtype Yoneda (p :: i -> i -> *) (a :: i) (b :: i) = Op { getOp :: p b a } newtype Yoneda :: Cat i -> Cat i where Op :: { getOp :: p b a } -> Yoneda p a b -- type family Op (p :: i -> i -> *) :: i -> i -> * where type family Op (p :: Cat i) :: Cat i where Op (Yoneda p) = p Op p = Yoneda p -- data CatT (cat :: * -> * -> *) (a :: k) (b :: k) (cat1 :: k -> k -> *) (cat2 :: k -> k -> *) data CatT (cat :: Cat Type) (a :: k) (b :: k) (cat1 :: Cat k) (cat2 :: Cat k) -- class (Category' (Dom f), Category' (Cod f)) => Functor (f :: i -> j) where -- type Dom f :: i -> i -> * -- type Cod f :: j -> j -> * class (Category' (Dom f), Category' (Cod f)) => Functor (f :: i -> j) where type Dom f :: Cat i type Cod f :: Cat j -- data Nat (p :: i -> i -> *) (q :: j -> j -> *) (f :: i -> j) (g :: i -> j) where data Nat (p :: Cat i) (q :: Cat j) (f :: i -> j) (g :: i -> j) where -- instance Cartesian ((->) :: * -> * -> *) where instance Cartesian ((->) :: Cat Type) where }}} and {{{#!hs -- class (f x, g x) => And (f :: * -> Constraint) (g :: * -> Constraint) (x :: *) -- instance (f x, g x) => And (f :: * -> Constraint) (g :: * -> Constraint) (x :: *) class (f x, g x) => And (f :: TypeClass) (g :: TypeClass) (x :: *) instance (f x, g x) => And (f :: TypeClass) (g :: TypeClass) (x :: *) -- ToContext (fs :: [TypeClass]) :: TypeClass where type family ToContext (fs :: [* -> Constraint]) :: * -> Constraint where ToContext (f:g:fs) = And f (ToContext (g:fs)) ToContext '[f] = f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 22:29:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 22:29:34 -0000 Subject: [GHC] #11740: RFC kind synonyms In-Reply-To: <051.0e72c4f1c3d54cad33a28cc5a9b7fcc3@haskell.org> References: <051.0e72c4f1c3d54cad33a28cc5a9b7fcc3@haskell.org> Message-ID: <066.46486c6718daf0b9b8c4b06cedcf2a82@haskell.org> #11740: RFC kind synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I write `type Fun = i -> j` in my own code: {{{#!hs class (Category' (Dom f), Category' (Cod f)) => Functor (f :: Fun i j) where data Nat (p :: Cat i) (q :: Cat j) (f :: Fun i j) (g :: Fun i j) where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 21 22:41:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Mar 2016 22:41:02 -0000 Subject: [GHC] #11740: RFC kind synonyms In-Reply-To: <051.0e72c4f1c3d54cad33a28cc5a9b7fcc3@haskell.org> References: <051.0e72c4f1c3d54cad33a28cc5a9b7fcc3@haskell.org> Message-ID: <066.04ac3ab7498218275c150c2fff0ad0e8@haskell.org> #11740: RFC kind synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -66,1 +66,1 @@ - -- ToContext (fs :: [TypeClass]) :: TypeClass where + -- ToContext (fs :: [* -> Constraint]) :: * -> Constraint where @@ -68,1 +68,1 @@ - ToContext (fs :: [* -> Constraint]) :: * -> Constraint where + ToContext (fs :: [TypeClass]) :: TypeClass where New description: Are any of these useful now that we have kind synonyms: {{{#!hs -- Control.Category type Cat k = k -> k -> Type -- Data.Kind type Kind = Type type Types = [Type] type TypeClass = Type -> Constraint }}} `Cat` is not limited to `Control.Category` but applies in all [https://github.com/ekmett/hask/blob/master/src/Hask/Category.hs#L68 hask], [https://github.com/mikeizbicki/subhask/blob/b5433b959914d8214bcc4f130ff1b3ddbe589e50/src/SubHask/Category.hs#L108 subhask] and is defined by [https://github.com/ttuegel/recategorize/blob/master/src/Category/Category.hs#L81 recategorize]. It lets you rewrite: {{{#!hs -- newtype Yoneda (p :: i -> i -> *) (a :: i) (b :: i) = Op { getOp :: p b a } newtype Yoneda :: Cat i -> Cat i where Op :: { getOp :: p b a } -> Yoneda p a b -- type family Op (p :: i -> i -> *) :: i -> i -> * where type family Op (p :: Cat i) :: Cat i where Op (Yoneda p) = p Op p = Yoneda p -- data CatT (cat :: * -> * -> *) (a :: k) (b :: k) (cat1 :: k -> k -> *) (cat2 :: k -> k -> *) data CatT (cat :: Cat Type) (a :: k) (b :: k) (cat1 :: Cat k) (cat2 :: Cat k) -- class (Category' (Dom f), Category' (Cod f)) => Functor (f :: i -> j) where -- type Dom f :: i -> i -> * -- type Cod f :: j -> j -> * class (Category' (Dom f), Category' (Cod f)) => Functor (f :: i -> j) where type Dom f :: Cat i type Cod f :: Cat j -- data Nat (p :: i -> i -> *) (q :: j -> j -> *) (f :: i -> j) (g :: i -> j) where data Nat (p :: Cat i) (q :: Cat j) (f :: i -> j) (g :: i -> j) where -- instance Cartesian ((->) :: * -> * -> *) where instance Cartesian ((->) :: Cat Type) where }}} and {{{#!hs -- class (f x, g x) => And (f :: * -> Constraint) (g :: * -> Constraint) (x :: *) -- instance (f x, g x) => And (f :: * -> Constraint) (g :: * -> Constraint) (x :: *) class (f x, g x) => And (f :: TypeClass) (g :: TypeClass) (x :: *) instance (f x, g x) => And (f :: TypeClass) (g :: TypeClass) (x :: *) -- ToContext (fs :: [* -> Constraint]) :: * -> Constraint where type family ToContext (fs :: [TypeClass]) :: TypeClass where ToContext (f:g:fs) = And f (ToContext (g:fs)) ToContext '[f] = f }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 00:13:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 00:13:39 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.897d94b15b83833d60fd1b4332086dfc@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:4 goldfire]: > But > > {{{ > data Proxy k (a :: k) deriving Functor > }}} > > would try `instance Functor (Proxy k)`, which is ill-kinded. GHC is surely clever enough to figure out that it should really do `instance Functor (Proxy *)`, but I think it should refrain from doing this. Right, that's what I mean by "instantiation check". Currently, GHC [http://git.haskell.org/ghc.git/blob/685398ebc5c8377597714cd8c3e97439d32e3a02:/compiler/typecheck/TcDeriv.hs#l605 unifies the kind of the typeclass] with the kind of the datatype. If, in this process, it ends up instantiating a visible `TyBinder` in the datatype with something other than a type variable, it should be rejected. > More to the point of this ticket: I have a bad feeling my fix for #11357 is utterly broken, in that it uses the `tc_args` from the instance tycon despite using visibilities from the parent tycon. Of course, the `tc_args` don't match up. I suppose a `mkFamilyTyConApp` would work nicely here. > > But you seem to know much more about generics in GHC than I do. Do you think you could make this fix? I really do think we just need to use `mkFamilyTyConApp` in the right spot here. I'm not sure what help `mkFamilyTyConApp` would provide, to be honest. Are you saying to do something like this: {{{#!hs let (tc', tc_args') = splitTyConApp (mkFamilyTyConApp tc tc_args) }}} If so, wouldn't you'd end up with the data //family// tycon and arguments? I tried this, and while it seemed to fix the above issue, it comically broke something else: {{{#!hs data family URec p a data instance URec Char a = UChar }}} Since it mistakenly believes that `URec Char a` is too instantiated (it shouldn't even be considering `Char` at all, which is normally the case when you get your type arguments from [http://git.haskell.org/ghc.git/blob/685398ebc5c8377597714cd8c3e97439d32e3a02:/compiler/typecheck/TcDeriv.hs#l751 tcLookupDataFamInst]). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 01:58:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 01:58:09 -0000 Subject: [GHC] #11740: RFC kind synonyms In-Reply-To: <051.0e72c4f1c3d54cad33a28cc5a9b7fcc3@haskell.org> References: <051.0e72c4f1c3d54cad33a28cc5a9b7fcc3@haskell.org> Message-ID: <066.f0621784aa4f480c62932b8a5689ae47@haskell.org> #11740: RFC kind synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think these are fine definitions for a separate library, but I don't personally see a compelling reason to put them into, say, `base` at this point. It's just too soon to know what will be helpful and widely used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 02:07:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 02:07:43 -0000 Subject: [GHC] #11741: -Wredundant-constraints is not in the manual's flag reference Message-ID: <047.f9b39d0f99f8346da2ca26cd49cc61f2@haskell.org> #11741: -Wredundant-constraints is not in the manual's flag reference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 02:20:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 02:20:29 -0000 Subject: [GHC] #10296: Segfaults when using dynamic wrappers and concurrency In-Reply-To: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> References: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> Message-ID: <061.c983161fb7365674c1cd990892838aa3@haskell.org> #10296: Segfaults when using dynamic wrappers and concurrency -------------------------------------+------------------------------------- Reporter: bitonic | Owner: jme Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2031 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jme): * status: new => patch * differential: => Phab:D2031 Comment: In the example above, each call to `wrap` allocates a new stable pointer, which is then dereferenced when `call_fun` calls back into Haskell. Since the stable pointers are not freed, the table holding them is periodically enlarged (using `realloc()`). When one of these reallocations moves the table just as it is being read by another thread (to dereference a stable pointer), a segfault can occur. The fix provided by Phab:D2031 is rather simplistic: it eliminates the freeing of the old table during reallocation, thus ensuring the table can continue to be safely read. While this approach allows dereferences to remain lock-free, it clearly wastes space (roughly twice the memory is now required to hold the stable pointer table). If this is an issue, it should be relatively straightforward to eliminate the extra memory consumption without adversely affecting performance (albeit with some added complexity). Let me know if such an implementation would be preferable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 03:14:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 03:14:32 -0000 Subject: [GHC] #11617: DYLD_LIBRARY_PATH ignored on Mac OS X 10.11.x In-Reply-To: <047.d00a5696b889c6d842cf8ac7cce9d67a@haskell.org> References: <047.d00a5696b889c6d842cf8ac7cce9d67a@haskell.org> Message-ID: <062.b62a7ed2662df3fd5f63a4c26c787a47@haskell.org> #11617: DYLD_LIBRARY_PATH ignored on Mac OS X 10.11.x ---------------------------------+-------------------------------------- Reporter: borsboom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by gershomb): Having done a little investigating, it seems to me that the real answer is "you shouldn't need to set DYLD_LIBRARY_PATH" . Indeed I don't think there are any ''normal'' workflows on OS X that should require this. The issue would only arise when linking to an external lib that inserts a path on DYLD_LIBRARY_PATH, and such libs are now effectively basically broken throughout the OS X ecosystem. Here are a few articles that recommend against setting it (ever) as taken from a thread discussing this issue on Oracle bindings for node: * https://blogs.oracle.com/ali/entry/avoiding_ld_library_path_the * http://linuxmafia.com/faq/Admin/ld-lib-path.html We may want to add a FAQ page for manual workarounds, but my gut says "don't fix, and recommend to those who encounter this that they should reconsider why they need DYLD_LIBRARY_PATH to begin with". That said, I'm not one of the people "feeling the pain" here, so opinions may vary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 06:59:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 06:59:30 -0000 Subject: [GHC] #5850: Greater customization of GHCi prompt In-Reply-To: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> References: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> Message-ID: <065.fe516fc84dd500857431cd9892e22c1b@haskell.org> #5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9994 | Differential Rev(s): Phab:D623 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niksaz): * owner: niksaz => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 08:45:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 08:45:33 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing (was: Demand analysis: Thunk wrongly determined single-entry) In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.4a28900b22c2684bcae313ea6931bdc5@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 09:12:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 09:12:37 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.6598ca3ef43b0e80b3e950cf546adeaf@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good point! For example, if the demand analyser saw {{{ let y = factorial v in let x = y in x + x }}} I think it'd conclude that `x` was demanded many times, but `y` was demanded only once. (Which is correct). But if we substitute for `x`, and then use call-by-name for `y` we'll evaluate the `factorial` twice. Urk. It seems to affect bindings like {{{ x = y -- Or perhaps y |> gamma etc; exprIsTrivial anyway }}} where * The demand signature on `x` is '''not''' marked "used-once" * The demand signature on `y` '''is''' marked "used-once" Under these circumstances, the binding for `x` is serving a useful role, to memo-ise the computation of `y`. Perhaps we should simply refrain from inlining `x` under these circumstances, leaving the trivial let in place. The fix would be in `postInlineUnonditionally`, `postInlineUnonditionally`, and `callSiteInline`. Would you like to try that? I think it'd fix this bug. But it would then be important to know how many trivial lets were thereby retained. Perhaps not many. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 09:15:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 09:15:39 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.aaf7d21f844a486cbf54a1369bd4cd65@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * Attachment "T11731.hs" added. Test case -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 09:19:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 09:19:59 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.37b4a69cd6f8025da6cd4e2947b4e53c@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I?ve created a test case for this; if you run `T11731`, it will print `Evaluated` twice. > Would you like to try that? I think it'd fix this bug. I?m not sure I like that path. This means that the strictness signatures will now not only ''describe'' the actual semantics of the code, but rather ''affect'' it. We would lose the invariant that the semantics of the program does not change if we remove all strictness signatures. Feels wrong to me. But nevertheless, I see if that indeed fixes the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 09:33:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 09:33:14 -0000 Subject: [GHC] #11737: Make validate --testsuite-only behave correctly w.r.t. bindisttest In-Reply-To: <047.2e7bc1a52ac540caae205e25ca4d0fee@haskell.org> References: <047.2e7bc1a52ac540caae205e25ca4d0fee@haskell.org> Message-ID: <062.5b0feb06b7b99bb21281c179f38a3e6d@haskell.org> #11737: Make validate --testsuite-only behave correctly w.r.t. bindisttest -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): I think it would be confusing if `./validate --testsuite-only` didn't run the tests in the same way as `./validate`. Maybe one of the following solutions can serve you already? Instead of `./validate --testsuite-only`, run: * `make test THREADS=`. It doesn't use the binary distribution. or * `./validate --no-clean`. It will call `make`, which should be a no-op, then recreate the binary distribution, and then call `make test BINDIST=YES` for you. or * `./validate --testuite-only --fast`. Drawback is that it doesn't run all tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 10:35:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 10:35:36 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.aab48c622a2e3ced09a9b8b0e9733bf3@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Hmm. Not so easy. Given that problematic code, i.e. {{{ $s$wwwMe_s49K :: Int -> Int -> GHC.Prim.Int# -> (# Int, Int #) [LclId, Arity=3, Str=DmdType ] $s$wwwMe_s49K = \ (sc_s49I :: Int) (sc_s49J :: Int) (sc_s49H :: GHC.Prim.Int#) -> case sc_s49H of ds_X1WV { __DEFAULT -> $wwwMe_s48A (GHC.Prim.-# ds_X1WV 1#) lvl_s1Z6; 0# -> case foo @ Int @ Int (sc_s49I, sc_s49J) of _ [Occ=Dead] { GHC.Types.I# ipv_s1XV [Dmd=] -> let { b_s1Z1 [Dmd=] :: Int [LclId, Str=DmdType] b_s1Z1 = sc_s49J } in let { a_s1Z0 [Dmd=] :: Int [LclId, Str=DmdType] a_s1Z0 = sc_s49I } in (# GHC.Num.$fNumInt_$c+ b_s1Z1 a_s1Z0, GHC.Num.$fNumInt_$c+ a_s1Z0 b_s1Z1 #) } } }}} it seems that the `used-once` information is not attached to the occurrence of `sc_s49J`, but only to the function `$s$wwwMe_s49J` that binds it. This is confirmed by a `pprTrace` of the `idDemandInfo` in `exprIsTrivial`: {{{ exprIsTrivial sc_s49J }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 11:53:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 11:53:18 -0000 Subject: [GHC] #11737: Make validate --testsuite-only behave correctly w.r.t. bindisttest In-Reply-To: <047.2e7bc1a52ac540caae205e25ca4d0fee@haskell.org> References: <047.2e7bc1a52ac540caae205e25ca4d0fee@haskell.org> Message-ID: <062.d548a5d389f72d0a6edcdda3d4831208@haskell.org> #11737: Make validate --testsuite-only behave correctly w.r.t. bindisttest -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:1 thomie]: > I think it would be confusing if `./validate --testsuite-only` didn't run the tests in the same way as `./validate`. Point well-taken. > > Maybe one of the following solutions can serve you already? Instead of `./validate --testsuite-only`, run: > * `make test THREADS=`. It doesn't use the binary distribution. I thought of this but wasn't sure it would run the same set of tests in the same way. > or > * `./validate --no-clean`. It will call `make`, which should be a no- op, then recreate the binary distribution, and then call `make test BINDIST=YES` for you. This wouldn't have been a no-op, because I edited the GHC source code. So it would have rebuilt everything from stage1 on. Perhaps the answer I'm looking for is `validate --no-clean --lax-dependencies` or `validate --no- clean --stage-2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 12:05:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 12:05:51 -0000 Subject: [GHC] #11737: Make validate --testsuite-only behave correctly w.r.t. bindisttest In-Reply-To: <047.2e7bc1a52ac540caae205e25ca4d0fee@haskell.org> References: <047.2e7bc1a52ac540caae205e25ca4d0fee@haskell.org> Message-ID: <062.b799fd21269a56136168f3ca7645f80b@haskell.org> #11737: Make validate --testsuite-only behave correctly w.r.t. bindisttest -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): > wasn't sure it would run the same set of tests in the same way It should. If you want to know more, it's probably best to look at validate script itself. The line that calls the tests is: {{{ $make $MAKE_TEST_TARGET stage=2 $BINDIST $TEST_VERBOSITY THREADS=$threads 2>&1 | tee testlog }}} > `validate --no-clean --lax-dependencies` or `validate --no-clean --stage-2`. You can create a file `mk/validate.mk` containing `stage=2` and `LAX_DEPENDENCIES = YES`. When running `./validate` (or when running `make` with a leftover `mk/are- validating.mk` file), the build system reads settings from `mk/validate.mk` instead of `mk/build.mk`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 12:21:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 12:21:54 -0000 Subject: [GHC] #9526: Add missing Generic instances in base In-Reply-To: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> References: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> Message-ID: <057.8b09a04235d76bc6d28bd3508e168f1b@haskell.org> #9526: Add missing Generic instances in base -------------------------------------+------------------------------------- Reporter: nh2 | Owner: dreixel Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: wontfix | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I can't tell - I don't really understand the change; link in the ticket description of #9766 seems broken. Can you explain a bit what this change does, and how it affects this issue? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 12:57:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 12:57:56 -0000 Subject: [GHC] #9526: Add missing Generic instances in base In-Reply-To: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> References: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> Message-ID: <057.e742c21e4f01f87addb287542e8342f0@haskell.org> #9526: Add missing Generic instances in base -------------------------------------+------------------------------------- Reporter: nh2 | Owner: dreixel Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: wontfix | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10512 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #10512 Comment: Sorry, my bad. I linked the wrong issue. It should be #10512, where `Generic` instances were proposed for `Int32` and `Word64`. The resolution of that issue is wontfix, and in GHC 8.0, the `Generic` instances for `Char`, `Float`, `Double`, and `Int` [https://ghc.haskell.org/trac/ghc/ticket/10512#comment:7 will be removed]. Pedro outlines the reasons for not including `Generic` instances for primitive types [https://ghc.haskell.org/trac/ghc/ticket/10512#comment:3 here]. Basically, `Generic` instances are intended for inspecting the structure of regular, structured algebraic data types until you get down to the "leaves" of a data structure. The leaves only require //ad hoc// instances of the base class, not of `Generic`. Moreover, the previous `Generic` instances base types were lying to users. Previously, we had something like this: {{{#!hs type Rep Char = D1 D_Char (C1 C_Char (S1 NoSelector (Rec0 Char)) }}} But according to the rules of how `Generic` operates, that would suggest that `data Char = Char Char`, which is absolutely not the case. To avoid this dishonesty, we decided to remove the offending instances altogether. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 13:12:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 13:12:01 -0000 Subject: [GHC] #11737: Make validate --testsuite-only behave correctly w.r.t. bindisttest In-Reply-To: <047.2e7bc1a52ac540caae205e25ca4d0fee@haskell.org> References: <047.2e7bc1a52ac540caae205e25ca4d0fee@haskell.org> Message-ID: <062.03ad8faef21b330cecf8439a6e7a24f4@haskell.org> #11737: Make validate --testsuite-only behave correctly w.r.t. bindisttest -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: Ah right. OK. I guess this is a case of a misguided/uninformed user. Thanks for fixing the bug. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 13:15:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 13:15:41 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.0d37a0a4ae5dc8dbff31c69bb97e1f97@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Humph. I was thinking that if a function has a particular strictness signature we can't change it. Certainly we can't change the strictness signature for an imported function. BUT we CAN change the strictness signatures of local functions and actually those are the ones that matter, because their sharing properties may worsen, as above. Indeed we already have the idea of running the demand analyser just before code generation: `-flate-dmd-anal`. (Main motivation: discover used-once thunks that weren't previously used-once.) Does using `-flate-dmd-anal` fix the problem? It may not becuase there is a simplifer run afterwards; but cleraly this bug only shows up rarely anyway, so running it late might actually fix it Thinking about it * ''Until'' code generation, the used-once info is ignored; only one- shot-call info is used * ''During'' code generation, the used-once info is used; and the one- shot-call info is ignored. So perhaps * We should not even ''generate'' used-once info in the main run of the demand analyser, since it is so easily invalidated. * In the run of the simplifier after late demand analysis we should be careful not to eliminate the dangerous lets. I tried the test program with `-O`; but it only prints `"Evaluated"` once. So, strangely, I can't reproduce the bug. What exact commands did you use? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 13:16:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 13:16:37 -0000 Subject: [GHC] #9526: Add missing Generic instances in base In-Reply-To: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> References: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> Message-ID: <057.ca666756976b7b3fce83ad7a0de5f247@haskell.org> #9526: Add missing Generic instances in base -------------------------------------+------------------------------------- Reporter: nh2 | Owner: dreixel Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: wontfix | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10512 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I think you linked the right issue; I got to #9766 via the git commit you mentioned in #10512. What you say makes sense, and it does look like a better solution. I don't know if it addresses all issues that motivated this issue, but your comment at https://ghc.haskell.org/trac/ghc/ticket/10512#comment:7 suggests that it does. I'll try that out when GHC 8 is released with this change, and reopen if there's any remaining problem. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 13:17:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 13:17:03 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.67e24cc33408471c336cceefe2428c32@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > it seems that the used-once information is not attached to the occurrence of `sc_s49J` Ha, well, that's not very cool. I bet it is easily fixed. Just need to annotate the binders of the worker, perhaps. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 13:17:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 13:17:47 -0000 Subject: [GHC] #10512: Generic instances missing for Int32, Word64 etc. In-Reply-To: <051.eb2fd15ce978c34ac9303293c51292d1@haskell.org> References: <051.eb2fd15ce978c34ac9303293c51292d1@haskell.org> Message-ID: <066.a70c81667bbf4b8a739b5f7881bfaf80@haskell.org> #10512: Generic instances missing for Int32, Word64 etc. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: wontfix | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Note: In https://ghc.haskell.org/trac/ghc/ticket/9526#comment:13 RyanGlScott provided an explanation of why this change is no longer necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 13:18:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 13:18:46 -0000 Subject: [GHC] #10512: Generic instances missing for Int32, Word64 etc. In-Reply-To: <051.eb2fd15ce978c34ac9303293c51292d1@haskell.org> References: <051.eb2fd15ce978c34ac9303293c51292d1@haskell.org> Message-ID: <066.ef46dc9cc16955bf46cb08242307614a@haskell.org> #10512: Generic instances missing for Int32, Word64 etc. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: wontfix | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9526 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #9526 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 13:42:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 13:42:39 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.893ffebad602c1d935ccd8bbe1bf73c2@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > I tried the test program with -O; but it only prints "Evaluated" once. So, strangely, I can't reproduce the bug. What exact commands did you use? Well spotted! I ran with `-O2`, and indeed, it does not happen with `-O`, but with `-O -fspec-constr`. Nothing deep here, it?s just that constructor specialization is required in this particular example to massage the code into the shape we want. > Does using -flate-dmd-anal fix the problem? Indeed it does. It recalculates the demand signature correctly, and will share the `shareMeThunk`. But after `-flate-dmd-anal`, there is another round of worker-wrapper and simplifier. So the principle, the problem could occur again. I would prefer to take a step back and think about what, at the level of Core, the semantics of {{{ let x = y in foo x }}} should be, independent of any possible annotations. Here a digression that follows that train of thought: If this code should indeed guarantee that `y` is evaluated at most once, then rewriting to `foo y` is in general wrong (and may only be justified if we ''know'' that `foo` evaluates its argument only once ? this is more conservative than not doing the substitution if we happen to know that it can go wrong). Alternatively, we declare the semantics that a `let` with a trivial RHS should ''not'' (guarantee) sharin (just like a trivial function argument does not indicate sharing!). But then the problem was one step earlier where GHC replaced {{{ let x = case (y,z) of (y,z) -> y in foo x }}} with the trivial let above. Maybe it should have changed it to something like {{{ let x = share y in foo x }}} where `share` is a magic id that is semantically the identity, but prevents the `let` from being trivial. Now `x` can even be safely inlined then `foo (share y)`. The simplifier could know some rules about when occurrences of `share` can be removed (e.g. when the argument is not trivial any more, or when it is itself known to be shared). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 14:41:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 14:41:14 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.eaf7fec000ec67679c85832306789fc1@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Ha, well, that's not very cool. I bet it is easily fixed. Just need to annotate the binders of the worker, perhaps. I found that the worker/wrapper code of the demand analyizer already does this annotation. In this instance, it?s a constructor specialization which does not preserve the annotations. I?ll have a look.... it?s easy to do, the new functions strictness signature is already calculated, so I simply pull the demand on the individual arguments out of that: (changeset:8649ac61698c8600f5db64ff7947828bb4715a5d for now, but this is a temporary branch). But still, it shows that it is tricky to try to preserve the analysis results through the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 14:44:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 14:44:37 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.b8c81f62caa983ed6d15deeb9950c1e1@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well, it all amounts to the same thing: * Introduce `share` * Use `let` to create sharing The rules for eliminating `share` would be the same as the rules governing inlining of trivial lets. Which is preferable is largely an engineering choice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 14:59:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 14:59:53 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.df98b7add7417b3a10c8097ec42262ea@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): So you suggest that the desired semantics is that a trivial `let` should guarantee sharing, right? In this case, transforming `let x = y in foo x` to `foo y` is not a valid transformation any more. Unless we can guarantee that `foo y` evaluates `y` only once ''or'' unless we can guarantee that `y` is shared anyways. Assuming we do not want to drag strictness annotations into the semantics, we cannot do that! (But maybe dragging them in is fine?) The rule ?a trivial `let` does not guarantee sharing? allows the the above transformation unconditionally, but shifts the onus to the earlier simplification of the RHS. Is that less hairy there? Not sure... Or maybe, as a third option, we should flag a variable with a bit of information that indicates whether it is shared (and safe to evaluate multiple times). How is that different from the demand annotation? The demand annotation says something about how it ''is'' used, while this flag contains information about how the variable is going to be created (with or without an update frame) and then guides how it ''can'' be used. I don?t see all the consequences, of course, but such a variable would in many cases behave more like a possibly costly expression, i.e. should not be duped, not be floated into a let etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 16:46:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 16:46:42 -0000 Subject: [GHC] #11742: 'Strict' extension is incompatible with 'deriving' mechanism Message-ID: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> #11742: 'Strict' extension is incompatible with 'deriving' mechanism -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This: {{{#!hs {-# LANGUAGE Strict #-} module Foo where data Foo = Foo deriving Eq }}} panics with {{{ ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.1.20160317 for x86_64-unknown-mingw32): makeCorePair: dfun $dEq_a1zL }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 18:23:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 18:23:24 -0000 Subject: [GHC] #11742: 'Strict' extension is incompatible with 'deriving' mechanism In-Reply-To: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> References: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> Message-ID: <059.882ac9ce8e47f93e13e43a4ed3935fb0@haskell.org> #11742: 'Strict' extension is incompatible with 'deriving' mechanism -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: simonpj (added) Comment: This is caused by {{{ tree b0db86fc5c3805eef1e66345bae410375a2a3dd2 parent e3f341f334d89c88f388d8e864ed8762d0890a64 author Simon Peyton Jones Thu Feb 25 15:53:59 2016 +0000 committer Simon Peyton Jones Fri Feb 26 17:14:59 2016 +0000 Special case for desugaring AbsBinds When AbsBinds has no tyvars and no dicts, a rather simpler desugaring is possible. This patch implements it. I don't think the optimised code changes, but there is less clutter generated. }}} I don't quite understand desugaring so can't fix it myself at the moment. cc @simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 18:24:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 18:24:02 -0000 Subject: [GHC] #11740: RFC kind synonyms In-Reply-To: <051.0e72c4f1c3d54cad33a28cc5a9b7fcc3@haskell.org> References: <051.0e72c4f1c3d54cad33a28cc5a9b7fcc3@haskell.org> Message-ID: <066.75e1660f57013411e66ab3fcd4b75e0f@haskell.org> #11740: RFC kind synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Agreed. I found it interesting that the most worthwhile synonym was `Cat` and should note that `TypeClass` could be more general: {{{#!hs type TTypeClass k = k -> Constraint And :: TTypeClass k -> TTypeClass k -> TTypeClass k Typeable :: TTypeClass k }}} And what about multi-parameter type classes like `(~) :: k -> k -> Constraint`? Let's see what happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 22:27:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 22:27:49 -0000 Subject: [GHC] #10162: Add unicode syntax for banana brackets In-Reply-To: <045.f7ad53896487f5f5496f96174e92dff7@haskell.org> References: <045.f7ad53896487f5f5496f96174e92dff7@haskell.org> Message-ID: <060.f8c1be5800852c7e9b0a1ceb036ef06a@haskell.org> #10162: Add unicode syntax for banana brackets -------------------------------------+------------------------------------- Reporter: zardoz | Owner: JoshPrice247 Type: feature request | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.8.4 (Parser) | Keywords: unicode, Resolution: | UnicodeSyntax, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2012 Wiki Page: | -------------------------------------+------------------------------------- Changes (by JoshPrice247): * differential: => Phab:D2012 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 22:30:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 22:30:52 -0000 Subject: [GHC] #5850: Greater customization of GHCi prompt In-Reply-To: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> References: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> Message-ID: <065.f9b7cb4c1a15434d01f4a7630de971ae@haskell.org> #5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: niksaz Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9994 | Differential Rev(s): Phab:D623 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niksaz): * owner: => niksaz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 23:10:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 23:10:16 -0000 Subject: [GHC] #11743: Add unicode support for special brackets (`{| |}` and `[| |]`) Message-ID: <051.4e3f659fb72a6cab53dcc41b17807208@haskell.org> #11743: Add unicode support for special brackets (`{| |}` and `[| |]`) -------------------------------------+------------------------------------- Reporter: JoshPrice247 | Owner: JoshPrice247 Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Keywords: unicode, | Operating System: Unknown/Multiple UnicodeSyntax | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 2878, 10162 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This has been mentioned before but didn't have it's own ticket. The following where mentioned in #2978, but the respective patch did not include them: * For TemplateHaskell: `? ?` (MATHEMATICAL _ WHITE SQUARE BRACKET) can be used instead of `[| |]` * For Generics: `? ?` (_ WHITE CURLY BRACKET) can be used instead of `{| |}` * For Arrows: `? ?` (Z NOTATION _ IMAGE BRACKET) can be used instead of `(| |)` Banana brackets were then suggested in #10162 and implemented in Phab:D2012 (which has been accepted, but has not yet landed). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 23:37:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 23:37:02 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.9d0b26db64d89c170955298cf5206166@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 22 23:37:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Mar 2016 23:37:51 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.b4b8c635e8f59532a3de2d24ba42be90@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 00:10:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 00:10:36 -0000 Subject: [GHC] #11742: 'Strict' extension is incompatible with 'deriving' mechanism In-Reply-To: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> References: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> Message-ID: <059.8ae575e8602dfb25f44ad585fe241d4b@haskell.org> #11742: 'Strict' extension is incompatible with 'deriving' mechanism -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest * milestone: => 8.2.1 Comment: This should be dealt with although it doesn't affect 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 01:33:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 01:33:03 -0000 Subject: [GHC] #11743: Add unicode support for TH quotes (`[| |]`) (was: Add unicode support for special brackets (`{| |}` and `[| |]`)) In-Reply-To: <051.4e3f659fb72a6cab53dcc41b17807208@haskell.org> References: <051.4e3f659fb72a6cab53dcc41b17807208@haskell.org> Message-ID: <066.6f882994c6bbf65c859549e072276e04@haskell.org> #11743: Add unicode support for TH quotes (`[| |]`) -------------------------------------+------------------------------------- Reporter: JoshPrice247 | Owner: JoshPrice247 Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Keywords: unicode, Resolution: | UnicodeSyntax Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 2878, 10162 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by JoshPrice247: @@ -13,2 +13,3 @@ - Banana brackets were then suggested in #10162 and implemented in - Phab:D2012 (which has been accepted, but has not yet landed). + Generic classes have since been removed and banana brackets were suggested + in #10162 and implemented in Phab:D2012 (which has been accepted, but has + not yet landed), leaving TH quotes. New description: This has been mentioned before but didn't have it's own ticket. The following where mentioned in #2978, but the respective patch did not include them: * For TemplateHaskell: `? ?` (MATHEMATICAL _ WHITE SQUARE BRACKET) can be used instead of `[| |]` * For Generics: `? ?` (_ WHITE CURLY BRACKET) can be used instead of `{| |}` * For Arrows: `? ?` (Z NOTATION _ IMAGE BRACKET) can be used instead of `(| |)` Generic classes have since been removed and banana brackets were suggested in #10162 and implemented in Phab:D2012 (which has been accepted, but has not yet landed), leaving TH quotes. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 01:45:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 01:45:20 -0000 Subject: [GHC] #11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics In-Reply-To: <051.d88b9387a728df13c9639e42ea307515@haskell.org> References: <051.d88b9387a728df13c9639e42ea307515@haskell.org> Message-ID: <066.6ac278f02234ac904e3d0b15b6c63bb4@haskell.org> #11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Segmentation | Fault, Generics, Runtime error Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: attached Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Interestingly, I can reproduce this on Linux x86_64 with GHC 7.10.3, but not with GHC 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 01:57:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 01:57:09 -0000 Subject: [GHC] #11743: Add unicode support for TH quotes (`[| |]`) In-Reply-To: <051.4e3f659fb72a6cab53dcc41b17807208@haskell.org> References: <051.4e3f659fb72a6cab53dcc41b17807208@haskell.org> Message-ID: <066.04ae7d420e17e21ca35e7028a745a0cb@haskell.org> #11743: Add unicode support for TH quotes (`[| |]`) -------------------------------------+------------------------------------- Reporter: JoshPrice247 | Owner: JoshPrice247 Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Keywords: unicode, Resolution: | UnicodeSyntax Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 2878, 10162 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JoshPrice247): I would like suggestions on how to proceed with this. I have it implemented, but it depends on changes made in Phab:D2012. Do I need to wait until D2012 lands and then create a new differential? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 04:18:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 04:18:51 -0000 Subject: [GHC] #11728: Core lint errors In-Reply-To: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> References: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> Message-ID: <066.3460a5b9c1e6f2b1ae8ea89c889c29e4@haskell.org> #11728: Core lint errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "Error.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 04:19:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 04:19:31 -0000 Subject: [GHC] #11728: Core lint errors In-Reply-To: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> References: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> Message-ID: <066.311d6bc53a54cb52f7502eeaf3a16657@haskell.org> #11728: Core lint errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I think `Error.hs` has the same problem, uses `UndecidableSuperclasses`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 08:31:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 08:31:37 -0000 Subject: [GHC] #11742: 'Strict' extension is incompatible with 'deriving' mechanism In-Reply-To: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> References: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> Message-ID: <059.c4829512f5ac635430038d3fdb467dce@haskell.org> #11742: 'Strict' extension is incompatible with 'deriving' mechanism -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Works ok in HEAD, so far as I can tell. So maybe already fixed? In which case a test case could be good. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 08:53:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 08:53:42 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` Message-ID: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ----------------------------------------+--------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- TLDR: Apple messed up again and broke POSIX compliance luite ran into problems when he installed the latest Xcode update because the derived platform constants were off. He provided me the output of `nm -P ./includes/dist- derivedconstants/header/tmp.o` which turned out have numbers which didn't make sense: {{{ _derivedConstantAP_STACK_SPLIM C 1025 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C 253 0 _derivedConstantBLOCK_SIZE C 4097 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ... }}} Which with an older Xcode version would have looked like {{{ _derivedConstantAP_STACK_SPLIM C 401 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C fd 0 _derivedConstantBLOCK_SIZE C 1001 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ... }}} So obviously `nm -P`'s output changed from hexadecimal to (non-compliant) decimal formatting of numbers. For reference, here's how POSIX specifies the semantics of `nm`: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html > `-P` > Write information in a portable output format, as specified in the STDOUT section. ... > If the `-P` option is specified, the previous information shall be displayed using the following portable format. The three versions differ depending on whether `-t d`, `-t o`, or `-t x` was specified, respectively: > > {{{"%s%s %s %d %d\n", , , , , }}} > > {{{"%s%s %s %o %o\n", , , , , }}} > > {{{"%s%s %s %x %x\n", , , , , }}} In the event that Apple can't be bothered to fix this bug (I've had bad experience with Apple and standard-compliance in the past, hence my pessimism) we could try to workaround by using `nm -P -t x` when building on OSX... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 08:57:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 08:57:01 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.c1c218604787912fa0ee13952ed93ed0@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Description changed by hvr: @@ -8,2 +8,2 @@ - derivedconstants/header/tmp.o` which turned out have numbers which didn't - make sense: + derivedconstants/header/tmp.o` which turned out to have numbers which + didn't make sense: @@ -46,0 +46,2 @@ + ---- + @@ -66,0 +68,7 @@ + ... + + > '''If `-P` is specified, but `-t` is not, the format shall be as if `-t + x` had been specified.''' + + ---- + New description: TLDR: Apple messed up again and broke POSIX compliance luite ran into problems when he installed the latest Xcode update because the derived platform constants were off. He provided me the output of `nm -P ./includes/dist- derivedconstants/header/tmp.o` which turned out to have numbers which didn't make sense: {{{ _derivedConstantAP_STACK_SPLIM C 1025 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C 253 0 _derivedConstantBLOCK_SIZE C 4097 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ... }}} Which with an older Xcode version would have looked like {{{ _derivedConstantAP_STACK_SPLIM C 401 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C fd 0 _derivedConstantBLOCK_SIZE C 1001 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ... }}} So obviously `nm -P`'s output changed from hexadecimal to (non-compliant) decimal formatting of numbers. For reference, here's how POSIX specifies the semantics of `nm`: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html ---- > `-P` > Write information in a portable output format, as specified in the STDOUT section. ... > If the `-P` option is specified, the previous information shall be displayed using the following portable format. The three versions differ depending on whether `-t d`, `-t o`, or `-t x` was specified, respectively: > > {{{"%s%s %s %d %d\n", , , , , }}} > > {{{"%s%s %s %o %o\n", , , , , }}} > > {{{"%s%s %s %x %x\n", , , , , }}} ... > '''If `-P` is specified, but `-t` is not, the format shall be as if `-t x` had been specified.''' ---- In the event that Apple can't be bothered to fix this bug (I've had bad experience with Apple and standard-compliance in the past, hence my pessimism) we could try to workaround by using `nm -P -t x` when building on OSX... -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 08:58:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 08:58:24 -0000 Subject: [GHC] #7198: New codegen more than doubles compile time of T3294 In-Reply-To: <047.96b5f0effd7d95ff044f855e6d48f3db@haskell.org> References: <047.96b5f0effd7d95ff044f855e6d48f3db@haskell.org> Message-ID: <062.915c74a9a10e26134dbdb67e2bdebd8a@haskell.org> #7198: New codegen more than doubles compile time of T3294 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The basic problem here is that * The Stg->Cmm code generator generates suboptimal code * The `CmmSink` pass would mostly optimise it away, but it is only run at -O. * The extra code is hurting compile time * The old code generator generated simpler code, and thus was faster It's not obvious what the solution is. We might need several improvements in various places. it's not clear whether the lets should be flattened; if so, this is the job of earlier phases (simplifier or CorePrep). Flattening lets is a tradeoff, and I suspect the simplifier is already doing a reasonable job here, and has just decided not to in this case. In some cases I made the STG->Cmm code generator a bit more clever, so as to generate less code and improve compile time, even though later optimisation phases would have produced the same result. I like this approach because it improves compile times for -O0, relying on later optimisation is brittle, and a few tweaks can have a big effect due to the regular patterns that occur in Cmm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 09:02:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 09:02:01 -0000 Subject: [GHC] #7198: New codegen more than doubles compile time of T3294 In-Reply-To: <047.96b5f0effd7d95ff044f855e6d48f3db@haskell.org> References: <047.96b5f0effd7d95ff044f855e6d48f3db@haskell.org> Message-ID: <062.95a19726096912f49d89709164650a5a@haskell.org> #7198: New codegen more than doubles compile time of T3294 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, if improving STG->Cmm can be done without major contortions -- and the additional complexity is documented -- that sounds perfect -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 09:58:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 09:58:02 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.218be6f76c06090945e5aed622cef71b@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by luite): thanks for creating the ticket. Unfortunately the new nm doesn't support the `-t x` option: {{{ luite at Luites-MacBook-Pro:~/haskell/build/ghc-8.0.0.20160322/includes/dist- derivedconstants/header$ nm -P -t x tmp.o nm: Unknown command line argument '-t'. Try: '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm -help' nm: Did you mean '-A'? luite at Luites-MacBook-Pro:~/haskell/build/ghc-8.0.0.20160322/includes/dist- derivedconstants/header$ nm -P -tx tmp.o nm: Unknown command line argument '-tx'. Try: '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm -help' nm: Did you mean '-x'? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 10:35:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 10:35:32 -0000 Subject: [GHC] #11742: 'Strict' extension is incompatible with 'deriving' mechanism In-Reply-To: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> References: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> Message-ID: <059.023a12b8c2727c269616d283a10a740b@haskell.org> #11742: 'Strict' extension is incompatible with 'deriving' mechanism -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): I tried it on quite recent ghc-8.1.20160317. Another thing I've forgotten to mention is that the bug needs `-O` to manifest itself. With no optimizations it doesn't happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 11:26:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 11:26:33 -0000 Subject: [GHC] #11684: Fix tests with Clang In-Reply-To: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> References: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> Message-ID: <059.c7396d6a75e673915ca41ffc20bbb7f9@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ?Phab:D1988 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 11:29:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 11:29:06 -0000 Subject: [GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc) In-Reply-To: <045.274c910606d60239cadf6f398a2dd711@haskell.org> References: <045.274c910606d60239cadf6f398a2dd711@haskell.org> Message-ID: <060.f7a1dbd9294ef300d874bb2b784974e7@haskell.org> #11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: jme Type: bug | Status: merge Priority: high | Milestone: Component: Profiling | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | perf/space_leaks/space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2005 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 11:44:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 11:44:56 -0000 Subject: [GHC] #11745: In GHC Download section it is not stated that ARMv7 build is only for 32bit ARM Message-ID: <045.95fbc89e237ba959ef056a0b0ce1db9b@haskell.org> #11745: In GHC Download section it is not stated that ARMv7 build is only for 32bit ARM --------------------------------+-------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Documentation bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+-------------------------------------- [https://www.haskell.org/ghc/download_ghc_7_10_3#linux_armv7] I have tried that on ARM64 and it doesn't "configure" because ghc-pwd is 32bit. This waste some time to figure out. If it is stated in the site, that those are 32bit distributions only - it will safe some effort. {{{ ubuntu at geekbox-arm64:~/ghc-7.10.2$ ./configure checking for path to top of build tree... utils/ghc-pwd/dist- install/build/tmp/ghc-pwd-bindist: line 3: /home/ubuntu/ghc-7.10.2/utils /ghc-pwd/dist-install/build/tmp/ghc-pwd: No such file or directory configure: error: cannot determine current directory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 11:45:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 11:45:38 -0000 Subject: [GHC] #11745: In GHC Download section it is not stated that ARMv7 build is only for 32bit ARM In-Reply-To: <045.95fbc89e237ba959ef056a0b0ce1db9b@haskell.org> References: <045.95fbc89e237ba959ef056a0b0ce1db9b@haskell.org> Message-ID: <060.e42ac5bcfd476562de82f73079414612@haskell.org> #11745: In GHC Download section it is not stated that ARMv7 build is only for 32bit ARM --------------------------------------+------------------------------ Reporter: varosi | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Documentation bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+------------------------------ Comment (by varosi): Both on 7.10.2 and 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 11:55:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 11:55:43 -0000 Subject: [GHC] #11724: Must check for representation polymorphism in datatype declarations In-Reply-To: <047.e984e50f4246346ca88e79b8cc73fa2e@haskell.org> References: <047.e984e50f4246346ca88e79b8cc73fa2e@haskell.org> Message-ID: <062.8f803d90e493167527007594c78c76e0@haskell.org> #11724: Must check for representation polymorphism in datatype declarations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T11724 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * failure: None/Unknown => Compile-time crash * resolution: => fixed Comment: Merged as b3304e06554276593f91a8eedcb2490873cc50bc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 11:55:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 11:55:47 -0000 Subject: [GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc) In-Reply-To: <045.274c910606d60239cadf6f398a2dd711@haskell.org> References: <045.274c910606d60239cadf6f398a2dd711@haskell.org> Message-ID: <060.e8a0b958437b90e2435eb8607f8add43@haskell.org> #11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: jme Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Profiling | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: | perf/space_leaks/space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2005 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * failure: None/Unknown => Runtime crash * resolution: => fixed * milestone: => 8.0.1 @@ -5,1 +5,1 @@ - {{{ + {{{#!hs New description: `WAY=profasm` is omitted by default for this test, but the code looks like this: Test.hs: {{{#!hs import Data.List main = print $ length $ show (foldl' (*) 1 [1..100000] :: Integer) }}} {{{ $ ghc Test.hs -prof -O $ ./Test +RTS -hc Segmentation fault (core dumped) }}} Reproducible with at least 7.10.3 and HEAD, also without `-O`. -- Comment: Merged as d1fbcbb6710db0e06deac66a77f90d74001acd16. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 11:55:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 11:55:49 -0000 Subject: [GHC] #11635: Higher-rank kind in datatype definition rejected In-Reply-To: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> References: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> Message-ID: <060.8fda6b7de080022d9fd890ad603690e1@haskell.org> #11635: Higher-rank kind in datatype definition rejected -------------------------------------+------------------------------------- Reporter: phadej | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11635 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * failure: None/Unknown => GHC rejects valid program * resolution: => fixed * milestone: => 8.0.1 @@ -3,1 +3,1 @@ - {{{ + {{{#!hs New description: Example program: {{{#!hs {-# LANGUAGE TypeInType, KindSignatures, ExplicitForAll #-} import Data.Kind data X (a :: forall k. k -> * ) = X }}} errors with {{{ polykind.hs:3:1: error: Expecting one more argument to ?a? Expected kind ?k0?, but ?a? has kind ?forall k. k -> *? }}} Without `TypeInType`, the error is better, yet gives false hint: {{{ polykind.hs:3:23: error: Illegal kind: forall k. k -> * Did you mean to enable TypeInType? }}} --- For the record 7.10.3 doesn't recognise polymorphic kinds at all (same program, without `Data.Kind` import): {{{ polykind.hs:3:23: parse error on input ?forall? }}} Which makes me think that polymorphic kinds are somehow supported, but maybe not. -- Comment: Merged as bae60f654ac5d99834818da9c50ad4bee54c334e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 11:55:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 11:55:52 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.478bc23360ebed634ebe2c1c518482e2@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * failure: None/Unknown => GHC rejects valid program * resolution: => fixed * milestone: => 8.0.1 @@ -7,1 +7,1 @@ - {{{ + {{{#!hs New description: This ticket came out of a discussion with Richard in this mailing list post: https://mail.haskell.org/pipermail/haskell- cafe/2016-March/123462.html Here's the code that should work, but doesn't: {{{#!hs import Data.Kind data TyFun :: * -> * -> * type a ~> b = TyFun a b -> * type family (f :: a ~> b) @@ (x :: a) :: b data Null a = Nullable a | NotNullable a type family ((f :: b ~> c) ? (g :: a ~> b)) (x :: a) :: c where (f ? g) x = f @@ (g @@ x) type family BaseType (k :: forall a. a ~> Type) (x :: b) :: Type where -- this fails :( -- BaseType k x = (@@) k x }}} -- Comment: Merged as bae60f654ac5d99834818da9c50ad4bee54c334e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 11:55:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 11:55:54 -0000 Subject: [GHC] #11723: TYPE 'UnboxedTupleRep is a lie In-Reply-To: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> References: <047.62968954af8a5ac72c32d3a4ff1647d4@haskell.org> Message-ID: <062.9995f18ba1e6d9e2c772eb70f4e4f502@haskell.org> #11723: TYPE 'UnboxedTupleRep is a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T11723 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * failure: None/Unknown => Compile-time crash * resolution: => fixed Comment: Merged as b3304e06554276593f91a8eedcb2490873cc50bc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 11:56:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 11:56:59 -0000 Subject: [GHC] #11684: Fix tests with Clang In-Reply-To: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> References: <044.7b10aaadf615b368cbc477058e80c3fe@haskell.org> Message-ID: <059.70b6190b0a9f2ed9b283f9164f2b1996@haskell.org> #11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ?Phab:D1988 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.2.1 => 8.0.1 Comment: Merged as 02e10ffc9f26ce4cebcb9c29c45e68682d18727f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 11:58:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 11:58:06 -0000 Subject: [GHC] #11512: An unwritten kind variable is "specified", when it shouldn't be. In-Reply-To: <047.7a36187500c6876edf467692a28ef5b3@haskell.org> References: <047.7a36187500c6876edf467692a28ef5b3@haskell.org> Message-ID: <062.5ef0513d889eeaa36ba58dab29c50643@haskell.org> #11512: An unwritten kind variable is "specified", when it shouldn't be. -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11512 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 01f771740f015149cf8e726c8da8a197bf99cb47. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 11:59:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 11:59:53 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.94d02066a966588e2ff2cb86cc0d7d8d@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2007, Wiki Page: | Phab:D2023 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => new * differential: Phab:D2007 => Phab:D2007, Phab:D2023 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 12:00:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 12:00:01 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.f9e1f780c9653bd1db50813c52c1f920@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2007, Wiki Page: | Phab:D2023 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 12:00:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 12:00:56 -0000 Subject: [GHC] #11712: Very confusing error message with -fprint-explicit-kinds In-Reply-To: <046.05390a91e58122ea87d7f537d0159d7b@haskell.org> References: <046.05390a91e58122ea87d7f537d0159d7b@haskell.org> Message-ID: <061.f1d8c6c4f2e282d70878de43e9bf1e91@haskell.org> #11712: Very confusing error message with -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 37dc43f152941595f882b0a5009088303102ea6b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 12:26:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 12:26:31 -0000 Subject: [GHC] #11742: 'Strict' extension is incompatible with 'deriving' mechanism In-Reply-To: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> References: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> Message-ID: <059.e6bdab35635ab3e3a2a2a05374e159ac@haskell.org> #11742: 'Strict' extension is incompatible with 'deriving' mechanism -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Rechecked with freshly built ghc-8.1.20160322. The bug remains in place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 12:37:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 12:37:13 -0000 Subject: [GHC] #10162: Add unicode syntax for banana brackets In-Reply-To: <045.f7ad53896487f5f5496f96174e92dff7@haskell.org> References: <045.f7ad53896487f5f5496f96174e92dff7@haskell.org> Message-ID: <060.01c5fb13ada86a7eafc9b48e811057c4@haskell.org> #10162: Add unicode syntax for banana brackets -------------------------------------+------------------------------------- Reporter: zardoz | Owner: JoshPrice247 Type: feature request | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.8.4 (Parser) | Keywords: unicode, Resolution: | UnicodeSyntax, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2012 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Are there any plans of supporting idiom brackets? `? Just 1 + Just 2 ?` could be used and Arrows are not used much at all -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 13:19:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 13:19:11 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.d3385b88c8002a54abeaa50e2833a982@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: It's unlikely that anything will happen on this front for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 13:29:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 13:29:33 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> Message-ID: <059.8b957b9945e32d6024afdbc6133ac20b@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I agree that being able to capture a `StaticPtr` as plain old data that can be easily serialized, like `StaticKey`, is very useful and a more natural approach than baking this logic into the compiler/standard libraries. It would be nice if the motivation and current implementation were clearly laid out in the [[wiki:StaticPointers|Wiki page]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 13:31:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 13:31:34 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> Message-ID: <059.fb98e90fa519b91ed05809898ec7c640@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: In light of comment:9, it seems like purifying `unsafeLookupStaticPtr` is something worth doing but won't happen for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 13:33:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 13:33:32 -0000 Subject: [GHC] #11716: Make TypeInType stress test work In-Reply-To: <047.dab3e539603ee118886dc0a739516c12@haskell.org> References: <047.dab3e539603ee118886dc0a739516c12@haskell.org> Message-ID: <062.4b480d744c3ccf10489a9ba29d7a2fe0@haskell.org> #11716: Make TypeInType stress test work -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/RaeJobTalk Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 14:26:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 14:26:00 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic In-Reply-To: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> References: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> Message-ID: <066.4ed7aea2ab018a6753c13e016440d6a5@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | TypeApplications GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T11456 Blocked By: | Blocking: Related Tickets: #11329 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "Error2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 14:29:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 14:29:47 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic In-Reply-To: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> References: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> Message-ID: <066.4ed7aea2ab018a6753c13e016440d6a5@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | TypeApplications GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T11456 Blocked By: | Blocking: Related Tickets: #11329 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "Error2.hs" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 14:29:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 14:29:47 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic In-Reply-To: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> References: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> Message-ID: <066.69f4425b479042dc5448eaf9c29b6f32@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | TypeApplications GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T11456 Blocked By: | Blocking: Related Tickets: #11329 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "Error2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 14:32:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 14:32:22 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic In-Reply-To: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> References: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> Message-ID: <066.d2093ad1d9a29eda7758b15b7b6d3add@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | TypeApplications GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T11456 Blocked By: | Blocking: Related Tickets: #11329 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Error2.hs fails, seems like same problem and can be added to the test suite: {{{ $ ghci -ignore-dot-ghci GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help Prelude> :set +c Prelude> :load /tmp/Error2.hs [1 of 1] Compiling Main ( /tmp/Error2.hs, interpreted ) Ok, modules loaded: Main. Collecting type info for 1 module(s) ... Error while getting type info from Main: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160117 for x86_64-unknown-linux): dsExpr:HsTypeOut Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 14:45:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 14:45:34 -0000 Subject: [GHC] #11746: I encountered an: internal error: evacuate: strange closure type 803645000 Message-ID: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> #11746: I encountered an: internal error: evacuate: strange closure type 803645000 --------------------------------------+------------------------------- Reporter: hkBst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- I encountered an: internal error: evacuate: strange closure type 803645000 after loading and running the attached code under GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 14:47:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 14:47:24 -0000 Subject: [GHC] #11746: I encountered an: internal error: evacuate: strange closure type 803645000 In-Reply-To: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> References: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> Message-ID: <059.76ec478d9fbadf76d878915c554262d2@haskell.org> #11746: I encountered an: internal error: evacuate: strange closure type 803645000 -------------------------------+-------------------------------------- Reporter: hkBst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by hkBst): * Attachment "tinychess.hs" added. code that I was running -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 14:50:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 14:50:38 -0000 Subject: [GHC] #11746: I encountered an: internal error: evacuate: strange closure type 803645000 In-Reply-To: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> References: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> Message-ID: <059.1eb8941c5d84e09da3415ff32432eebc@haskell.org> #11746: I encountered an: internal error: evacuate: strange closure type 803645000 -------------------------------+-------------------------------------- Reporter: hkBst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by hkBst): The last command and output for when this happened. Unfortunately I cannot reproduce. {{{ *Main> :main 6 White to play: /---V---V---\ | || | D---+---+---C | | | | D---+---+---C | | K | | \---A---A---/ [0,3,-5,3,-3,3] Black to play: /---V---V---\ | || | D---+---+---C | | | | D---+---+---C | K | | | \---A---A---/ [2,5,-3,3,-3,5] White to play: /---V---V---\ || | | D---+---+---C | | | | D---+---+---C | K | | | \---A---A---/ [0,5,-3,3,-5,3] Black to play: /---V---V---\ || | | D---+---+---C | | | | D---+---+---C | | K | | \---A---A---/ [-2,3,-3,5,-3,3] : internal error: evacuate: strange closure type 803645000 (GHC version 7.10.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 15:09:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 15:09:13 -0000 Subject: [GHC] #11747: `Strict` causes core lint error Message-ID: <051.5f1977edc97bd586c2cbc6d3ff3dff5b@haskell.org> #11747: `Strict` causes core lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: Strict | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghci -dcore-lint -XStrict -XGADTs -XRankNTypes -XTypeApplications -XScopedTypeVariables -ignore-dot-ghci GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Typeable Prelude Data.Typeable> let zero :: forall x. Typeable x => Maybe x; zero = do Refl <- eqT @Int @x; pure 0 Prelude Data.Typeable> zero *** Core Lint errors : in result of desugar expression *** : warning: In the expression: ds_d1t9 @ x_a1sx $dTypeable_a1sC @ x_a1sx $dTypeable_a1sz $dTypeable_a1sz :: Typeable x_a1sx [LclId, Str=DmdType] is out of scope *** Offending Program *** let { $dTypeable_a1sS :: Typeable () [LclId, Str=DmdType] $dTypeable_a1sS = D:Typeable @ * @ () (let { ds_d1tb :: TypeRep [LclId, Str=DmdType] ds_d1tb = mkPolyTyConApp $tc() ([] @ TypeRep) ([] @ TypeRep) } in \ (wild_00 :: Proxy# ()) -> ds_d1tb) } in let { $dShow_a1sU :: Show () [LclId, Str=DmdType] $dShow_a1sU = $fShow() } in let { $dShow_a1sP :: Show (Maybe ()) [LclId, Str=DmdType] $dShow_a1sP = $fShowMaybe @ () $dShow_a1sU } in letrec { ds_d1t9 :: forall x_a1sx. Typeable x_a1sx => forall x_a11P. Typeable x_a11P => Maybe x_a11P [LclId, Str=DmdType] ds_d1t9 = \ (@ x_a1sx) ($dTypeable_a1sC :: Typeable x_a1sx) -> let { $dTypeable_a1sz :: Typeable x_a1sx [LclId, Str=DmdType] $dTypeable_a1sz = $dTypeable_a1sC } in letrec { it_a1sw :: forall x_a11P. Typeable x_a11P => Maybe x_a11P [LclId, Str=DmdType] it_a1sw = zero; } in it_a1sw; it_a1dz :: forall x_a1sx. Typeable x_a1sx => Maybe x_a1sx [LclId, Str=DmdType] it_a1dz = \ (@ x_a1sx) ($dTypeable_a1sC :: Typeable x_a1sx) -> ds_d1t9 @ x_a1sx $dTypeable_a1sC @ x_a1sx $dTypeable_a1sz; } in case it_a1dz of it_a1dz { __DEFAULT -> thenIO @ () @ [()] (print @ (Maybe ()) $dShow_a1sP (it_a1dz @ () $dTypeable_a1sS)) (returnIO @ [()] (: @ () (unsafeCoerce# @ 'Lifted @ 'Lifted @ (forall x_a1sx. Typeable x_a1sx => Maybe x_a1sx) @ () it_a1dz) ([] @ ()))) } *** End of Offense *** : error: Compilation had errors *** Exception: ExitFailure 1 Prelude Data.Typeable> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 15:37:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 15:37:30 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol Message-ID: <044.47110be31f0548a4f623e31c109dd321@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Linking) | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found GHC panic when using both inline-c and local Win32 package. I don't know whether it's related to #6107. {{{ D:\ghc-bug-maybe>stack build Win32a-2.3.1.0: build Win32a-2.3.1.0: copy/register ghc-bug-maybe-0.1.0.0: configure ghc-bug-maybe-0.1.0.0: build Completed 2 action(s). -- While building package ghc-bug-maybe-0.1.0.0 using: C:\AppData\Roaming\stack\setup-exe-cache\x86_64-windows\setup- Simple-Cabal-1.22.5.0-ghc-7.10.3.exe --builddir=.stack-work\dist\2672c1f3 build lib:ghc-bug-maybe exe:DualternativeH-exe --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: D:\ghc-bug-maybe\.stack-work\logs\ghc-bug- maybe-0.1.0.0.log Configuring ghc-bug-maybe-0.1.0.0... Preprocessing library ghc-bug-maybe-0.1.0.0... [1 of 1] Compiling Lib ( src\Lib.hs, .stack- work\dist\2672c1f3\build\Lib.o ) GHC runtime linker: fatal error: I found a duplicate definition for symbol rgb whilst processing object file D:\ghc-bug-maybe\.stack-work\install\0464eb7a\lib\x86_64-windows- ghc-7.10.3\Win32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA\HSWin32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-mingw32): loadObj "D:\\ghc-bug-maybe\\.stack- work\\install\\0464eb7a\\lib\\x86_64-windows- ghc-7.10.3\\Win32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA\\HSWin32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 15:37:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 15:37:58 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.17683e3b06ec65e270cee65a36591bdb@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jeiea): * Attachment "ghc-bug-maybe.7z" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 15:48:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 15:48:16 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic In-Reply-To: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> References: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> Message-ID: <066.b88b0231e3e3995b048ae88798f6d4c9@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | TypeApplications GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T11456 Blocked By: | Blocking: Related Tickets: #11329 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Error2 seems to have the same mechanism (`:set +c` with a type application) as the original error, which is already in the testsuite. I personally don't think another test is warranted. Thanks for posting however -- if someone stumbles over this problem in the future, they will find your second case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 16:20:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 16:20:51 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.459cbcf1b06f64bfec73ee82d4230f7e@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I had a thought while falling asleep last night about what may be causing all of this. Previously, `Type` had a constructor `FunTy :: Type -> Type -> Type`. Now, the situation is more complex, with a `TyBinder`: {{{#!hs data Type = ... | ForAllTy TyBinder Type | ... data TyBinder = Named TyVar VisibilityFlag | Anon Type }}} What was `FunTy arg res` is now `ForAllTy (Anon arg) res`. But this refactoring means that we have an extra box for ''every'' function type. And there are a lot of those. Chasing all of these boxes might mean that everything goes just a bit slower... which is exactly what I've observed. This refactoring was not forced by `TypeInType`, but Simon and I thought it to be a good idea. It does simplify things in a bunch of places. It could be undone -- somewhat labor-intensive, but not theoretically hard. Even better would be to have unboxed and unpacked sums, which would allow GHC to inline `TyBinder` into `Type`. It also might be possible to simulate unboxed and unpacked sums through something like this: {{{#!hs data Type = ... | ForAllTyNamed TyVar VisibilityFlag Type | ForAllTyAnon Type Type | ... repSplitForAllTy :: Type -> Maybe (TyBinder, Type) repSplitForAllTy (ForAllTyNamed tv vis ty) = Just (Named tv vis, ty) repSplitForAllTy (ForAllTyAnon arg res) = Just (Anon arg, res) repSplitForAllTy _ = Nothing pattern ForAllTy :: TyBinder -> Type -> Type pattern ForAllTy bndr ty <- (repSplitForAllTy -> Just (bndr, ty)) where ForAllTy (Named tv vis) ty = ForAllTyNamed tv vis ty ForAllTy (Anon arg) res = ForAllTyAnon arg res }}} With these definitions, it would seem you could use `ForAllTy` just as it is done now. And my guess is that matching against, say `(ForAllTy (Anon arg) res) -> ...`, as is done somewhat frequently, would induce GHC to inline all of the splitting and matching (and allocation of the very- temporary `TyBinder`). That would need to be tested. But perhaps this is the answer to our woes. If it's performant, this would also be a good recipe to disseminate to people clamoring for unboxed, unpackable sums. With the forthcoming support for pattern synonyms in TH (not for 8.0! but likely for 8.2), this might even be possible to automate and implement unpacked sums in TH until GHC can support them for real. I won't be testing this anytime soon, sadly. Perhaps someone else can in time for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 16:39:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 16:39:21 -0000 Subject: [GHC] #11701: ghc generates significant slower code In-Reply-To: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> References: <049.71a47418bfaa1b01327dde2b5bb51a56@haskell.org> Message-ID: <064.779b04f923a26a8f1d7d5384a65f105c@haskell.org> #11701: ghc generates significant slower code -------------------------------------+------------------------------------- Reporter: HuStmpHrrr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: efficiency Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1997 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 92465259ae875a2fece5ab37a45e358ba1819d83. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 16:45:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 16:45:30 -0000 Subject: [GHC] #11707: Don't desugar large lists with build In-Reply-To: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> References: <046.bb4c3e9f99538210e94d375ca5857978@haskell.org> Message-ID: <061.3dead52ff1d03bbfef7229fe28664040@haskell.org> #11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2007, Wiki Page: | Phab:D2023 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 19ab5256a1a0a4e7d4ed0d36973fb43eeeda447f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 16:48:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 16:48:42 -0000 Subject: [GHC] #11595: Merge some TypeInType fixes In-Reply-To: <047.0b5fec0bd3fc52dea06510ee7b852368@haskell.org> References: <047.0b5fec0bd3fc52dea06510ee7b852368@haskell.org> Message-ID: <062.f1f19b8b237c58e8c9e166adf5e6b50c@haskell.org> #11595: Merge some TypeInType fixes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): ||= `master` =||= `ghc-8.0` =|| || af2f7f90dd0aaae0e33d1f8064377d1657f180a6 || 919e5c16a449a2cd6ed5c4017477294435a1b1a2 || || 01b29ebd25aceef8c35ea1cc3eabb6dafbb55daa || fcf36a9c64f2cc80cd8d6a062a6993eb00f44a11 || || 0706a103ae8c9c61e6bbaadd16b32da76aa5a749 || 4183976003ab9da51583d78debec798cd53789cc || || f8ab575404b726b499e72343b7220e9213880dd4 || todo || || 3e1b8824c849d063c7354dbdf63ae2910cf0fdfc || todo || || 35e937973f61a7e5534ecd0b1c67111cd82d4238 || fefaba919f4fcfe4eb71198d91a8718b72d7b6a1 || || 5c0c751ab2deb4b03b8a2055d4f60d2574cae32f || f840006b3e05c426951605f96ac5791afff10540 || || 0beb82c171913508dc0de91851ab8e90821d8ba8 || todo || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 18:19:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 18:19:27 -0000 Subject: [GHC] #11595: Merge some TypeInType fixes In-Reply-To: <047.0b5fec0bd3fc52dea06510ee7b852368@haskell.org> References: <047.0b5fec0bd3fc52dea06510ee7b852368@haskell.org> Message-ID: <062.2daa891b162fc9a3aaf00502e9f9f8b6@haskell.org> #11595: Merge some TypeInType fixes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: `ghc-8.0` should now have everything mentioned in comment:3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 18:19:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 18:19:42 -0000 Subject: [GHC] #11595: Merge some TypeInType fixes In-Reply-To: <047.0b5fec0bd3fc52dea06510ee7b852368@haskell.org> References: <047.0b5fec0bd3fc52dea06510ee7b852368@haskell.org> Message-ID: <062.e701946cd2bca3d976512865d5e457d0@haskell.org> #11595: Merge some TypeInType fixes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks for collecting these so nicely, Richard! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 18:39:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 18:39:10 -0000 Subject: [GHC] #11746: I encountered an: internal error: evacuate: strange closure type 803645000 In-Reply-To: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> References: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> Message-ID: <059.a3e9ad32266f1832773285d5b6f47435@haskell.org> #11746: I encountered an: internal error: evacuate: strange closure type 803645000 -------------------------------+-------------------------------------- Reporter: hkBst | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by bgamari): * priority: normal => high * cc: simonmar (added) * milestone: => 8.0.1 Comment: I can also reproduce this with your example. Simply load the file into ghci and run, {{{ $ ghci tinychess.hs GHCi, version 7.10.2.20151118: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tinychess.hs, interpreted ) Ok, modules loaded: Main. ?> import Control.Monad (forever) ?> forever $ playGame 6 . . . D---+---+---C | | K | | \---A---A---/ [-2,3,-3,5,-3,3] : internal error: evacuate: strange closure type 1195407224 (GHC version 7.10.2.20151118 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted $ }}} The problem is evidently still lurking as I see segmentation faults if I run the same test with a recent `ghc-8.0` snapshot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 18:48:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 18:48:14 -0000 Subject: [GHC] #11746: I encountered an: internal error: evacuate: strange closure type 803645000 In-Reply-To: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> References: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> Message-ID: <059.398daeab5f772992d7528727f9c5d9ab@haskell.org> #11746: I encountered an: internal error: evacuate: strange closure type 803645000 -------------------------------+-------------------------------------- Reporter: hkBst | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by bgamari): Reproducing in gdb reveals this, {{{ (gdb) bt #0 0x00007fffecd46507 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007fffecd478da in __GI_abort () at abort.c:89 #2 0x00007fffed2f4302 in rtsFatalInternalErrorFn (s=, ap=0x7fffeb38dba8) at rts/RtsMessages.c:182 #3 0x00007fffed2f4460 in barf (s=s at entry=0x7fffed31ab80 "evacuate: strange closure type %d") at rts/RtsMessages.c:46 #4 0x00007fffed2df88e in evacuate (p=p at entry=0x204ed00a8) at rts/dist/build/sm/Evac_thr.c:740 #5 0x00007fffed2fe711 in tidyWeakList (gen=) at rts/sm/MarkWeak.c:270 #6 0x00007fffed2fea08 in traverseWeakPtrList () at rts/sm/MarkWeak.c:130 #7 0x00007fffed300332 in GarbageCollect (collect_gen=collect_gen at entry=1, do_heap_census=do_heap_census at entry=rtsFalse, gc_type=gc_type at entry=2, cap=cap at entry=0x7fffed52ad00 ) at rts/sm/GC.c:409 #8 0x00007fffed2f1d51 in scheduleDoGC (pcap=pcap at entry=0x7fffeb38deb0, task=task at entry=0x7af4f0, force_major=force_major at entry=rtsFalse) at rts/Schedule.c:1652 #9 0x00007fffed2f294e in schedule (initialCapability=, task=task at entry=0x7af4f0) at rts/Schedule.c:551 #10 0x00007fffed2f3a5c in scheduleWorker (cap=, task=0x7af4f0) at rts/Schedule.c:2378 #11 0x00007ffff738c284 in start_thread (arg=0x7fffeb38e700) at pthread_create.c:333 #12 0x00007fffecdfba4d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 }}} It appears this is weak-pointer related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 18:51:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 18:51:59 -0000 Subject: [GHC] #10073: Idris REPL is pretty and we can too In-Reply-To: <048.41fb030b4d1813ef94f8c7de6a966874@haskell.org> References: <048.41fb030b4d1813ef94f8c7de6a966874@haskell.org> Message-ID: <063.04b4fb419458c52f90777d707797e8f2@haskell.org> #10073: Idris REPL is pretty and we can too -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8809,#10179 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #8809,#10073,#10179 => #8809,#10179 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 19:37:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 19:37:38 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.5ce0c4cb38a51c90c638cea4a70b8641@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > With the forthcoming support for pattern synonyms in TH (not for 8.0! but likely for 8.2) Given how quickly osa1 seems to be moving on unboxed sums it's entirely possible that we will have proper unpacking by 8.2 (at least I have my fingers crossed). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 22:19:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 22:19:37 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.5472e1bc8fc2e288991d45bd09ba51a1@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by carter): what version of OS X, XCODE (and thus puttatively GHC) are impacted? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 23:06:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 23:06:37 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.e3e67c3dc371ea8d2a1723a78806045d@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Description changed by hvr: @@ -80,0 +80,13 @@ + + ---- + + Alternative workaround (since it turns out that Apple's `nm` violates + POSIX even more than assumed by not even supporting `nm -P -t x`): + + Have `deriveConstants` derive a known value, e.g. the value `0x1234` via + `char derivedConstantCONTROL_GROUP[1+0x1234];`, and if the value for + `CONTROL_GROUP` comes back as `18016` we know that we need to fixup all + decimal-wrongly-as-hex parsed integers, if it comes back as `4660` we + parsed correctly; any different value is a non-recoverable error + + This would also serve as a general integrity check for //all// platforms New description: TLDR: Apple messed up again and broke POSIX compliance luite ran into problems when he installed the latest Xcode update because the derived platform constants were off. He provided me the output of `nm -P ./includes/dist- derivedconstants/header/tmp.o` which turned out to have numbers which didn't make sense: {{{ _derivedConstantAP_STACK_SPLIM C 1025 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C 253 0 _derivedConstantBLOCK_SIZE C 4097 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ... }}} Which with an older Xcode version would have looked like {{{ _derivedConstantAP_STACK_SPLIM C 401 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C fd 0 _derivedConstantBLOCK_SIZE C 1001 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ... }}} So obviously `nm -P`'s output changed from hexadecimal to (non-compliant) decimal formatting of numbers. For reference, here's how POSIX specifies the semantics of `nm`: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html ---- > `-P` > Write information in a portable output format, as specified in the STDOUT section. ... > If the `-P` option is specified, the previous information shall be displayed using the following portable format. The three versions differ depending on whether `-t d`, `-t o`, or `-t x` was specified, respectively: > > {{{"%s%s %s %d %d\n", , , , , }}} > > {{{"%s%s %s %o %o\n", , , , , }}} > > {{{"%s%s %s %x %x\n", , , , , }}} ... > '''If `-P` is specified, but `-t` is not, the format shall be as if `-t x` had been specified.''' ---- In the event that Apple can't be bothered to fix this bug (I've had bad experience with Apple and standard-compliance in the past, hence my pessimism) we could try to workaround by using `nm -P -t x` when building on OSX... ---- Alternative workaround (since it turns out that Apple's `nm` violates POSIX even more than assumed by not even supporting `nm -P -t x`): Have `deriveConstants` derive a known value, e.g. the value `0x1234` via `char derivedConstantCONTROL_GROUP[1+0x1234];`, and if the value for `CONTROL_GROUP` comes back as `18016` we know that we need to fixup all decimal-wrongly-as-hex parsed integers, if it comes back as `4660` we parsed correctly; any different value is a non-recoverable error This would also serve as a general integrity check for //all// platforms -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 23 23:32:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Mar 2016 23:32:20 -0000 Subject: [GHC] #11729: `make sdist` target fails horribly if `lndir` is unavailable (was: `make sdist` target fails) In-Reply-To: <044.fb56a4d177682d7be236a48a26caf9dc@haskell.org> References: <044.fb56a4d177682d7be236a48a26caf9dc@haskell.org> Message-ID: <059.307646a5eaaef6649484695a941d9dc0@haskell.org> #11729: `make sdist` target fails horribly if `lndir` is unavailable -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 00:56:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 00:56:17 -0000 Subject: [GHC] #11676: Preserve name of original function in worker name In-Reply-To: <046.9564de68fd6f249b5e9dd2c92248810c@haskell.org> References: <046.9564de68fd6f249b5e9dd2c92248810c@haskell.org> Message-ID: <061.b1bdf6d3d3b9964a67cfb836a7646b8d@haskell.org> #11676: Preserve name of original function in worker name -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1970 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I unfortunately just noticed that the commit message of the commit in comment:4 no longer reflects what the commit itself implements. The simplifier does not maintain a stack of contexts; instead we simply pass the context name in from the various call-sites of `makeTrivial` and friends. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 00:56:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 00:56:40 -0000 Subject: [GHC] #11676: Preserve name of original function in worker name In-Reply-To: <046.9564de68fd6f249b5e9dd2c92248810c@haskell.org> References: <046.9564de68fd6f249b5e9dd2c92248810c@haskell.org> Message-ID: <061.c4f65a36160920a7ff8db7193fe017f2@haskell.org> #11676: Preserve name of original function in worker name -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1970 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Merged as bceb5becdb408316580c970c1f75cbde92a4f9e6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 03:21:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 03:21:09 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.cb80fe46be667fe805c70ff0a1dc9a51@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by carter): it looks like the new version of nm is llvm-nm, or at least a snapshot thereof http://llvm.org/docs/CommandGuide/llvm-nm.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 03:22:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 03:22:11 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.0cfa701881f9cff2d6bd69961eae1392@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by carter): heres a listing of the new apple nm flag options/output, for comparision with the prior one {{{ $ /Users/carter/Desktop/bad-cli-tools/Command\ Line\ Tools\ \(OS\ X\ 10.11\)/CLTools_Executables.pkg.cpio.xz/Library/Developer/CommandLineTools/usr/bin/nm --help OVERVIEW: llvm symbol table dumper USAGE: nm [options] --s Dump only symbols from this segment and section name, Mach-O only OPTIONS: General options: -B - Alias for --format=bsd -P - Alias for --format=posix -aarch64-neon-syntax - Choose style of NEON code to emit from AArch64 backend: =generic - Emit generic NEON assembly =apple - Emit Apple-style NEON assembly -arch= - architecture(s) from a Mach-O file to dump -debug-syms - Show all symbols, even debugger only -defined-only - Show only defined symbols -dynamic - Display the dynamic symbols instead of normal symbols. -enable-objc-arc-opts - enable/disable all ARC Optimizations -enable-scoped-noalias - -enable-tbaa - -extern-only - Show only external symbols -format - Specify output format =bsd - BSD format =sysv - System V format =posix - POSIX.2 format =darwin - Darwin -m format -join-liveintervals - Coalesce copies (default=true) -just-symbol-name - Print just the symbol's name -m - Alias for --format=darwin -no-llvm-bc - Disable LLVM bitcode reader -no-sort - Show symbols in order encountered -numeric-sort - Sort symbols by address -print-after-all - Print IR after each pass -print-armap - Print the archive map -print-before-all - Print IR before each pass -print-file-name - Precede each symbol with the object file it came from -print-size - Show symbol size instead of address -reverse-sort - Sort in reverse order -rng-seed= - Seed for the random number generator -s= - Dump only symbols from this segment and section name, Mach-O only -size-sort - Sort symbols by size -stackmap-version= - Specify the stackmap encoding version (default = 1) -time-passes - Time each pass, printing elapsed time for each on exit -undefined-only - Show only undefined symbols -verify-dom-info - Verify dominator info (time consuming) -verify-loop-info - Verify loop info (time consuming) -verify-scev - Verify ScalarEvolution's backedge taken counts (slow) -x - Print symbol entry in hex, Mach-O only -x86-asm-syntax - Choose style of code to emit from X86 backend: =att - Emit AT&T-style assembly =intel - Emit Intel-style assembly Generic Options: -help - Display available options (-help-hidden for more) -help-list - Display list of available options (-help-list- hidden for more) -version - Display the version of this program }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 03:57:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 03:57:30 -0000 Subject: [GHC] #7353: Make system IO interruptible on Windows In-Reply-To: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> References: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> Message-ID: <063.0b642d9b66f80451f7420c29e46fee1b@haskell.org> #7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): I will be spending the next two months working on this ticket, picking up where @joeyadams left off. My intention is to produce a patchset suitable for inclusion for GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 06:49:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 06:49:45 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.12c4b85f4673555e6b6646541def6bc7@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hi, thanks for the report! This is likely related to #11223 I will test to see if my local branch solves this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 07:24:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 07:24:36 -0000 Subject: [GHC] #11746: I encountered an: internal error: evacuate: strange closure type 803645000 In-Reply-To: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> References: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> Message-ID: <059.6f7202f95978980c026b3c6ff33d4632@haskell.org> #11746: I encountered an: internal error: evacuate: strange closure type 803645000 -------------------------------+-------------------------------------- Reporter: hkBst | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by hkBst): I don't know if this is related or not, but after compiling with profiling enabled: $ ghc -O2 -fforce-recomp -prof -fprof-auto tinychess.hs even $ $ time ./tinychess 0 +RTS -p would exhaust memory on my machine and I had to kill it. The argument 0 determines the depth of moves that are considered for evaluating the possible next positions. Without profiling this completes instantly as one would expect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 09:47:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 09:47:52 -0000 Subject: [GHC] #11742: 'Strict' extension is incompatible with 'deriving' mechanism In-Reply-To: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> References: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> Message-ID: <059.c7b19dfdf10c4e206677f714935fa4f2@haskell.org> #11742: 'Strict' extension is incompatible with 'deriving' mechanism -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"db9e4eb4e3fe916df7a69da1b211083ad6068aff/ghc" db9e4eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="db9e4eb4e3fe916df7a69da1b211083ad6068aff" Move DFunUnfolding generation to TcInstDcls The desugarer had a fragile case to generate the Unfolding for a DFun. This patch moves the unfolding generation to TcInstDcls, where all the pieces are to hand. Fixes Trac #11742 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 09:50:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 09:50:24 -0000 Subject: [GHC] #11742: 'Strict' extension is incompatible with 'deriving' mechanism In-Reply-To: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> References: <044.1099056177bb9b8f8365ada563f6c2b6@haskell.org> Message-ID: <059.ce71d8c0b983a21ad0aca6640364fac8@haskell.org> #11742: 'Strict' extension is incompatible with 'deriving' mechanism -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T11742 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => simplCore/should_compile/T11742 Comment: Good bug! Pls merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 09:51:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 09:51:08 -0000 Subject: [GHC] #11145: Template Haskell quotes of data instance GADTs is totally broken In-Reply-To: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> References: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> Message-ID: <062.1fd91fe6ec61cd3c75735151137871c7@haskell.org> #11145: Template Haskell quotes of data instance GADTs is totally broken -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bollmann Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1978 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e57b9ffee858278bf1ef8ed0754346685334b9ba/ghc" e57b9ffe/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e57b9ffee858278bf1ef8ed0754346685334b9ba" Fix regression test for #11145. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2032 GHC Trac Issues: #11145 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 09:51:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 09:51:08 -0000 Subject: [GHC] #11667: Incorrect pattern synonym types in error messages In-Reply-To: <046.01f7d6134e84da2cd298573ade0572c4@haskell.org> References: <046.01f7d6134e84da2cd298573ade0572c4@haskell.org> Message-ID: <061.03cc0a7e5a837ebe01197eaa1580db1d@haskell.org> #11667: Incorrect pattern synonym types in error messages -------------------------------------+------------------------------------- Reporter: rdragon | Owner: rdragon Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11213 | Differential Rev(s): Phab:D1967 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"997312b04c56017197250096d61f3e8fab502319/ghc" 997312b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="997312b04c56017197250096d61f3e8fab502319" Add `PatSynSigSkol` and modify `PatSynCtxt` As the type of a pattern synonym cannot in general be represented by a value of type Type, we cannot use a value `SigSkol (PatSynCtxt n) (Check ty)` to represent the signature of a pattern synonym (this causes incorrect signatures to be printed in error messages). Therefore we now represent it by a value `PatSynSigSkol n` (instead of incorrect signatures we simply print no explicit signature). Furthermore, we rename `PatSynCtxt` to `PatSynBuilderCtxt`, and use `SigSkol (PatSynBuilderCtxt n) (Check ty)` to represent the type of a bidirectional pattern synonym when used in an expression context. Before, this type was represented by a value `SigSkol (PatSynCtxt n) (Check ty)`, which caused incorrect error messages. Also, in `mk_dict_err` of `typecheck\TcErrors.hs` we now distinguish between all enclosing implications and "useful" enclosing implications, for better error messages concerning pattern synonyms. See `Note [Useful implications]`. See the Phabricator page for examples. Reviewers: mpickering, goldfire, simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1967 GHC Trac Issues: #11667 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 09:51:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 09:51:08 -0000 Subject: [GHC] #11733: Undeclared identifier 'CLOCK_PROCESS_CPUTIME_ID' on OS X In-Reply-To: <044.34d6ef1f50509835f04a609c09b1a0b3@haskell.org> References: <044.34d6ef1f50509835f04a609c09b1a0b3@haskell.org> Message-ID: <059.aaf94c3f5d517105f94e7e1095f8235f@haskell.org> #11733: Undeclared identifier 'CLOCK_PROCESS_CPUTIME_ID' on OS X -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2ddfb7573793c2a288d0979868f876af75733426/ghc" 2ddfb75/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2ddfb7573793c2a288d0979868f876af75733426" base: Fix ClockGetTime on OS X Apparently _POSIX_CPUTIME may be defined as -1 if CLOCK_PROCESS_CPUTIME_ID isn't defined. Test Plan: Validate Reviewers: austin, hvr, erikd, goldfire Reviewed By: erikd, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2028 GHC Trac Issues: #11733 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 09:51:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 09:51:08 -0000 Subject: [GHC] #10162: Add unicode syntax for banana brackets In-Reply-To: <045.f7ad53896487f5f5496f96174e92dff7@haskell.org> References: <045.f7ad53896487f5f5496f96174e92dff7@haskell.org> Message-ID: <060.c8089f2c8cf29516a3328c958f9b40e9@haskell.org> #10162: Add unicode syntax for banana brackets -------------------------------------+------------------------------------- Reporter: zardoz | Owner: JoshPrice247 Type: feature request | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.8.4 (Parser) | Keywords: unicode, Resolution: | UnicodeSyntax, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2012 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"03a1bb4d010f94bed233ca261bf44e00c7bd9878/ghc" 03a1bb4d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="03a1bb4d010f94bed233ca261bf44e00c7bd9878" Add unicode syntax for banana brackets Summary: Add "?" and "?" as unicode alternatives for "(|" and "|)" respectively. This must be implemented differently than other unicode additions because ?" and "?" are interpretted as a $unigraphic rather than a $unisymbol. Test Plan: validate Reviewers: goldfire, bgamari, austin Reviewed By: bgamari, austin Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2012 GHC Trac Issues: #10162 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 09:51:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 09:51:08 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.a2e08dfb4cc06e32a632e0371aa8e531@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6c2c853b11fe25c106469da7b105e2be596c17de/ghc" 6c2c853b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6c2c853b11fe25c106469da7b105e2be596c17de" Various ticky-related work this Diff contains small, self-contained changes as I work towards fixing #10613. It is mostly created to let harbormaster do its job, but feedback is welcome as well. Please do not merge this via arc; I?d like to push the individual patches as layed out here. I might push mostly trivial ones even without review, as long as the build passes. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2014 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 09:51:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 09:51:08 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.f7019b00852a2a38c9f05ffa2176cd50@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: kaiha Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2015 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9f9345e5ad55e4a02e6de9afac814ac58c852ff2/ghc" 9f9345e5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9f9345e5ad55e4a02e6de9afac814ac58c852ff2" Create empty dump files (fixes #10320) Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2015 GHC Trac Issues: #10320 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 09:51:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 09:51:08 -0000 Subject: [GHC] #11710: Fusion of a simple listArray call is very fragile In-Reply-To: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> References: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> Message-ID: <061.a8fa9e158533e3fbc188619bf3d38846@haskell.org> #11710: Fusion of a simple listArray call is very fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2023 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0db05941668814094c2b18b3d35e1deaed36c210/ghc" 0db05941/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0db05941668814094c2b18b3d35e1deaed36c210" DsExpr: Rip out static/dynamic check in list desugaring Previously we would try to break explicit lists into a dynamic prefix and static tail and desugar the former into a `build` expression. Unfortunately, this heuristic resulted in surprising behavior (see #11710) and wasn't pulling its weight. Here we drop it (along with the `-fsimple-list-literals` flag), leaving only the list length heuristic to determine whether `build` or cons list desugaring should be used. Test Plan: Validate Reviewers: simonpj, austin Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2023 GHC Trac Issues: #11710 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 09:51:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 09:51:08 -0000 Subject: [GHC] #9405: Ticky results should be displayed even during interrupts (Ctrl-c) In-Reply-To: <052.9c2a439965f718a8964f4e460ff5ae13@haskell.org> References: <052.9c2a439965f718a8964f4e460ff5ae13@haskell.org> Message-ID: <067.ddaed452af9fa4c3601dc120128bad7a@haskell.org> #9405: Ticky results should be displayed even during interrupts (Ctrl-c) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2008 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2708c22b8c8a415446d963575c0396a038b43a93/ghc" 2708c22b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2708c22b8c8a415446d963575c0396a038b43a93" Close ticky profiling file stream after printing (#9405) Test Plan: T9405 Reviewers: simonmar, austin, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2008 GHC Trac Issues: #9405 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 09:56:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 09:56:34 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.9804e39930f956dd7664e5f743852e29@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): I have ghc 7.8.4, 7.10.3 and 8.0.0.20160316 installed on my machine. I cloned the vector git repo, set up a cabal sandbox and then for each ghc, `cabal install --dependencies-only`. Them for each ghc I did `cabal clean && time cabal build`. I've timed this with each compiler three times and this result is pretty representative: {{{ Compiler real user sys ---------------------------------------------------- 7.8.4 3m26.106s 4m42.508s 1m40.868s 7.10.3 4m32.690s 6m18.956s 3m6.416s 8.0.0.20160316 1m19.510s 1m52.796s 0m47.992s }}} It seems this partially fixed between 7.10.1 and 7.10.3 anyway, and 8.0 is far better than either of the old releases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 10:02:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 10:02:59 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.be9f78eca5654b6e55827287e094096a@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yay! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 10:17:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 10:17:24 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.b761a2aad93715cdc1c869ddb2680a04@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): From IRC: {{{ erikd, IIRC I have a more minimal testcase as well the problem centers around zip when things are inlined has changed which results in a large number of stream fusion primitives that can't be resolved until late in compilation which produces a large amount of code erikd, that should at least be a hint unfortunately I ran out of time before identifying the root cause erikd, https://gist.github.com/bgamari/2ca0f7d2a4e0b6447aee erikd, that's my minimized testcase thanks, i'll check it out It helps to look at the -dverbose-core2core output comparing between the relevant compiler versions erikd, this utility may come in handy for turning the verbose-core2core output into something less unwieldy https://github.com/bgamari/ghc-utils/blob/master/split- core2core.py }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 10:20:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 10:20:17 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.d2eb4494ec3b014700475514d41bcf44@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Replying to [comment:13 simonpj]: > Yay! Certainly great that the compile times have improved, but @Bgamari points out that the original problem was about compilng the test suite. More investigation still needed (tomorrow). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 11:31:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 11:31:04 -0000 Subject: [GHC] #10162: Add unicode syntax for banana brackets In-Reply-To: <045.f7ad53896487f5f5496f96174e92dff7@haskell.org> References: <045.f7ad53896487f5f5496f96174e92dff7@haskell.org> Message-ID: <060.adda5f132dc5a17c80d7f9246466c763@haskell.org> #10162: Add unicode syntax for banana brackets -------------------------------------+------------------------------------- Reporter: zardoz | Owner: JoshPrice247 Type: feature request | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 7.8.4 (Parser) | Keywords: unicode, Resolution: fixed | UnicodeSyntax, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2012 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: ? => 8.2.1 Comment: > Are there any plans of supporting idiom brackets? ? Just 1 + Just 2 ? could be used and Arrows are not used much at all I don't know of any work along these lines. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 11:32:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 11:32:02 -0000 Subject: [GHC] #11710: Fusion of a simple listArray call is very fragile In-Reply-To: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> References: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> Message-ID: <061.6cfe82bb209f890d00f2eb6445e0f5d5@haskell.org> #11710: Fusion of a simple listArray call is very fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2023 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 11:34:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 11:34:41 -0000 Subject: [GHC] #11710: Fusion of a simple listArray call is very fragile In-Reply-To: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> References: <046.d863423cdcca10f59ad67def2223d4cb@haskell.org> Message-ID: <061.1872a06fa0fa5a1286f9e32d6bc895ca@haskell.org> #11710: Fusion of a simple listArray call is very fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2023 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 193fdec1a4ad9a979974b21864ba026b35633170. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 11:35:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 11:35:44 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.86133cbb5662417f351cf2bb87c9038d@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: kaiha Type: bug | Status: merge Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2015 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.0.1 @@ -1,5 +1,5 @@ - For example, I ran with -ddump-rule-firings -ddump-to-file when there were - no rule firings. GHC should have created an empty foo.dump-rule-firings - file. (Instead it left the existing foo.dump-rule-firings from a previous - run intact, which could have been misleading if I didn't already know that - the most recent run had no rule firings.) + For example, I ran with `-ddump-rule-firings -ddump-to-file` when there + were no rule firings. GHC should have created an empty `foo.dump-rule- + firings` file. (Instead it left the existing `foo.dump-rule-firings` from + a previous run intact, which could have been misleading if I didn't + already know that the most recent run had no rule firings.) New description: For example, I ran with `-ddump-rule-firings -ddump-to-file` when there were no rule firings. GHC should have created an empty `foo.dump-rule- firings` file. (Instead it left the existing `foo.dump-rule-firings` from a previous run intact, which could have been misleading if I didn't already know that the most recent run had no rule firings.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 11:36:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 11:36:24 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.d1a965c3265c3a10ee9ac884c69ab1aa@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: kaiha Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2015 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 35351996f47bde97db696cd9a08439e00bfc2f00. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 11:37:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 11:37:24 -0000 Subject: [GHC] #11702: Constant folding on 'mod/Word' - incorrect result In-Reply-To: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> References: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> Message-ID: <060.1ef0510fdd56ca118c1d032c0eaae301@haskell.org> #11702: Constant folding on 'mod/Word' - incorrect result -------------------------------------+------------------------------------- Reporter: ondrap | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Prelude | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2004 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 630d07995a814f665531eaecf07dffe1298c6fd5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 11:43:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 11:43:44 -0000 Subject: [GHC] #11667: Incorrect pattern synonym types in error messages In-Reply-To: <046.01f7d6134e84da2cd298573ade0572c4@haskell.org> References: <046.01f7d6134e84da2cd298573ade0572c4@haskell.org> Message-ID: <061.8615d02b6b62b9838bad2b6584580401@haskell.org> #11667: Incorrect pattern synonym types in error messages -------------------------------------+------------------------------------- Reporter: rdragon | Owner: rdragon Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11213 | Differential Rev(s): Phab:D1967 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: 8.0.2 => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 11:46:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 11:46:10 -0000 Subject: [GHC] #11653: Emit timings for individual compiler passes In-Reply-To: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> References: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> Message-ID: <061.743390d35d224942a4c2e4544f387f89@haskell.org> #11653: Emit timings for individual compiler passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1959 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge Comment: Phab:D1959 was merged as 8048d51be0676627b417c128af0b0c352b75c537. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 11:46:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 11:46:42 -0000 Subject: [GHC] #11653: Emit timings for individual compiler passes In-Reply-To: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> References: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> Message-ID: <061.34b3dfc3f304b50d98fdeed6c744d63f@haskell.org> #11653: Emit timings for individual compiler passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1959 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 8ad33de4b256fcad42d1f8f9b67ceaaae03ccb1a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 11:50:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 11:50:27 -0000 Subject: [GHC] #9405: Ticky results should be displayed even during interrupts (Ctrl-c) In-Reply-To: <052.9c2a439965f718a8964f4e460ff5ae13@haskell.org> References: <052.9c2a439965f718a8964f4e460ff5ae13@haskell.org> Message-ID: <067.1fba248e529ca834cdb6a6740febef0e@haskell.org> #9405: Ticky results should be displayed even during interrupts (Ctrl-c) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: archblob Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Profiling | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2008 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Merged to `ghc-8.0` as 5bf1a916da4e810e98c70498cb59f2da72131052. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 12:21:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 12:21:46 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.71bce92e6c98efdeebb27bd005e21c8c@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ignore the commit in comment:22; I forgot that this Diff was not intended to be merged. I'll be reverting it shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 12:31:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 12:31:48 -0000 Subject: [GHC] #11741: -Wredundant-constraints is not in the manual's flag reference In-Reply-To: <047.f9b39d0f99f8346da2ca26cd49cc61f2@haskell.org> References: <047.f9b39d0f99f8346da2ca26cd49cc61f2@haskell.org> Message-ID: <062.c9f46a1fb347b170ae5bc9881c71310a@haskell.org> #11741: -Wredundant-constraints is not in the manual's flag reference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2035 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2035 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 12:42:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 12:42:00 -0000 Subject: [GHC] #11749: Add long forms for -keep-* flags and possibly deprecate short forms Message-ID: <046.6395df32b5dfef07d0ac806a2a326d62@haskell.org> #11749: Add long forms for -keep-* flags and possibly deprecate short forms -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The fact that GHC's `-keep-*` flags are short flags (e.g. begin with only one dash) is confusing and inconsistent with most of the rest of our flags, which use the typical gnu long form (with two dashes). I propose that we add `--keep-*` flags and consider deprecating the short forms at some point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 12:47:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 12:47:20 -0000 Subject: [GHC] #11749: Add long forms for multi-character short-form flags and possibly deprecate short forms (was: Add long forms for -keep-* flags and possibly deprecate short forms) In-Reply-To: <046.6395df32b5dfef07d0ac806a2a326d62@haskell.org> References: <046.6395df32b5dfef07d0ac806a2a326d62@haskell.org> Message-ID: <061.c6150814d637c82634d16d035c65cb39@haskell.org> #11749: Add long forms for multi-character short-form flags and possibly deprecate short forms -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -1,3 +1,3 @@ - The fact that GHC's `-keep-*` flags are short flags (e.g. begin with only - one dash) is confusing and inconsistent with most of the rest of our - flags, which use the typical gnu long form (with two dashes). + Many of GHC's long form flags use BSD-style single-dash prefixes (e.g. + `-keep-llvm-files`, `-rtsopts`). Many others use gnu-style double-dash + prefixes (e.g. `--version`, `--supported-languages`). @@ -5,2 +5,3 @@ - I propose that we add `--keep-*` flags and consider deprecating the short - forms at some point. + This is arguably more confusing than necessary. IMHO it seems reasonable + to add Gnu forms for our BSD-style flags (e.g. add `--keep-llvm-files`) + and consider deprecating the latter at some point in the future. New description: Many of GHC's long form flags use BSD-style single-dash prefixes (e.g. `-keep-llvm-files`, `-rtsopts`). Many others use gnu-style double-dash prefixes (e.g. `--version`, `--supported-languages`). This is arguably more confusing than necessary. IMHO it seems reasonable to add Gnu forms for our BSD-style flags (e.g. add `--keep-llvm-files`) and consider deprecating the latter at some point in the future. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 13:00:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 13:00:39 -0000 Subject: [GHC] #11145: Template Haskell quotes of data instance GADTs is totally broken In-Reply-To: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> References: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> Message-ID: <062.393a6137897815e69f43a73b88797e7d@haskell.org> #11145: Template Haskell quotes of data instance GADTs is totally broken -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bollmann Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: fixed | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1978 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollmann): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 13:07:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 13:07:12 -0000 Subject: [GHC] #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm In-Reply-To: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> References: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> Message-ID: <060.88e4b568290c69db2cbcebf59f15ee5a@haskell.org> #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T3220, | indexed- | types/should_compile/ColInference3 Blocked By: | Blocking: Related Tickets: #11371, #11643 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good news on this one. I know exactly what is happening and have a fix in the works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 15:12:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 15:12:32 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.26e0207e5016beec480beac727c744be@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1961 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"371608f1cdaf20c49eb6c5ec165b9eb08b745a89/ghc" 371608f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="371608f1cdaf20c49eb6c5ec165b9eb08b745a89" Default RuntimeRep variables unless -fprint-explicit-runtime-reps Summary: Addresses #11549 by defaulting `RuntimeRep` variables to `PtrRepLifted` and adding a new compiler flag `-fprint-explicit-runtime-reps` to disable this behavior. This is just a guess at the right way to go about this. If it's wrong-beyond-any-hope just say so. Test Plan: Working on a testcase Reviewers: goldfire, austin Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1961 GHC Trac Issues: #11549 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 15:12:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 15:12:32 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.8c598417cbfc101979ad1478b40d1cb4@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D669, Wiki Page: | Phab:D2027 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1448f8ab2379452312f1f74f6d5ba4de8ad3d47e/ghc" 1448f8ab/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1448f8ab2379452312f1f74f6d5ba4de8ad3d47e" Show: Restore redundant parentheses around records As discussed in #2530 we are going to continue to produce parentheses here in order to preserve compatibility with previous GHC releases. It was found that dropped parentheses would break some testsuites which compared against output from Show. This has been documented in the users guide. This reverts commit 5692643c9d17e746327588cd6157a923642b7975. Test Plan: Validate Reviewers: hvr, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2027 GHC Trac Issues: #2350 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 15:12:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 15:12:32 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.130f28f126b11c6f1b8a32b305c41932@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0bd0c31e833055eb3e86177f70c4b4d93d5a1c11/ghc" 0bd0c31e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0bd0c31e833055eb3e86177f70c4b4d93d5a1c11" Defer inlining of Eq for primitive types Summary: This is one solution to #11688, wherein (==) was inlined to soon defeating a rewrite rule provided by bytestring. Since the RHSs of Eq's methods are simple, there is little to be gained and much to be lost by inlining them early. For instance, the bytestring library provides, ```lang=haskell break :: (Word8 -> Bool) -> ByteString -> (ByteString, ByteString) breakByte :: Word8 -> ByteString -> (ByteString, ByteString) ``` and a rule ``` forall x. break ((==) x) = breakByte x ``` since `breakByte` implments an optimized version of `break (== x)` for known `x :: Word8`. If we allow `(==)` to be inlined too early, we will prevent this rule from firing. This was the cause of #11688. This patch just defers the `Eq` methods, although it's likely worthwhile giving `Ord` this same treatment. This regresses compiler allocations for T9661 by about 8% due to the additional inlining that we now require the simplifier to perform. Updates the `bytestring` submodule to include updated rewrite rules which match on `eqWord8` instead of `(==)`. Test Plan: * Validate, examine performance impact Reviewers: simonpj, hvr, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1980 GHC Trac Issues: #11688 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 15:12:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 15:12:32 -0000 Subject: [GHC] #2350: hSetEcho: failed (failed to set echoing) on Windows In-Reply-To: <046.f635148d87eda19915274a731d766966@haskell.org> References: <046.f635148d87eda19915274a731d766966@haskell.org> Message-ID: <061.0d35fdbcad1432ed58087fee6aac25c8@haskell.org> #2350: hSetEcho: failed (failed to set echoing) on Windows -------------------------------------+--------------------------------- Reporter: EricKow | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Test Case: | -------------------------------------+--------------------------------- Comment (by Ben Gamari ): In [changeset:"1448f8ab2379452312f1f74f6d5ba4de8ad3d47e/ghc" 1448f8ab/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1448f8ab2379452312f1f74f6d5ba4de8ad3d47e" Show: Restore redundant parentheses around records As discussed in #2530 we are going to continue to produce parentheses here in order to preserve compatibility with previous GHC releases. It was found that dropped parentheses would break some testsuites which compared against output from Show. This has been documented in the users guide. This reverts commit 5692643c9d17e746327588cd6157a923642b7975. Test Plan: Validate Reviewers: hvr, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2027 GHC Trac Issues: #2350 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 17:07:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 17:07:45 -0000 Subject: [GHC] #11739: Simplify axioms; should be applied to types In-Reply-To: <047.1dec82d6884084079fbacd762d819ea8@haskell.org> References: <047.1dec82d6884084079fbacd762d819ea8@haskell.org> Message-ID: <062.9701b3c597f3d6ce0b19a624f506252e@haskell.org> #11739: Simplify axioms; should be applied to types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by goldfire: @@ -8,1 +8,1 @@ - But the example shows that the new expressiveness is not expressive + But this example shows that the new expressiveness is not expressive @@ -10,0 +10,23 @@ + + {{{ + type family F (a :: *) (b :: *) where + F a a = Int + F a b = b + + type family Id (a :: *) where + Id a = a + + ---------------------- + + axF :: { [a::*]. F a a ~ Int + ; [a::*, b::*]. F a b ~ b } + axId :: [a::*]. Id a ~ a + + co1 = axF[1] (axId[0] ) (axId[0] ) + :: F (Id Int) (Id Bool) ~ Bool + co2 = sym (axId[0] ) + :: Bool ~ Id Bool + + co3 = co1 ; co2 :: F (Id Int) (Id Bool) ~ Id Bool + co3' = optimized co3 = axF[1] (axId[0] ) -- bogus + }}} New description: Simon PJ says: In `Note [Coercion axioms applied to coercions]` in Coercion, we find the justification for allowing coercions as arguments to axioms. The goal is to add a bit of extra expressiveness, so that optimisations can be done pair-wise. But this example shows that the new expressiveness is not expressive enough! {{{ type family F (a :: *) (b :: *) where F a a = Int F a b = b type family Id (a :: *) where Id a = a ---------------------- axF :: { [a::*]. F a a ~ Int ; [a::*, b::*]. F a b ~ b } axId :: [a::*]. Id a ~ a co1 = axF[1] (axId[0] ) (axId[0] ) :: F (Id Int) (Id Bool) ~ Bool co2 = sym (axId[0] ) :: Bool ~ Id Bool co3 = co1 ; co2 :: F (Id Int) (Id Bool) ~ Id Bool co3' = optimized co3 = axF[1] (axId[0] ) -- bogus }}} Rather than give up (as you do in !OptCoercion) maybe we should re-examine the assumption. How could we optimise if axioms could only be instantiated with types, not coercions. Which would be a LOT simpler! Let's take the example from the Note: {{{ C a : t[a] ~ F a g : b ~ c }}} and we want to optimize {{{ sym (C b) ; t[g] ; C c :: F b ~ F c }}} One possibility is to perform a 3-component optimisation, but that's a bit horrible. But what about this: push the `t[g]` ''past'' the axiom rather than ''into'' it. For example {{{ t[g] ; C c ==> C b ; F g where t[g] : t[b]~t[c] C c : t[c] ~ F c }}} If we use this to move axioms to the right, I think we'll get the same optimisations as now, but with a simpler system. Does that seem right? Now it becomes clearer that you can't always commute the things. {{{ ax : F a a ~ a; F a b ~ b co :: Id Bool ~ Bool }}} If we have {{{ (F co ; ax[1] Int Bool) : F Int (Id Bool) ~ Bool }}} then we might try to commute `co` past the axiom thus: {{{ ax[1] Int (Id Bool) ; co }}} but now (as you point out) the ax[1] is not necessarily OK. But I hazard that the lack of the commuting isn't going to lose useful optimisations. So in some ways we are no further forward (an optimisation is only sometimes OK), but I feel MUCH happier about simplifying the axiom- applied-to-coercion stuff. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 17:09:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 17:09:33 -0000 Subject: [GHC] #11739: Simplify axioms; should be applied to types In-Reply-To: <047.1dec82d6884084079fbacd762d819ea8@haskell.org> References: <047.1dec82d6884084079fbacd762d819ea8@haskell.org> Message-ID: <062.dae825ae21ef280fb7e2ee26c8a8af7a@haskell.org> #11739: Simplify axioms; should be applied to types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by goldfire: @@ -9,1 +9,2 @@ - enough! + enough, given the apartness restrictions on closed type families. (The + goal is to eliminate the call to `checkAxInstCo` in !OptCoercion.) @@ -31,1 +32,2 @@ - co3' = optimized co3 = axF[1] (axId[0] ) -- bogus + co3' = optimized co3 = axF[1] (axId[0] ) -- bogus, fails + call to checkAxInstCo New description: Simon PJ says: In `Note [Coercion axioms applied to coercions]` in Coercion, we find the justification for allowing coercions as arguments to axioms. The goal is to add a bit of extra expressiveness, so that optimisations can be done pair-wise. But this example shows that the new expressiveness is not expressive enough, given the apartness restrictions on closed type families. (The goal is to eliminate the call to `checkAxInstCo` in !OptCoercion.) {{{ type family F (a :: *) (b :: *) where F a a = Int F a b = b type family Id (a :: *) where Id a = a ---------------------- axF :: { [a::*]. F a a ~ Int ; [a::*, b::*]. F a b ~ b } axId :: [a::*]. Id a ~ a co1 = axF[1] (axId[0] ) (axId[0] ) :: F (Id Int) (Id Bool) ~ Bool co2 = sym (axId[0] ) :: Bool ~ Id Bool co3 = co1 ; co2 :: F (Id Int) (Id Bool) ~ Id Bool co3' = optimized co3 = axF[1] (axId[0] ) -- bogus, fails call to checkAxInstCo }}} Rather than give up (as you do in !OptCoercion) maybe we should re-examine the assumption. How could we optimise if axioms could only be instantiated with types, not coercions. Which would be a LOT simpler! Let's take the example from the Note: {{{ C a : t[a] ~ F a g : b ~ c }}} and we want to optimize {{{ sym (C b) ; t[g] ; C c :: F b ~ F c }}} One possibility is to perform a 3-component optimisation, but that's a bit horrible. But what about this: push the `t[g]` ''past'' the axiom rather than ''into'' it. For example {{{ t[g] ; C c ==> C b ; F g where t[g] : t[b]~t[c] C c : t[c] ~ F c }}} If we use this to move axioms to the right, I think we'll get the same optimisations as now, but with a simpler system. Does that seem right? Now it becomes clearer that you can't always commute the things. {{{ ax : F a a ~ a; F a b ~ b co :: Id Bool ~ Bool }}} If we have {{{ (F co ; ax[1] Int Bool) : F Int (Id Bool) ~ Bool }}} then we might try to commute `co` past the axiom thus: {{{ ax[1] Int (Id Bool) ; co }}} but now (as you point out) the ax[1] is not necessarily OK. But I hazard that the lack of the commuting isn't going to lose useful optimisations. So in some ways we are no further forward (an optimisation is only sometimes OK), but I feel MUCH happier about simplifying the axiom- applied-to-coercion stuff. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 17:11:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 17:11:17 -0000 Subject: [GHC] #11739: Simplify axioms; should be applied to types In-Reply-To: <047.1dec82d6884084079fbacd762d819ea8@haskell.org> References: <047.1dec82d6884084079fbacd762d819ea8@haskell.org> Message-ID: <062.389dd7f35ae2469c9fabaa5c726525b2@haskell.org> #11739: Simplify axioms; should be applied to types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by goldfire: @@ -35,0 +35,5 @@ + + This last `co3'` is what would be produced if we didn't run + `checkAxInstCo`. But, as the comment says, it runs afoul of the apartness + condition (as checked by `checkAxInstCo`). Currently, !OptCoercion just + gives up in this case, retaining the original `co3`. New description: Simon PJ says: In `Note [Coercion axioms applied to coercions]` in Coercion, we find the justification for allowing coercions as arguments to axioms. The goal is to add a bit of extra expressiveness, so that optimisations can be done pair-wise. But this example shows that the new expressiveness is not expressive enough, given the apartness restrictions on closed type families. (The goal is to eliminate the call to `checkAxInstCo` in !OptCoercion.) {{{ type family F (a :: *) (b :: *) where F a a = Int F a b = b type family Id (a :: *) where Id a = a ---------------------- axF :: { [a::*]. F a a ~ Int ; [a::*, b::*]. F a b ~ b } axId :: [a::*]. Id a ~ a co1 = axF[1] (axId[0] ) (axId[0] ) :: F (Id Int) (Id Bool) ~ Bool co2 = sym (axId[0] ) :: Bool ~ Id Bool co3 = co1 ; co2 :: F (Id Int) (Id Bool) ~ Id Bool co3' = optimized co3 = axF[1] (axId[0] ) -- bogus, fails call to checkAxInstCo }}} This last `co3'` is what would be produced if we didn't run `checkAxInstCo`. But, as the comment says, it runs afoul of the apartness condition (as checked by `checkAxInstCo`). Currently, !OptCoercion just gives up in this case, retaining the original `co3`. Rather than give up (as you do in !OptCoercion) maybe we should re-examine the assumption. How could we optimise if axioms could only be instantiated with types, not coercions. Which would be a LOT simpler! Let's take the example from the Note: {{{ C a : t[a] ~ F a g : b ~ c }}} and we want to optimize {{{ sym (C b) ; t[g] ; C c :: F b ~ F c }}} One possibility is to perform a 3-component optimisation, but that's a bit horrible. But what about this: push the `t[g]` ''past'' the axiom rather than ''into'' it. For example {{{ t[g] ; C c ==> C b ; F g where t[g] : t[b]~t[c] C c : t[c] ~ F c }}} If we use this to move axioms to the right, I think we'll get the same optimisations as now, but with a simpler system. Does that seem right? Now it becomes clearer that you can't always commute the things. {{{ ax : F a a ~ a; F a b ~ b co :: Id Bool ~ Bool }}} If we have {{{ (F co ; ax[1] Int Bool) : F Int (Id Bool) ~ Bool }}} then we might try to commute `co` past the axiom thus: {{{ ax[1] Int (Id Bool) ; co }}} but now (as you point out) the ax[1] is not necessarily OK. But I hazard that the lack of the commuting isn't going to lose useful optimisations. So in some ways we are no further forward (an optimisation is only sometimes OK), but I feel MUCH happier about simplifying the axiom- applied-to-coercion stuff. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 17:13:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 17:13:12 -0000 Subject: [GHC] #11739: Simplify axioms; should be applied to types In-Reply-To: <047.1dec82d6884084079fbacd762d819ea8@haskell.org> References: <047.1dec82d6884084079fbacd762d819ea8@haskell.org> Message-ID: <062.974c94503a33fd9d72b5029dbae16710@haskell.org> #11739: Simplify axioms; should be applied to types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -91,2 +91,3 @@ - but now (as you point out) the ax[1] is not necessarily OK. But I hazard - that the lack of the commuting isn't going to lose useful optimisations. + but now (as you point out) the `ax[1]` is not necessarily OK. But I + hazard that the lack of the commuting isn't going to lose useful + optimisations. New description: Simon PJ says: In `Note [Coercion axioms applied to coercions]` in Coercion, we find the justification for allowing coercions as arguments to axioms. The goal is to add a bit of extra expressiveness, so that optimisations can be done pair-wise. But this example shows that the new expressiveness is not expressive enough, given the apartness restrictions on closed type families. (The goal is to eliminate the call to `checkAxInstCo` in !OptCoercion.) {{{ type family F (a :: *) (b :: *) where F a a = Int F a b = b type family Id (a :: *) where Id a = a ---------------------- axF :: { [a::*]. F a a ~ Int ; [a::*, b::*]. F a b ~ b } axId :: [a::*]. Id a ~ a co1 = axF[1] (axId[0] ) (axId[0] ) :: F (Id Int) (Id Bool) ~ Bool co2 = sym (axId[0] ) :: Bool ~ Id Bool co3 = co1 ; co2 :: F (Id Int) (Id Bool) ~ Id Bool co3' = optimized co3 = axF[1] (axId[0] ) -- bogus, fails call to checkAxInstCo }}} This last `co3'` is what would be produced if we didn't run `checkAxInstCo`. But, as the comment says, it runs afoul of the apartness condition (as checked by `checkAxInstCo`). Currently, !OptCoercion just gives up in this case, retaining the original `co3`. Rather than give up (as you do in !OptCoercion) maybe we should re-examine the assumption. How could we optimise if axioms could only be instantiated with types, not coercions. Which would be a LOT simpler! Let's take the example from the Note: {{{ C a : t[a] ~ F a g : b ~ c }}} and we want to optimize {{{ sym (C b) ; t[g] ; C c :: F b ~ F c }}} One possibility is to perform a 3-component optimisation, but that's a bit horrible. But what about this: push the `t[g]` ''past'' the axiom rather than ''into'' it. For example {{{ t[g] ; C c ==> C b ; F g where t[g] : t[b]~t[c] C c : t[c] ~ F c }}} If we use this to move axioms to the right, I think we'll get the same optimisations as now, but with a simpler system. Does that seem right? Now it becomes clearer that you can't always commute the things. {{{ ax : F a a ~ a; F a b ~ b co :: Id Bool ~ Bool }}} If we have {{{ (F co ; ax[1] Int Bool) : F Int (Id Bool) ~ Bool }}} then we might try to commute `co` past the axiom thus: {{{ ax[1] Int (Id Bool) ; co }}} but now (as you point out) the `ax[1]` is not necessarily OK. But I hazard that the lack of the commuting isn't going to lose useful optimisations. So in some ways we are no further forward (an optimisation is only sometimes OK), but I feel MUCH happier about simplifying the axiom- applied-to-coercion stuff. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 17:17:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 17:17:12 -0000 Subject: [GHC] #11739: Simplify axioms; should be applied to types In-Reply-To: <047.1dec82d6884084079fbacd762d819ea8@haskell.org> References: <047.1dec82d6884084079fbacd762d819ea8@haskell.org> Message-ID: <062.207e0074f88653f525062859b1db418b@haskell.org> #11739: Simplify axioms; should be applied to types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -91,3 +91,3 @@ - but now (as you point out) the `ax[1]` is not necessarily OK. But I - hazard that the lack of the commuting isn't going to lose useful - optimisations. + but now (as you point out) the `ax[1]` is not necessarily OK; so we still + need to use `checkAxInstCo`. But I hazard that the lack of the commuting + isn't going to lose useful optimisations. New description: Simon PJ says: In `Note [Coercion axioms applied to coercions]` in Coercion, we find the justification for allowing coercions as arguments to axioms. The goal is to add a bit of extra expressiveness, so that optimisations can be done pair-wise. But this example shows that the new expressiveness is not expressive enough, given the apartness restrictions on closed type families. (The goal is to eliminate the call to `checkAxInstCo` in !OptCoercion.) {{{ type family F (a :: *) (b :: *) where F a a = Int F a b = b type family Id (a :: *) where Id a = a ---------------------- axF :: { [a::*]. F a a ~ Int ; [a::*, b::*]. F a b ~ b } axId :: [a::*]. Id a ~ a co1 = axF[1] (axId[0] ) (axId[0] ) :: F (Id Int) (Id Bool) ~ Bool co2 = sym (axId[0] ) :: Bool ~ Id Bool co3 = co1 ; co2 :: F (Id Int) (Id Bool) ~ Id Bool co3' = optimized co3 = axF[1] (axId[0] ) -- bogus, fails call to checkAxInstCo }}} This last `co3'` is what would be produced if we didn't run `checkAxInstCo`. But, as the comment says, it runs afoul of the apartness condition (as checked by `checkAxInstCo`). Currently, !OptCoercion just gives up in this case, retaining the original `co3`. Rather than give up (as you do in !OptCoercion) maybe we should re-examine the assumption. How could we optimise if axioms could only be instantiated with types, not coercions. Which would be a LOT simpler! Let's take the example from the Note: {{{ C a : t[a] ~ F a g : b ~ c }}} and we want to optimize {{{ sym (C b) ; t[g] ; C c :: F b ~ F c }}} One possibility is to perform a 3-component optimisation, but that's a bit horrible. But what about this: push the `t[g]` ''past'' the axiom rather than ''into'' it. For example {{{ t[g] ; C c ==> C b ; F g where t[g] : t[b]~t[c] C c : t[c] ~ F c }}} If we use this to move axioms to the right, I think we'll get the same optimisations as now, but with a simpler system. Does that seem right? Now it becomes clearer that you can't always commute the things. {{{ ax : F a a ~ a; F a b ~ b co :: Id Bool ~ Bool }}} If we have {{{ (F co ; ax[1] Int Bool) : F Int (Id Bool) ~ Bool }}} then we might try to commute `co` past the axiom thus: {{{ ax[1] Int (Id Bool) ; co }}} but now (as you point out) the `ax[1]` is not necessarily OK; so we still need to use `checkAxInstCo`. But I hazard that the lack of the commuting isn't going to lose useful optimisations. So in some ways we are no further forward (an optimisation is only sometimes OK), but I feel MUCH happier about simplifying the axiom- applied-to-coercion stuff. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 17:29:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 17:29:29 -0000 Subject: [GHC] #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm In-Reply-To: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> References: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> Message-ID: <060.ae7f107ec1c14a221f13d9373fe6d930@haskell.org> #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T3220, | indexed- | types/should_compile/ColInference3 Blocked By: | Blocking: Related Tickets: #11371, #11643 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"cb08f8da37ff5fb99e1d02b8afdcb802d23e9a8d/ghc" cb08f8da/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cb08f8da37ff5fb99e1d02b8afdcb802d23e9a8d" Tidy up handling of coercion variables * Comments to explain that a CoVar, whose IdInfo is CoVarId, is always unlifted (but may be nominal or representational role) And TyCoRep.isCoercionType picks out only those unlifted types, NOT the lifted versions * Introduce Var.NcId for non-co-var Ids with predicate isNonCoVarId * Add assertions in CoreSubst that the Id env is only used for NcIds * Fix lurking bug in CSE which extended the CoreSubst Id env with a CoVar * Fix two bugs in Specialise.spec_call, which wrongly treated CoVars like NcIds - needed a varToCoreExpr in one place - needed extendSubst not extendIdSubst in another This was the root cause of Trac #11644 Minor refactoring * Eliminate unused mkDerivedLocalCoVarM, mkUserLocalCoVar * Small refactor in mkSysLocalOrCoVar }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 17:30:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 17:30:58 -0000 Subject: [GHC] #11720: pureMD5: Simplifier ticks exhausted In-Reply-To: <047.b040aecf5498d7034551332304a09b9c@haskell.org> References: <047.b040aecf5498d7034551332304a09b9c@haskell.org> Message-ID: <062.e63829234ef244470958d42bf1c3803e@haskell.org> #11720: pureMD5: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10852 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #10852 Comment: This is a duplicate of #10852, where I believe we determined that `cereal` is at fault, requesting that we inline positively huge amounts of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 17:31:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 17:31:06 -0000 Subject: [GHC] #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm In-Reply-To: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> References: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> Message-ID: <060.49dfdfc50c3b7296aabceb6080599536@haskell.org> #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T11644, | indexed- | types/should_compile/ColInference3 Blocked By: | Blocking: Related Tickets: #11371, #11643 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: indexed-types/should_compile/T3220, indexed- types/should_compile/ColInference3 => simplCore/should_compile/T11644, indexed- types/should_compile/ColInference3 * status: new => merge Comment: Pls merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 18:03:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 18:03:00 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.9ba401d6bc0c842110b788ac98b6ff61@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D669, Wiki Page: | Phab:D2027 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 18:21:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 18:21:51 -0000 Subject: [GHC] #2350: hSetEcho: failed (failed to set echoing) on Windows In-Reply-To: <046.f635148d87eda19915274a731d766966@haskell.org> References: <046.f635148d87eda19915274a731d766966@haskell.org> Message-ID: <061.5d2ff864c0b6180efbb84ac2a54cfc16@haskell.org> #2350: hSetEcho: failed (failed to set echoing) on Windows -------------------------------------+------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: => None/Unknown Comment: The commit message in comment:4 was obviously supposed to refer to #2530. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 18:41:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 18:41:00 -0000 Subject: [GHC] #485: AdjustorAsm.S doesn't build on AIX In-Reply-To: <047.348c1b9e6ebc7759d7861925cfd6ccd1@haskell.org> References: <047.348c1b9e6ebc7759d7861925cfd6ccd1@haskell.org> Message-ID: <062.1530d7fa97c156f194d61d134379e3c8@haskell.org> #485: AdjustorAsm.S doesn't build on AIX -------------------------------------+------------------------------------- Reporter: jgoerzen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Operating System: AIX | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2029 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: closed => new * priority: low => normal * cc: simonmar (added) * differential: => phab:D2029 * component: Compiler => Runtime System * testcase: N/A => * failure: None/Unknown => Building GHC failed * milestone: ? => 8.0.1 * resolution: wontfix => Comment: I'm a bit confused about the comment about `rts/AdjustorAsm.S` not existing anymore, as it does still exist... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 18:41:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 18:41:14 -0000 Subject: [GHC] #485: AdjustorAsm.S doesn't build on AIX In-Reply-To: <047.348c1b9e6ebc7759d7861925cfd6ccd1@haskell.org> References: <047.348c1b9e6ebc7759d7861925cfd6ccd1@haskell.org> Message-ID: <062.fb4a2e0e0f6702082bbc814e4be01ad8@haskell.org> #485: AdjustorAsm.S doesn't build on AIX -------------------------------------+------------------------------------- Reporter: jgoerzen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Operating System: AIX | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2029 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 19:41:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 19:41:49 -0000 Subject: [GHC] #485: AdjustorAsm.S doesn't build on AIX In-Reply-To: <047.348c1b9e6ebc7759d7861925cfd6ccd1@haskell.org> References: <047.348c1b9e6ebc7759d7861925cfd6ccd1@haskell.org> Message-ID: <062.462a4af073c98a05dfd3d6cf1fd96cc2@haskell.org> #485: AdjustorAsm.S doesn't build on AIX -------------------------------------+------------------------------------- Reporter: jgoerzen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Operating System: AIX | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2029 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"343349df1f19f21899818d647bf570e489d0cf8f/ghc" 343349d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="343349df1f19f21899818d647bf570e489d0cf8f" Avoid local label syntax for assembler on AIX Unfortunately (for inline `__asm__()` uses), IBM's `as` doesn't seem to support local labels[1] like GNU `as` does so we need to workaround this when on AIX. [1]: https://sourceware.org/binutils/docs/as/Symbol-Names.html#Symbol- Names Turns out this also addresses the long-standing bug #485 Reviewed By: bgamari, trommler Differential Revision: https://phabricator.haskell.org/D2029 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 19:43:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 19:43:41 -0000 Subject: [GHC] #11108: Weak references related crash In-Reply-To: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> References: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> Message-ID: <061.35d19e931bbd5375a613d31f5dcc74f2@haskell.org> #11108: Weak references related crash -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: jme Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11746 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jme): * owner: => jme * related: => #11746 Comment: I'll give this one a shot. It looks like the weak pointer is ending up in an older generation than its key. The key gets GCed during a minor collection, but the weak pointer is not "tidied" until the next major collection. At that point, its pointer to the key is no longer valid. This appears to be the same issue as #11746. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 19:43:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 19:43:55 -0000 Subject: [GHC] #11746: I encountered an: internal error: evacuate: strange closure type 803645000 In-Reply-To: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> References: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> Message-ID: <059.753e9aa8d3a266330f4e42bdb5112bc4@haskell.org> #11746: I encountered an: internal error: evacuate: strange closure type 803645000 -------------------------------+-------------------------------------- Reporter: hkBst | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #11108 | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by jme): * related: => #11108 Comment: This appears to be the same issue as #11108. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 20:13:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 20:13:34 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.284e983c418d15a5a6566fda24e22491@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: Resolution: | Keywords: thread-local | state, TLS clang Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: 7678 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Any update on this? In the original bug entry Simon Marlow suggests: A workaround is to install a real gcc (using homebrew?) and use that to compile GHC. Whoever builds the GHC distributions for OS X should probably do it that way, so everyone benefits. Are we doing that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 20:32:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 20:32:19 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.e40f3cb3fd366da51507293987168413@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by hvr): I was told there might be a `nm-classic(1)` tool provided by Xcode 7.3; can somebody verify if it's there, and if we can pass that one to `./configure --with-nm=...` to workaround this issue temporarily? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 21:16:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 21:16:55 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.fbf254436cb61b55500a03da5f495218@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1961 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` in 371608f1cdaf20c49eb6c5ec165b9eb08b745a89. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 21:17:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 21:17:48 -0000 Subject: [GHC] #485: AdjustorAsm.S doesn't build on AIX In-Reply-To: <047.348c1b9e6ebc7759d7861925cfd6ccd1@haskell.org> References: <047.348c1b9e6ebc7759d7861925cfd6ccd1@haskell.org> Message-ID: <062.bb5b3e04cfb7ef92a355c1d4bf083a1d@haskell.org> #485: AdjustorAsm.S doesn't build on AIX -------------------------------------+------------------------------------- Reporter: jgoerzen | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Operating System: AIX | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2029 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 21:18:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 21:18:14 -0000 Subject: [GHC] #11580: panic on incompatible options In-Reply-To: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> References: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> Message-ID: <059.8186d89fcbd69871176d4c61be319f20@haskell.org> #11580: panic on incompatible options -------------------------------------+------------------------------------- Reporter: dougm | Owner: kaiha Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1925 Wiki Page: | Phab:D2013 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 21:19:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 21:19:23 -0000 Subject: [GHC] #11580: panic on incompatible options In-Reply-To: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> References: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> Message-ID: <059.b5eb7fce2c5895525a6a52c352e3bc7c@haskell.org> #11580: panic on incompatible options -------------------------------------+------------------------------------- Reporter: dougm | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1925 Wiki Page: | Phab:D2013 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: kaiha => * status: closed => new * resolution: fixed => Comment: Merged to `ghc-8.0` as 552df38b6ab5f397817d5c8eaf787f1ea304c19a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 22:01:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 22:01:35 -0000 Subject: [GHC] #485: AdjustorAsm.S doesn't build on AIX In-Reply-To: <047.348c1b9e6ebc7759d7861925cfd6ccd1@haskell.org> References: <047.348c1b9e6ebc7759d7861925cfd6ccd1@haskell.org> Message-ID: <062.38bef6857c14f60ac416c73b32a07a53@haskell.org> #485: AdjustorAsm.S doesn't build on AIX -------------------------------------+------------------------------------- Reporter: jgoerzen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: AIX | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2029 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as ade015c7ff269a3947dd414143048f638be0ff46. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 22:05:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 22:05:01 -0000 Subject: [GHC] #11667: Incorrect pattern synonym types in error messages In-Reply-To: <046.01f7d6134e84da2cd298573ade0572c4@haskell.org> References: <046.01f7d6134e84da2cd298573ade0572c4@haskell.org> Message-ID: <061.34045112eb5964f71c7b470a1df6d595@haskell.org> #11667: Incorrect pattern synonym types in error messages -------------------------------------+------------------------------------- Reporter: rdragon | Owner: rdragon Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11213 | Differential Rev(s): Phab:D1967 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.0` as 13a54bc3526df1f13c717ec80456743d9bbe6656. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 22:07:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 22:07:03 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.6431e467d3a57365abd59bb62462a918@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D669, Wiki Page: | Phab:D2027 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 061669156c0e24a550dc968e5d6c7f1e5e518505. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 22:08:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 22:08:32 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.add081b307cbfd453f460895c809c11a@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => upstream * milestone: => 8.0.1 Comment: Merged to `ghc-8.0` as ed3398d176fc777dff8f5ae5315425e40c705c2d. I have a `bytestring` branch updating the rewrite rules which I now need to upstream. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 22:09:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 22:09:04 -0000 Subject: [GHC] #11580: panic on incompatible options In-Reply-To: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> References: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> Message-ID: <059.5ffa5f44f9dbadab46f071ab96f8c39b@haskell.org> #11580: panic on incompatible options -------------------------------------+------------------------------------- Reporter: dougm | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1925 Wiki Page: | Phab:D2013 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 22:12:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 22:12:56 -0000 Subject: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC In-Reply-To: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> References: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> Message-ID: <059.d8e31d1e3c49d157d4b984d7cf06ffca@haskell.org> #4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: kaiha Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2258 | Differential Rev(s): Phab:D2021 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"24149528a0a2d17ff9b5b087e0a8249c8c9cef98/ghc" 24149528/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="24149528a0a2d17ff9b5b087e0a8249c8c9cef98" Add option `no-keep-hi-files` and `no-keep-o-files` (fixes #4114) Summary: Remove `.hi` and `.o` files if the flags `no-keep-hi-files` and `no-keep-o-files` are given. Test Plan: ./validate Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2021 GHC Trac Issues: #4114 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 22:12:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 22:12:56 -0000 Subject: [GHC] #11741: -Wredundant-constraints is not in the manual's flag reference In-Reply-To: <047.f9b39d0f99f8346da2ca26cd49cc61f2@haskell.org> References: <047.f9b39d0f99f8346da2ca26cd49cc61f2@haskell.org> Message-ID: <062.757a8e7c46e5807eb569c61f29cd28d8@haskell.org> #11741: -Wredundant-constraints is not in the manual's flag reference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2035 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8ff6518b5af1b357eb043ac46f9209bd0019a193/ghc" 8ff6518b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8ff6518b5af1b357eb043ac46f9209bd0019a193" users-guide: Add -Wredundant-constraints to flags reference Test Plan: Validate and read Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2035 GHC Trac Issues: #11741 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 22:22:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 22:22:56 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.cc4c42f14c0d685f6ff31b9da3461726@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've opened [[https://github.com/haskell/bytestring/pull/71/files|bytestring #71]] for the rewrite rule fixes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 22:24:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 22:24:43 -0000 Subject: [GHC] #11741: -Wredundant-constraints is not in the manual's flag reference In-Reply-To: <047.f9b39d0f99f8346da2ca26cd49cc61f2@haskell.org> References: <047.f9b39d0f99f8346da2ca26cd49cc61f2@haskell.org> Message-ID: <062.d61ba3ed1654ba4d5daea67c84aa401a@haskell.org> #11741: -Wredundant-constraints is not in the manual's flag reference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2035 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Pushed to `ghc-8.0` as abca1519926aa1a2c62d929a95a723037ebfe517. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 22:34:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 22:34:26 -0000 Subject: [GHC] #11736: Allow unsaturated uses of unlifted types in Core In-Reply-To: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> References: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> Message-ID: <061.9b4a641f07a8b4d3c3390e05083906ac@haskell.org> #11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: sweirich@?, dimitris (added) Comment: The issue with un-saturated type function is to do with abstraction. What if you had {{{ (/\(a:: * -> *). blah) F }}} where `F` is a type function. Well bad things, if you can decompose applications of `a` in `blah`. I think that's the only thing that can go wrong with un-saturated unlifted type constructors. What if we said {{{ (/\(a :: * -> *). blah) Array# }}} Would that be OK? Well, no: `Array# Int` is an unlifted type, not `*`. So it's ill-kinded. But I think this would be fine {{{ (/\(a :: TYPE 'PtrRepLifted -> TYPE 'PtrRepUnlifted). blah) Array# }}} Inside `blah` a variable `x :: a Int` would be an unlifted type, evaluated call-by-value, just as it should. Moreover stranger things like {{{ (/\(a :: Type 'PtrRepLifted -> TYPE 'VoidRep). blah) State# }}} Now inside blah a variable `x :: a Int` would be an unboxed zero-width void thing. Just right. In short I think this is absolutely fine. We don't even need to do anything! (I vote for the above patch.) All we need is someone to come up with a proper account of runtime-rep polymorphism. Kenny? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 23:43:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 23:43:18 -0000 Subject: [GHC] #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm In-Reply-To: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> References: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> Message-ID: <060.ca339993d76eb7a9f609aa370dc383de@haskell.org> #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | simplCore/should_compile/T11644, | indexed- | types/should_compile/ColInference3 Blocked By: | Blocking: Related Tickets: #11371, #11643 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * failure: None/Unknown => Compile-time crash * resolution: => fixed @@ -2,1 +2,1 @@ - {{{ + {{{#!hs New description: This is the code: {{{#!hs {-# LANGUAGE TypeFamilies, ScopedTypeVariables#-} module T3220 where class Foo m where type Bar m :: * action :: m -> Bar m -> m right x m = action m (Right x) right' :: (Either a b ~ Bar m, Foo m) => b -> m -> m right' x m = action m (Right x) instance Foo Int where type Bar Int = Either Int Int action m a = either (*) (+) a m instance Foo Float where type Bar Float = Either Float Float action m a = either (*) (+) a m foo = print $ right (1::Int) (3 :: Int) bar = print $ right (1::Float) (3 :: Float) }}} Invocation: {{{ $ ghc-8.0.1 T3220.hs -O -dcore-lint }}} {{{ [1 of 1] Compiling T3220 ( T3220.hs, T3220.o ) *** Core Lint errors : in result of Specialise *** : warning: In the expression: action @ Float $fFooFloat m_ayb ((Right @ Float @ Float x_aya) `cast` (Sub (Sym cobox_aUe) :: Either a_aU3 b_aU4 ~R# Bar m_aU1)) cobox_aUe :: Bar m_aU1 ~# Either a_aU3 b_aU4 [LclId[CoVarId], Str=DmdType] is out of scope }}} Interestingly, with HEAD (2aee41960aa00fe09a2cd1983e02c15e06013037), it hits an assert from #11371. {{{ =====> T3220(profasm) 12 of 21 [0, 11, 0] cd ./indexed-types/should_compile && "/home/thomas/ghc- validate/inplace/test spaces/ghc-stage2" -c T3220.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history -O -prof -static -auto-all > T3220.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160221 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1942:51 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2076:17 in ghc:TyCoRep substCo, called at compiler/coreSyn/CoreSubst.hs:605:20 in ghc:CoreSubst in_scope InScope {x_axS m_axT $caction_a1dp $caction_a1dR right right' foo bar $tcFoo $tc'C:Foo $fFooFloat $fFooInt $trModule a_s1fZ a_s1g0 a_s1g1 a_s1g2} tenv [aTT :-> Float, aTV :-> Float, aTW :-> Float] cenv [] tys [] cos [Sub (Sym cobox_aU6)] needInScope [aU6 :-> cobox_aU6] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is a regression from 7.10.3. Setting priority=highest. -- Comment: Merged to `ghc-8.0` as c12ae2f986d4cd59e38752da7fd7b597d6ba903e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 24 23:44:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Mar 2016 23:44:06 -0000 Subject: [GHC] #11667: Incorrect pattern synonym types in error messages In-Reply-To: <046.01f7d6134e84da2cd298573ade0572c4@haskell.org> References: <046.01f7d6134e84da2cd298573ade0572c4@haskell.org> Message-ID: <061.eaf12f620232bae9c0ce6559a1d8e603@haskell.org> #11667: Incorrect pattern synonym types in error messages -------------------------------------+------------------------------------- Reporter: rdragon | Owner: rdragon Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11213 | Differential Rev(s): Phab:D1967 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 00:20:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 00:20:16 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2311750=3A_32_bit_CPUs=3A_Couldn=27t_match_?= =?utf-8?q?expected_type_=E2=80=98Word=23=E2=80=99_with_actual_ty?= =?utf-8?b?cGUg4oCYV29yZDY0I+KAmQ==?= Message-ID: <044.b6ecdb23aa4eae2e442be684f61fe72c@haskell.org> #11750: 32 bit CPUs: Couldn't match expected type ?Word#? with actual type ?Word64#? -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Getting this on PowerPC and Arm: {{{ libraries/base/GHC/Word.hs:605:39: error: ? Couldn't match expected type ?Word#? with actual type ?Word64#? ? In the first argument of ?eqWord#?, namely ?x? In the first argument of ?isTrue#?, namely ?(x `eqWord#` y)? In the expression: isTrue# (x `eqWord#` y) libraries/base/GHC/Word.hs:605:51: error: ? Couldn't match expected type ?Word#? with actual type ?Word64#? ? In the second argument of ?eqWord#?, namely ?y? In the first argument of ?isTrue#?, namely ?(x `eqWord#` y)? In the expression: isTrue# (x `eqWord#` y) libraries/base/GHC/Word.hs:606:39: error: ? Couldn't match expected type ?Word#? with actual type ?Word64#? ? In the first argument of ?neWord#?, namely ?x? In the first argument of ?isTrue#?, namely ?(x `neWord#` y)? In the expression: isTrue# (x `neWord#` y) libraries/base/GHC/Word.hs:606:51: error: ? Couldn't match expected type ?Word#? with actual type ?Word64#? ? In the second argument of ?neWord#?, namely ?y? In the first argument of ?isTrue#?, namely ?(x `neWord#` y)? In the expression: isTrue# (x `neWord#` y) }}} Same happens for `Int64` in `GHC/Int.hs`. Patch on the way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 00:28:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 00:28:40 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.e45685a80a12dd423de985cc636ef0e4@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"26f86f3d397159f9c0db0b59766138f553ba5a86/ghc" 26f86f3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="26f86f3d397159f9c0db0b59766138f553ba5a86" base: Fix GHC.Word and GHC.Int on 32-bit platforms Due to a cut-and-paste error D1980 (#11688) broke 32-bit platforms. This should fix it. See #11750. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 00:28:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 00:28:40 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311750=3A_32_bit_CPUs=3A_Couldn=27t_?= =?utf-8?q?match_expected_type_=E2=80=98Word=23=E2=80=99_with_act?= =?utf-8?b?dWFsIHR5cGUg4oCYV29yZDY0I+KAmQ==?= In-Reply-To: <044.b6ecdb23aa4eae2e442be684f61fe72c@haskell.org> References: <044.b6ecdb23aa4eae2e442be684f61fe72c@haskell.org> Message-ID: <059.95f31d1a813aeb0d51afc50f53976e12@haskell.org> #11750: 32 bit CPUs: Couldn't match expected type ?Word#? with actual type ?Word64#? -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"26f86f3d397159f9c0db0b59766138f553ba5a86/ghc" 26f86f3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="26f86f3d397159f9c0db0b59766138f553ba5a86" base: Fix GHC.Word and GHC.Int on 32-bit platforms Due to a cut-and-paste error D1980 (#11688) broke 32-bit platforms. This should fix it. See #11750. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 00:30:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 00:30:18 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311750=3A_32_bit_CPUs=3A_Couldn=27t_?= =?utf-8?q?match_expected_type_=E2=80=98Word=23=E2=80=99_with_act?= =?utf-8?b?dWFsIHR5cGUg4oCYV29yZDY0I+KAmQ==?= In-Reply-To: <044.b6ecdb23aa4eae2e442be684f61fe72c@haskell.org> References: <044.b6ecdb23aa4eae2e442be684f61fe72c@haskell.org> Message-ID: <059.2478b32e06f9b6e1b943c7356127de22@haskell.org> #11750: 32 bit CPUs: Couldn't match expected type ?Word#? with actual type ?Word64#? -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 01:23:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 01:23:42 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.3997f6b73a26ac129a5bc34ff26c78e1@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another troubling aspect of this that I discovered recently: GHC appears to quantify type variables in typeclass methods differently now. Compare this (GHC 7.10.3): {{{ $ /opt/ghc/7.10.3/bin/ghci -fprint-explicit-foralls GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help ?> import GHC.Generics ?> :t datatypeName datatypeName :: forall d (t :: * -> (* -> *) -> * -> *) (f :: * -> *) a. Datatype d => t d f a -> [Char] }}} to this (GHC 8.0): {{{ $ /opt/ghc/8.0.1/bin/ghci -fprint-explicit-foralls GHCi, version 8.0.0.20160323: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci ?> import GHC.Generics ?> :t datatypeName datatypeName :: forall {k} (d :: k). Datatype d => forall {k1} (t :: k -> (* -> *) -> k1 -> *) (f :: * -> *) (a :: k1). t d f a -> [Char] }}} I'm not sure what's going on with the GHC 8.0-reported type signature at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 04:31:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 04:31:47 -0000 Subject: [GHC] #11751: Parse error with case in where Message-ID: <046.54234b52b76451ad86fb8ff46ac451f1@haskell.org> #11751: Parse error with case in where ----------------------------------------+--------------------------------- Reporter: samuela | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The following code produces a peculiar parse error: {{{#!hs subtype = 0 where (x, y) = case (1, 2) of (a, b) -> (3, 4) }}} `parse_error.hs:3:5: parse error on input ?(?` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 04:49:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 04:49:14 -0000 Subject: [GHC] #11752: ghc-8.0 branch fails to build with ghc-7.8 Message-ID: <044.569a3c8bd55efd2c4fb3e3e9e7f60df6@haskell.org> #11752: ghc-8.0 branch fails to build with ghc-7.8 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Problems with `getAllocationCounter` not being available in 7.8's `GHC.Conc` and ghc-7.8 not having `pure` in the prelude. Patch attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 04:49:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 04:49:29 -0000 Subject: [GHC] #11752: ghc-8.0 branch fails to build with ghc-7.8 In-Reply-To: <044.569a3c8bd55efd2c4fb3e3e9e7f60df6@haskell.org> References: <044.569a3c8bd55efd2c4fb3e3e9e7f60df6@haskell.org> Message-ID: <059.c6b4011284b1f42044d2a48a3613e844@haskell.org> #11752: ghc-8.0 branch fails to build with ghc-7.8 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * Attachment "0001-Make-it-compile-with-ghc-7.8.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 04:49:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 04:49:48 -0000 Subject: [GHC] #11752: ghc-8.0 branch fails to build with ghc-7.8 In-Reply-To: <044.569a3c8bd55efd2c4fb3e3e9e7f60df6@haskell.org> References: <044.569a3c8bd55efd2c4fb3e3e9e7f60df6@haskell.org> Message-ID: <059.faa9140ea92a7feeb505c2fd3ce5465e@haskell.org> #11752: ghc-8.0 branch fails to build with ghc-7.8 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 05:54:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 05:54:18 -0000 Subject: [GHC] #11184: panic tcMonoExpr _ with bad indentation in TH code In-Reply-To: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> References: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> Message-ID: <066.22ac98a6ddf0dcf9710eac2e3a3cf8d3@haskell.org> #11184: panic tcMonoExpr _ with bad indentation in TH code -------------------------------------+------------------------------------- Reporter: TeroLaitinen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): Perhaps this is worth another bug report, but here's another case: {{{ {-# LANGUAGE TemplateHaskell #-} -- A realistic example, demonstrating how this can be baffling in real code. $(mapM (n -> [d| foo = n |]) [1]) -- Minimal example $((x -> x)) }}} causes {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): tcMonoExpr _ }}} Similarly, this is likely due to expressions and patterns sharing parsing. We just need to do the same checks that are applied to normal user code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 06:50:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 06:50:33 -0000 Subject: [GHC] #11532: ghc: panic! occured In-Reply-To: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> References: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> Message-ID: <060.71ff9184c5a1f96bc8a365cbff186e73@haskell.org> #11532: ghc: panic! occured -------------------------------------+------------------------------------- Reporter: cutsea | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cutsea): Hi all. This is news. I succeed to compile this package without a panic. I guess this panic is due to usable disk space of file system. regards. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 08:27:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 08:27:20 -0000 Subject: [GHC] #11753: Type hole(?) causes compiler failure Message-ID: <043.7a81c953d83c393090e34705d60ba9ba@haskell.org> #11753: Type hole(?) causes compiler failure -------------------------------------+------------------------------------- Reporter: akfp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried to understand soem Servant code, and added {{{#!hs bodyCheck :: _ }}} To the following code {{{#!hs -# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeSynonymInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} module Servant.Files ( FilesTmp , FilesMem , MultiPartData , MultiPartDataT , Tmp , Mem ) where import Control.Monad.Trans.Resource import Data.ByteString.Lazy (ByteString) import Network.Wai.Parse import Servant import Servant.Server.Internal -- Backends for file upload: in memory or in /tmp ? data Mem data Tmp class KnownBackend b where type Storage b :: * withBackend :: Proxy b -> (BackEnd (Storage b) -> IO r) -> IO r instance KnownBackend Mem where type Storage Mem = ByteString withBackend Proxy f = f lbsBackEnd instance KnownBackend Tmp where type Storage Tmp = FilePath withBackend Proxy f = runResourceT . withInternalState $ \s -> f (tempFileBackEnd s) -- * Files combinator, to get all of the uploaded files data Files b type MultiPartData b = ([Param], [File (Storage b)]) type MultiPartDataT b = ((MultiPartData b -> IO (MultiPartData b)) -> IO (MultiPartData b)) type FilesMem = Files Mem type FilesTmp = Files Tmp instance (KnownBackend b, HasServer sublayout config) => HasServer (Files b :> sublayout) config where type ServerT (Files b :> sublayout) m = MultiPartDataT b -> ServerT sublayout m route Proxy config subserver = WithRequest $ \request -> route (Proxy :: Proxy sublayout) config (addBodyCheck subserver (bodyCheck request)) where bodyCheck :: _ bodyCheck request = return $ Route (\f -> withBackend (Proxy :: Proxy b) $ \pb -> parseRequestBody pb request >>= f ) }}} Output: {{{ > :load src/Servant/Test.hs [1 of 1] Compiling Servant.Files ( src/Servant/Test.hs, interpreted ) src/Servant/Test.hs:59:59: Couldn't match type ?r? with ?([Param], [File (Storage b)])? because type variable ?b? would escape its scope This (rigid, skolem) type variable is bound by the instance declaration at src/Servant/Test.hs:(53,10)-(54,80) Expected type: Delayed (((([Param], [File (Storage b)]) -> IO r) -> IO r) -> Server sublayout) Actual type: Delayed (Server (Files b :> sublayout)) Relevant bindings include bodyCheck :: Network.Wai.Internal.Request -> m (RouteResult ((([Param], [File (Storage b)]) -> IO r) -> IO r)) (bound at src/Servant/Test.hs:62:7) subserver :: Delayed (Server (Files b :> sublayout)) (bound at src/Servant/Test.hs:58:22) route :: Proxy (Files b :> sublayout) -> Context config -> Delayed (Server (Files b :> sublayout)) -> Router (bound at src/Servant/Test.hs:58:3) In the first argument of ?addBodyCheck?, namely ?subserver? In the third argument of ?route?, namely ?(addBodyCheck subserver (bodyCheck request))? src/Servant/Test.hs:59:70: Couldn't match type ?m? with ?IO? ?m? is untouchable inside the constraints (KnownBackend b, HasServer sublayout config) bound by the instance declaration at src/Servant/Test.hs:(53,10)-(54,80)ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): No skolem info: m_a5An[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 08:29:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 08:29:58 -0000 Subject: [GHC] #11753: Type hole(?) causes compiler failure In-Reply-To: <043.7a81c953d83c393090e34705d60ba9ba@haskell.org> References: <043.7a81c953d83c393090e34705d60ba9ba@haskell.org> Message-ID: <058.f751aeed8e4bc72abfe773ebcb8ba6a5@haskell.org> #11753: Type hole(?) causes compiler failure -------------------------------------+------------------------------------- Reporter: akfp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by akfp: @@ -1,1 +1,1 @@ - I tried to understand soem Servant code, and added + I tried to understand some Servant code, and added @@ -10,1 +10,1 @@ - -# LANGUAGE DataKinds #-} + {-# LANGUAGE DataKinds #-} New description: I tried to understand some Servant code, and added {{{#!hs bodyCheck :: _ }}} To the following code {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeSynonymInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} module Servant.Files ( FilesTmp , FilesMem , MultiPartData , MultiPartDataT , Tmp , Mem ) where import Control.Monad.Trans.Resource import Data.ByteString.Lazy (ByteString) import Network.Wai.Parse import Servant import Servant.Server.Internal -- Backends for file upload: in memory or in /tmp ? data Mem data Tmp class KnownBackend b where type Storage b :: * withBackend :: Proxy b -> (BackEnd (Storage b) -> IO r) -> IO r instance KnownBackend Mem where type Storage Mem = ByteString withBackend Proxy f = f lbsBackEnd instance KnownBackend Tmp where type Storage Tmp = FilePath withBackend Proxy f = runResourceT . withInternalState $ \s -> f (tempFileBackEnd s) -- * Files combinator, to get all of the uploaded files data Files b type MultiPartData b = ([Param], [File (Storage b)]) type MultiPartDataT b = ((MultiPartData b -> IO (MultiPartData b)) -> IO (MultiPartData b)) type FilesMem = Files Mem type FilesTmp = Files Tmp instance (KnownBackend b, HasServer sublayout config) => HasServer (Files b :> sublayout) config where type ServerT (Files b :> sublayout) m = MultiPartDataT b -> ServerT sublayout m route Proxy config subserver = WithRequest $ \request -> route (Proxy :: Proxy sublayout) config (addBodyCheck subserver (bodyCheck request)) where bodyCheck :: _ bodyCheck request = return $ Route (\f -> withBackend (Proxy :: Proxy b) $ \pb -> parseRequestBody pb request >>= f ) }}} Output: {{{ > :load src/Servant/Test.hs [1 of 1] Compiling Servant.Files ( src/Servant/Test.hs, interpreted ) src/Servant/Test.hs:59:59: Couldn't match type ?r? with ?([Param], [File (Storage b)])? because type variable ?b? would escape its scope This (rigid, skolem) type variable is bound by the instance declaration at src/Servant/Test.hs:(53,10)-(54,80) Expected type: Delayed (((([Param], [File (Storage b)]) -> IO r) -> IO r) -> Server sublayout) Actual type: Delayed (Server (Files b :> sublayout)) Relevant bindings include bodyCheck :: Network.Wai.Internal.Request -> m (RouteResult ((([Param], [File (Storage b)]) -> IO r) -> IO r)) (bound at src/Servant/Test.hs:62:7) subserver :: Delayed (Server (Files b :> sublayout)) (bound at src/Servant/Test.hs:58:22) route :: Proxy (Files b :> sublayout) -> Context config -> Delayed (Server (Files b :> sublayout)) -> Router (bound at src/Servant/Test.hs:58:3) In the first argument of ?addBodyCheck?, namely ?subserver? In the third argument of ?route?, namely ?(addBodyCheck subserver (bodyCheck request))? src/Servant/Test.hs:59:70: Couldn't match type ?m? with ?IO? ?m? is untouchable inside the constraints (KnownBackend b, HasServer sublayout config) bound by the instance declaration at src/Servant/Test.hs:(53,10)-(54,80)ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): No skolem info: m_a5An[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 09:06:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 09:06:20 -0000 Subject: [GHC] #11753: Type hole(?) causes compiler failure In-Reply-To: <043.7a81c953d83c393090e34705d60ba9ba@haskell.org> References: <043.7a81c953d83c393090e34705d60ba9ba@haskell.org> Message-ID: <058.63f395999815863394ac6a2be0ebace2@haskell.org> #11753: Type hole(?) causes compiler failure -------------------------------------+------------------------------------- Reporter: akfp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate Comment: This will be fixed in the next release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 09:30:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 09:30:33 -0000 Subject: [GHC] #11753: Type hole(?) causes compiler failure In-Reply-To: <043.7a81c953d83c393090e34705d60ba9ba@haskell.org> References: <043.7a81c953d83c393090e34705d60ba9ba@haskell.org> Message-ID: <058.fdead582ff8d9b02541bd42a495db7bb@haskell.org> #11753: Type hole(?) causes compiler failure -------------------------------------+------------------------------------- Reporter: akfp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What's it a duplicate of? Are you saying that you've tested with the 8.0 release candidate and it's fine there? If so, great, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 09:35:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 09:35:54 -0000 Subject: [GHC] #11728: Core lint errors In-Reply-To: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> References: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> Message-ID: <066.398d2bab0617b513e55003d4265d7992@haskell.org> #11728: Core lint errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: The original report is fixed by this commit (I made a typo in the ticket number). {{{ commit 356e5e03e63558019fd0571b6c462740aceb7810 Author: Simon Peyton Jones Date: Fri Mar 25 09:23:17 2016 +0000 Do not eta-reduce across Ticks in CorePrep The function tryEtaReducePrep was being over-ambitious. When Breakpoint ticks were involved (i.e. in GHCi), eta reduction left an out-of-scope variable in the Tick. Easily fixed. Fixes the original report in Trac #111728. >--------------------------------------------------------------- 356e5e03e63558019fd0571b6c462740aceb7810 compiler/coreSyn/CorePrep.hs | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/compiler/coreSyn/CorePrep.hs b/compiler/coreSyn/CorePrep.hs index 58eda2f..fb00f2b 100644 --- a/compiler/coreSyn/CorePrep.hs +++ b/compiler/coreSyn/CorePrep.hs @@ -967,8 +967,13 @@ tryEtaReducePrep bndrs (Let bind@(NonRec _ r) body) where fvs = exprFreeVars r -tryEtaReducePrep bndrs (Tick tickish e) - = fmap (mkTick tickish) $ tryEtaReducePrep bndrs e +-- NB: do not attempt to eta-reduce across ticks +-- Otherwise we risk reducing +-- \x. (Tick (Breakpoint {x}) f x) +-- ==> Tick (breakpoint {x}) f +-- which is bogus (Trac #17228) +-- tryEtaReducePrep bndrs (Tick tickish e) +-- = fmap (mkTick tickish) $ tryEtaReducePrep bndrs e tryEtaReducePrep _ _ = Nothing }}} I'll add a test. Please merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 09:38:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 09:38:13 -0000 Subject: [GHC] #11754: Error in optCoercion Message-ID: <046.bab60c56aeea09df505e0c689289f35b@haskell.org> #11754: Error in optCoercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program fails Lint after a run of the simplifier. {{{ {-# LANGUAGE TypeOperators, UndecidableSuperClasses, KindSignatures, TypeFamilies, FlexibleContexts #-} module T11728a where import Data.Kind import Data.Void newtype K a x = K a newtype I x = I x data (f + g) x = L (f x) | R (g x) data (f ? g) x = f x :?: g x class Differentiable (D f) => Differentiable f where type D (f :: Type -> Type) :: Type -> Type instance Differentiable (K a) where type D (K a) = K Void instance Differentiable I where type D I = K () instance (Differentiable f?, Differentiable f?) => Differentiable (f? + f?) where type D (f? + f?) = D f? + D f? instance (Differentiable f?, Differentiable f?) => Differentiable (f? ? f?) where type D (f? ? f?) = (D f? ? f?) + (f? ? D f?) }}} Originally reported in #11728, but it's a totally different problem. Richard has nailed it already... patch coming from him. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 09:38:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 09:38:41 -0000 Subject: [GHC] #11754: Error in optCoercion In-Reply-To: <046.bab60c56aeea09df505e0c689289f35b@haskell.org> References: <046.bab60c56aeea09df505e0c689289f35b@haskell.org> Message-ID: <061.dcba01aa5f1cf2de83de0915dedf94ee@haskell.org> #11754: Error in optCoercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => goldfire * priority: normal => highest * milestone: => 8.0.1 Comment: I'll make it "highest" to make sure we don't forget to merge this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 09:39:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 09:39:46 -0000 Subject: [GHC] #11728: Core lint errors In-Reply-To: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> References: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> Message-ID: <066.1bcd807208a2a2b64c1ce911ad16aacb@haskell.org> #11728: Core lint errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The `Error.hs` problem (between comment:2 and comment:3) is utterly different. I opened #11754 for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 09:48:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 09:48:51 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.16ed38d2ef9ba1a1482c9ae9ee5eb724@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Apart from it all being kind-polymorphic, the other difference is that the foralls are not brought together. But the effect is unchanged. Does it matter? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 09:49:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 09:49:44 -0000 Subject: [GHC] #11184: panic tcMonoExpr _ with bad indentation in TH code In-Reply-To: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> References: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> Message-ID: <066.dca1915014d3dba51a0915418b20ea8d@haskell.org> #11184: panic tcMonoExpr _ with bad indentation in TH code -------------------------------------+------------------------------------- Reporter: TeroLaitinen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TemplateHaskell * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 09:57:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 09:57:13 -0000 Subject: [GHC] #11754: Error in optCoercion In-Reply-To: <046.bab60c56aeea09df505e0c689289f35b@haskell.org> References: <046.bab60c56aeea09df505e0c689289f35b@haskell.org> Message-ID: <061.fcc26666bc8e0d2cecf65c38164f7170@haskell.org> #11754: Error in optCoercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 10:02:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 10:02:48 -0000 Subject: [GHC] #11722: No TypeRep for unboxed tuples In-Reply-To: <047.62aa410ace38ef8cf0e4ab854da20597@haskell.org> References: <047.62aa410ace38ef8cf0e4ab854da20597@haskell.org> Message-ID: <062.2f13ae7ae166a745fb4efbd34e33d132@haskell.org> #11722: No TypeRep for unboxed tuples -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See also #11736, which is closely related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 10:03:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 10:03:24 -0000 Subject: [GHC] #11736: Allow unsaturated uses of unlifted types in Core In-Reply-To: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> References: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> Message-ID: <061.e28342f70a08a4712797547298cf4e5f@haskell.org> #11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See also #11722 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 10:20:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 10:20:33 -0000 Subject: [GHC] #11728: Core lint errors In-Reply-To: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> References: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> Message-ID: <066.f244c4070d48e079ec7f2d0a7d5e1169@haskell.org> #11728: Core lint errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b416630faf92b5366fcc48941fa54b87f13994f8/ghc" b416630f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b416630faf92b5366fcc48941fa54b87f13994f8" Test Trac #11728 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 10:20:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 10:20:39 -0000 Subject: [GHC] #11751: Parse error with case in where In-Reply-To: <046.54234b52b76451ad86fb8ff46ac451f1@haskell.org> References: <046.54234b52b76451ad86fb8ff46ac451f1@haskell.org> Message-ID: <061.957729304f61eb6b3557f9fd3572f530@haskell.org> #11751: Parse error with case in where -------------------------------------+------------------------------------- Reporter: samuela | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Incorrect warning at compile-time * component: Compiler => Compiler (Parser) Comment: Thanks for the report. That being said, I'm not sure I see why do you say it's peculiar. It seems like quite a reasonable error to me: The `case` alternative falls outside of the virtual close-bracket delimiting the `where` clause due to its indentation. In particular, the fragment `(a, b) -> (3, 4)` * cannot be parsed as a case alternative (due to being "outside" of the `case` expression) * cannot be parsed as a binding (since it also falls outside of the `where` clause (again, since it has decreasing indentation) * cannot be a top-level binding (due to the `->`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 10:21:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 10:21:00 -0000 Subject: [GHC] #11728: Core lint errors In-Reply-To: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> References: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> Message-ID: <066.f37f33b990d4835fdab4848552283584@haskell.org> #11728: Core lint errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T11728 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => ghci/scripts/T11728 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 10:21:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 10:21:37 -0000 Subject: [GHC] #11753: Type hole(?) causes compiler failure In-Reply-To: <043.7a81c953d83c393090e34705d60ba9ba@haskell.org> References: <043.7a81c953d83c393090e34705d60ba9ba@haskell.org> Message-ID: <058.576c0b570e322e7dd9b549926b9c2858@haskell.org> #11753: Type hole(?) causes compiler failure -------------------------------------+------------------------------------- Reporter: akfp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #11059 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: => #11059 Comment: #11059 and quite a few others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 10:30:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 10:30:07 -0000 Subject: [GHC] #11726: Document change in implicit quantification In-Reply-To: <047.b3f24e15febbe2b1b55713b5bd16ee41@haskell.org> References: <047.b3f24e15febbe2b1b55713b5bd16ee41@haskell.org> Message-ID: <062.7f78645b3911bce1b4d673e699ec5dcd@haskell.org> #11726: Document change in implicit quantification -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"da4bc0cff142225ed7fda7101cb6e559f025ebc1/ghc" da4bc0c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="da4bc0cff142225ed7fda7101cb6e559f025ebc1" Document implicit quantification better Addresses Trac #11726 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 10:30:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 10:30:15 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311750=3A_32_bit_CPUs=3A_Couldn=27t_?= =?utf-8?q?match_expected_type_=E2=80=98Word=23=E2=80=99_with_act?= =?utf-8?b?dWFsIHR5cGUg4oCYV29yZDY0I+KAmQ==?= In-Reply-To: <044.b6ecdb23aa4eae2e442be684f61fe72c@haskell.org> References: <044.b6ecdb23aa4eae2e442be684f61fe72c@haskell.org> Message-ID: <059.567506e39371bc8f93651a9f13048dfa@haskell.org> #11750: 32 bit CPUs: Couldn't match expected type ?Word#? with actual type ?Word64#? -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as bf6e2085ce7e9de0c56b4b2ef8db24df65cd8d68. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 10:40:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 10:40:25 -0000 Subject: [GHC] #11726: Document change in implicit quantification In-Reply-To: <047.b3f24e15febbe2b1b55713b5bd16ee41@haskell.org> References: <047.b3f24e15febbe2b1b55713b5bd16ee41@haskell.org> Message-ID: <062.b7fb4da5bef9dbfa9d6a336d50bbdc74@haskell.org> #11726: Document change in implicit quantification -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"454585c6802f0de4d23f9f16de591596533503b7/ghc" 454585c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="454585c6802f0de4d23f9f16de591596533503b7" More clarification in docs for implicit quantification This is a follow-up patch to the previous one for #11726. It turns out that I'd missed the point of the ticket; this patch addresses it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 10:40:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 10:40:47 -0000 Subject: [GHC] #11726: Document change in implicit quantification In-Reply-To: <047.b3f24e15febbe2b1b55713b5bd16ee41@haskell.org> References: <047.b3f24e15febbe2b1b55713b5bd16ee41@haskell.org> Message-ID: <062.a9e79be0e97ceb5bee3f6c8c626d2d4a@haskell.org> #11726: Document change in implicit quantification -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: merge Priority: high | Milestone: 8.0.1 Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: OK, done. Merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 10:55:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 10:55:26 -0000 Subject: [GHC] #11726: Document change in implicit quantification In-Reply-To: <047.b3f24e15febbe2b1b55713b5bd16ee41@haskell.org> References: <047.b3f24e15febbe2b1b55713b5bd16ee41@haskell.org> Message-ID: <062.c73c18f6fac06f89da1b7018ec56a243@haskell.org> #11726: Document change in implicit quantification -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: closed Priority: high | Milestone: 8.0.1 Component: Documentation | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 11:02:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 11:02:09 -0000 Subject: [GHC] #11626: type variable out of scope core lint error when compiling attoparsec In-Reply-To: <044.3b54a1a1868c7f532f99f416b8fae60d@haskell.org> References: <044.3b54a1a1868c7f532f99f416b8fae60d@haskell.org> Message-ID: <059.ad41bfe2147ced96c10adc188329227c@haskell.org> #11626: type variable out of scope core lint error when compiling attoparsec -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11665 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What does "just fixed" mean? Is it ok in our upcoming 8.0, and HEAD? If so, fine. Do you know what fixed it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 11:05:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 11:05:26 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.a01981c8c11918ec7b452fe31979f8cf@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -21,0 +21,2 @@ + + See also #11621 New description: I first noticed something was a bit odd with `Constraint` when chasing #11334. Consider this testcase (`-O0` is sufficient), {{{#!hs import Data.Typeable main = do print $ typeRep (Proxy :: Proxy Eq) print $ typeOf (Proxy :: Proxy Eq) }}} With `ghc-8.0` this will produce, {{{ Eq Proxy (* -> *) Eq }}} Notice the second line; GHC seems to be claiming that `Eq :: * -> *`, which is clearly nonsense. I believe this issue may be the cause of some of the testsuite failures that I'm seeing on #11011. Unfortunately I haven't the foggiest where this issue might originate. See also #11621 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 11:05:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 11:05:47 -0000 Subject: [GHC] #11621: GHC doesn't see () as a Constraint in type family In-Reply-To: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> References: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> Message-ID: <066.41e34d43bcf32a08abaa9957fff325c0@haskell.org> #11621: GHC doesn't see () as a Constraint in type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See also #11715, which tackles the bigger picture -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 11:06:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 11:06:12 -0000 Subject: [GHC] #11626: type variable out of scope core lint error when compiling attoparsec In-Reply-To: <044.3b54a1a1868c7f532f99f416b8fae60d@haskell.org> References: <044.3b54a1a1868c7f532f99f416b8fae60d@haskell.org> Message-ID: <059.07549dd7c2f68a9582f6d730582ffd60@haskell.org> #11626: type variable out of scope core lint error when compiling attoparsec -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11665 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): This ticket is an exact duplicate of #11665, which was fixed for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 11:15:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 11:15:00 -0000 Subject: [GHC] #11728: Core lint errors In-Reply-To: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> References: <051.6bcedaccaf0cce0d232c3cb7e4659f49@haskell.org> Message-ID: <066.6c8a8613a44e4017df70b90a0f89b609@haskell.org> #11728: Core lint errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | ghci/scripts/T11728 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * failure: None/Unknown => Other * resolution: => fixed * milestone: => 8.0.1 Comment: Merged to `ghc-8.0` as 7f2d6f5a18d7b15b76bd1bf5cd59b81fb241365b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 11:34:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 11:34:28 -0000 Subject: [GHC] #11753: Type hole(?) causes compiler failure In-Reply-To: <043.7a81c953d83c393090e34705d60ba9ba@haskell.org> References: <043.7a81c953d83c393090e34705d60ba9ba@haskell.org> Message-ID: <058.bacc2669ba1ef4b72faa883031ea27d7@haskell.org> #11753: Type hole(?) causes compiler failure -------------------------------------+------------------------------------- Reporter: akfp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #11059 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I have managed to test it now and it is indeed fixed. {{{ [1 of 1] Compiling Servant.Files ( test.hs, test.o ) test.hs:62:20: error: ? Found type wildcard ?_? standing for ?Network.Wai.Internal.Request -> IO (RouteResult ((([Param], [File (Storage b)]) -> IO r) -> IO r))? Where: ?r? is a rigid type variable bound by the inferred type of bodyCheck :: Network.Wai.Internal.Request -> IO (RouteResult ((([Param], [File (Storage b)]) -> IO r) -> IO r)) at test.hs:63:7 ?b? is a rigid type variable bound by the instance declaration at test.hs:54:10 To use the inferred type, enable PartialTypeSignatures ? In the type signature: bodyCheck :: _ In an equation for ?route?: route Proxy config subserver = WithRequest $ \ request -> route (Proxy :: Proxy sublayout) config (addBodyCheck subserver (bodyCheck request)) where bodyCheck :: _ bodyCheck request = return $ Route (\ f -> withBackend (Proxy :: Proxy b) $ \ pb -> ...) In the instance declaration for ?HasServer (Files b :> sublayout) config? ? Relevant bindings include bodyCheck :: Network.Wai.Internal.Request -> IO (RouteResult ((([Param], [File (Storage b)]) -> IO r) -> IO r)) (bound at test.hs:63:7) subserver :: Delayed (Server (Files b :> sublayout)) (bound at test.hs:59:22) config :: Config config (bound at test.hs:59:15) route :: Proxy (Files b :> sublayout) -> Config config -> Delayed (Server (Files b :> sublayout)) -> Router (bound at test.hs:59:3) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 11:57:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 11:57:28 -0000 Subject: [GHC] #11753: Type hole(?) causes compiler failure In-Reply-To: <043.7a81c953d83c393090e34705d60ba9ba@haskell.org> References: <043.7a81c953d83c393090e34705d60ba9ba@haskell.org> Message-ID: <058.5bac100a0aaf21616c7ad27011df18ff@haskell.org> #11753: Type hole(?) causes compiler failure -------------------------------------+------------------------------------- Reporter: akfp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #11059 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Terrific thanks. I'm not sure it's worth adding as a regression test, as it's similar to others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 12:29:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 12:29:14 -0000 Subject: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC In-Reply-To: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> References: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> Message-ID: <059.18bbfe84619d59d8156beee45d8ec5b6@haskell.org> #4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: kaiha Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2258 | Differential Rev(s): Phab:D2021 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hmm these test break on Windows since they don't properly take note of the application suffix. e.g. on Windows It needs to check for "T4114a.exe" instead of "T4114a". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 12:54:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 12:54:15 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.63a1c8af51f1fe878e2bb518b7ada310@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I suppose the behavior is unchanged, but cosmetically, the type signature's appearance seems off, especially when combined with `-XTypeApplications`: {{{ $ /opt/ghc/8.0.1/bin/ghci GHCi, version 8.0.0.20160324: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci ?> :set -XTypeApplications -XDataKinds -fprint-explicit-foralls ?> import GHC.Generics ?> :t datatypeName @('MetaData "Void" "Data.Void" "base" 'False) datatypeName @('MetaData "Void" "Data.Void" "base" 'False) :: Datatype ('MetaData "Void" "Data.Void" "base" 'False) => forall {k1} (t :: Meta -> (* -> *) -> k1 -> *) (f :: * -> *) (a :: k1). t ('MetaData "Void" "Data.Void" "base" 'False) f a -> [Char] }}} 1. You would expect the context to go away once you apply `'MetaData "Void" "Data.Void" "base" 'False`. 2. You certainly wouldn't expect the context to appear //before// the list of quantified type variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 12:58:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 12:58:53 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.ae5c8c47fefea394e0fdb2a5aab586de@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1961 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Do you think it's worth special-casing this kind of behavior with `-XTypeApplications` as well? Currently, it's quite easy to leak `RuntimeRep`: {{{ $ /opt/ghc/8.0.1/bin/ghci GHCi, version 8.0.0.20160324: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci ?> :t undefined undefined :: GHC.Stack.Types.HasCallStack => a ?> :set -XTypeApplications ?> :t undefined @Int :1:12: error: ? Expected kind ?GHC.Types.RuntimeRep?, but ?Int? has kind ?*? ? In the type ?Int? In the expression: undefined @Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 13:38:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 13:38:11 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.bcb7012cae04adff9120ef239fb9616e@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think the fact that the context doesn't go away is a bug in visible type application. Richard? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 14:11:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 14:11:10 -0000 Subject: [GHC] #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls In-Reply-To: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> References: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> Message-ID: <061.482d7ebbea605edda5d4b6c1ef5bc2b0@haskell.org> #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11338, #11337 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #11338, #11337 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 14:11:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 14:11:22 -0000 Subject: [GHC] #11338: Unwind information is incorrect in region surrounding a safe foreign call In-Reply-To: <046.63160c8569d055bb9627f95207d1d3a0@haskell.org> References: <046.63160c8569d055bb9627f95207d1d3a0@haskell.org> Message-ID: <061.739ed7e34f687b7d3ff16f6325d24698@haskell.org> #11338: Unwind information is incorrect in region surrounding a safe foreign call -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11337, #11353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #11337 => #11337, #11353 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 15:36:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 15:36:07 -0000 Subject: [GHC] #11755: Seed unsafeGlobalDynFlags with enough information to use ppr Message-ID: <046.9f7b4239d14bbc3c0460e17161c92902@haskell.org> #11755: Seed unsafeGlobalDynFlags with enough information to use ppr -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment the pretty-printer isn't functional if used before `DynFlags` is initialized by `initGhcMonad`. In particular things like `pprPanic` aren't usable since `unsafeGlobalDynFlags` isn't yet initialized. This is quite annoying during development. It seems like it should be possible to seed `unsafeGlobalDynFlags` with some minimal `DynFlags`, presumably with rather verbose output (as this is presumably what you want when debugging a compiler crash early in startup). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 15:46:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 15:46:30 -0000 Subject: [GHC] #11755: Seed unsafeGlobalDynFlags with enough information to use ppr In-Reply-To: <046.9f7b4239d14bbc3c0460e17161c92902@haskell.org> References: <046.9f7b4239d14bbc3c0460e17161c92902@haskell.org> Message-ID: <061.b634af26dc229efa9fb51366cb8662f2@haskell.org> #11755: Seed unsafeGlobalDynFlags with enough information to use ppr -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2036 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2036 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 20:12:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 20:12:11 -0000 Subject: [GHC] #11736: Allow unsaturated uses of unlifted types in Core In-Reply-To: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> References: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> Message-ID: <061.bab50ff70dddaab16c8f28c366cd04a8@haskell.org> #11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): What about unboxed tuples? Right now, we have, e.g., `(# , #) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). TYPE r1 -> TYPE r2 -> TYPE 'UnboxedTupleRep`. Of course, `UnboxedTupleRep` is a lie, because unboxed tuples have all sorts of representations. There is an explicit check for this along with the check for runtime representation polymorphism. With those checks in place, what can go wrong even if we unsaturate unboxed tuples? I think it's OK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 20:39:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 20:39:51 -0000 Subject: [GHC] #11756: Data.Functor.Classes instances for Proxy Message-ID: <049.88e00c8489fafead34a109f21260f2c7@haskell.org> #11756: Data.Functor.Classes instances for Proxy -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It looks like Proxy is missing instances for Eq1, Ord1, Show1, and Read1. These are all completely trivial. Can I add them? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 20:42:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 20:42:46 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.2dc8c3dcb529c989feafaca1024b8687@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -51,0 +51,3 @@ + + EDIT: Most of this is fix, as of March 25. But the data family stuff in + comment:12 is still outstanding, and we need a test case. New description: Originally reported [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010915.html here]. When applying types via `-XTypeApplications`, the type/kind that gets instantiated seems to be different depending on whether you're using functions, datatypes, or typeclasses. Here's an example contrasting functions and datatypes: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help ?> :set -fprint-explicit-kinds -XTypeApplications -XTypeInType ?> data Prox a = Prox ?> prox :: Prox a; prox = Prox ?> :t prox prox :: forall k (a :: k). Prox k a ?> :t prox @Int prox @Int :: Prox * Int ?> :t Prox Prox :: forall k (a :: k). Prox k a ?> :t Prox @Int Prox @Int :: Prox Int a }}} This is the core of the problem: with a function, `Int` seems to be applied to type variable `a`, whereas with data types, `Int` appears to be applied to the kind variable `k`. This confuses me, since `k` wasn't specified anywhere in the definition of `Prox`. Andres L?h also [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010916.html observed] a similar discrepancy between functions and typeclasses: {{{ ?> :set -XScopedTypeVariables ?> class C a where c :: () ?> d :: forall a. C a => (); d = c @_ @a ?> :t d d :: forall k (a :: k). C k a => () ?> :t d @Int d @Int :: C * Int => () ?> :t c c :: forall k (a :: k). C k a => () ?> :t c @Int c @Int :: C Int a => () ?> :t c @_ @Int c @_ @Int :: C * Int => () }}} EDIT: See also documentation infelicity in comment:9. EDIT: Most of this is fix, as of March 25. But the data family stuff in comment:12 is still outstanding, and we need a test case. -- Comment (by goldfire): Replying to [comment:16 simonpj]: > I think the fact that the context doesn't go away is a bug in visible type application. Richard? Instantiation is lazy. There's (currently) no incentive for GHC to solve that constraint when you say `datatypeName @blah`. Consider {{{ foo :: forall a b. Show a => ... }}} and `foo @Int`. What type should this have? `forall b. Show Int => ...` seems the natural choice. The only way to get, say, `forall b. ...` (solving the constraint) would be to instantiate and regeneralize, but then we'd get `forall {b}. ...`, which is quite silly. We could have some logic that looks to see if no specified type variables are left at the beginning of the type and then instantiate constraints. But I'm not sure this is a good idea. Seems a bit arbitrary. Always being lazy seems simpler. As for the other problems in this ticket: they're mostly fixed now, except for the data family bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 21:07:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 21:07:55 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.fb5f5fa9cd2ab4a14a7befce7a33b20b@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Much like for [comment:12 comment 12], set myself up so I could build the vector test suite with ghc versions 7.8.4, 7.10.3 and 8.0.0.20160316 and then with each compiler ran `cabal clean && time cabal test` a number of times with each. This is the result of a single run, but is representative of this test: {{{ Compiler real user sys 7.8.4 1m38.167s 2m03.336s 0m43.800s 7.10.3 8m59.597s 11m40.756s 5m37.828s 8.0.0 0m45.165s 1m0.148s 0m23.744s }}} The 8.0 compiler has not only fixed the compile regression from 7.8 to 7.10, its actually about twice as fast as 7.8. Just as validation I also timed the runtime of the test suites compiled by each of the three compile and there didn't seem to be any measurable difference in run time performance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 22:44:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 22:44:53 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.0b8bcc1fd1c8cfee970e761517c3de39@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, very interesting. Indeed it has been quite a while since I've checked this issue with 8.0. Judging by comment:5 it seems this was still reproducible, ||= Compiler =||= Real =||= user =||= sys =||= allocations =||= max residency =|| || 8.0.0.20160311 || 1m7.445s || 1m1.257s || 5.938s || || || 1m2.751s || 55.979s || 6.774s || || || 59.469s || 55.507s || 3.959s || || || 58.90s || 56.98s || 1.41s || 39.77e9 bytes || 248.65e6 bytes || || 7.8.4 || 2m2.411s || 1m58.572s || 3.429s || || || 2m3.170s || 2m0.194s || 3.027s || || || 2m2.185s || 2m0.342s || 1.834s || || || 2m1.44s || 1m59.81s || 1.61s || 106.07e9 bytes || 369.51e6 bytes || || 7.10.3 || 11m40.961s || 11m38.834s || 6.592s || || || 11m29.73s || 11m28.62s || 5.47s || 454.467e9 bytes || 70.714e6 bytes || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 22:52:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 22:52:16 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.2bd642879e4bd4859a11065728759d24@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: highest => high * milestone: 8.0.1 => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 22:52:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 22:52:22 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.36cbbc09ff80b5eaf57ef4ad89aaa747@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 22:52:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 22:52:38 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.59a2ec3374e564588ed585a8bd81ff94@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 22:56:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 22:56:34 -0000 Subject: [GHC] #11752: ghc-8.0 branch fails to build with ghc-7.8 In-Reply-To: <044.569a3c8bd55efd2c4fb3e3e9e7f60df6@haskell.org> References: <044.569a3c8bd55efd2c4fb3e3e9e7f60df6@haskell.org> Message-ID: <059.b9b506bbfa547efc61dc7f2e9c6b28f5@haskell.org> #11752: ghc-8.0 branch fails to build with ghc-7.8 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Thanks Erik! Merged as 0a13e0c60416242bf7ed5715df489901119a9944. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 22:58:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 22:58:39 -0000 Subject: [GHC] #11587: Place shared objects in LIBDIR In-Reply-To: <046.ae680f55d8340157abb914750c3f9267@haskell.org> References: <046.ae680f55d8340157abb914750c3f9267@haskell.org> Message-ID: <061.8d3c90bfbce99976d90f123e8acf6746@haskell.org> #11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Package system | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: dcoutts (added) * milestone: 8.0.1 => 8.2.1 Comment: Adding Duncan as this will be primarily a Cabal change, but sadly this won't be happening for 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 23:04:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 23:04:39 -0000 Subject: [GHC] #11687: GHC reports unimplemented/strange closure type 5937 in the ARM platform In-Reply-To: <046.132b2bfeb7d9730f653c87d886b5930b@haskell.org> References: <046.132b2bfeb7d9730f653c87d886b5930b@haskell.org> Message-ID: <061.98496fbbd5e84243aac6524f67fc8234@haskell.org> #11687: GHC reports unimplemented/strange closure type 5937 in the ARM platform ----------------------------------+------------------------------ Reporter: highfly | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by bgamari): * status: infoneeded => closed * resolution: => duplicate Comment: I'm fairly certain that this should be fixed in 8.0.1 (see #11206 for an accounting of the various issues fixed in 8.0.1). Closing as there has been no response. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 23:07:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 23:07:14 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.3d71377fd30b3a8fc9bf3f9d3e66301e@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dolio): Interesting. Do you by chance have 7.6.3 to compare with? 7.8 was already significantly worse than it. bgamari, is your max residency for 7.10 off? The figures for both 7.8 and 7.10 seem low to me, really. When I build the test suite on 7.10 I get like 11 GB max residency, and I'm not sure it would ever complete if I limited it to ~400 MB. Unless your test is a smaller case derived from the real test suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 23:30:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 23:30:37 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.9707bada2d6ac7b0dcdf52f748a32923@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): I do have 7.6.3 installed, but it seems to have become broken since last time I tried. I think its actually a cabal issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 25 23:36:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Mar 2016 23:36:48 -0000 Subject: [GHC] #11714: Kind of (->) type constructor is overly constrained In-Reply-To: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> References: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> Message-ID: <061.73c5bb8d54415c540c94b04840dfff6a@haskell.org> #11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For what it's worth I took a stab at carrying out comment:3 [[http://git.haskell.org/ghc.git/commitdiff/refs/heads/wip/generalized- arrow|here]]. At the moment I'm a bit stuck on how to deal with `Constraint`s. This appears to be yet another case where `* ~ Constraint` would simplify things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 01:01:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 01:01:11 -0000 Subject: [GHC] #11755: Seed unsafeGlobalDynFlags with enough information to use ppr In-Reply-To: <046.9f7b4239d14bbc3c0460e17161c92902@haskell.org> References: <046.9f7b4239d14bbc3c0460e17161c92902@haskell.org> Message-ID: <061.710a303e9db882888f942bd1d4bfd0d0@haskell.org> #11755: Seed unsafeGlobalDynFlags with enough information to use ppr -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2036 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4e98b4ff98e127aa9ef4fa1e85bdf0efa41f0902/ghc" 4e98b4f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4e98b4ff98e127aa9ef4fa1e85bdf0efa41f0902" DynFlags: Initialize unsafeGlobalDynFlags enough to be useful Previously unsafeGlobalDynFlags would bottom if used prior to initialization. This meant that any attempt to use the pretty-printer early in the initialization process of the compiler would fail. This is quite inconvenient. Here we initialize unsafeGlobalDynFlags with defaultDynFlags, bottoming only if settings is accessed. See #11755. Test Plan: Validate Reviewers: austin Reviewed By: austin Subscribers: thomie, gridaphobe Differential Revision: https://phabricator.haskell.org/D2036 GHC Trac Issues: #11755 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 01:01:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 01:01:11 -0000 Subject: [GHC] #11755: Seed unsafeGlobalDynFlags with enough information to use ppr In-Reply-To: <046.9f7b4239d14bbc3c0460e17161c92902@haskell.org> References: <046.9f7b4239d14bbc3c0460e17161c92902@haskell.org> Message-ID: <061.c583adf9b4c18d034f11ae25e1e02299@haskell.org> #11755: Seed unsafeGlobalDynFlags with enough information to use ppr -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2036 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e8d356773b56c1e56911b6359a368fe2f5d3ed1c/ghc" e8d3567/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e8d356773b56c1e56911b6359a368fe2f5d3ed1c" Panic: Try outputting SDocs This works in conjunction with D2036 to allow useful debug output before DynFlags has been initializated. See #11755. Reviewers: austin Reviewed By: austin Subscribers: thomie, gridaphobe Differential Revision: https://phabricator.haskell.org/D2037 GHC Trac Issues: #11755 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 01:01:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 01:01:11 -0000 Subject: [GHC] #11165: Testsuite framework failures are too easy to ignore and too hard to find In-Reply-To: <046.b1d93186c62e1a3de1b9e3c053f1008e@haskell.org> References: <046.b1d93186c62e1a3de1b9e3c053f1008e@haskell.org> Message-ID: <061.284b172e3a23b6d46beead7576b11efb@haskell.org> #11165: Testsuite framework failures are too easy to ignore and too hard to find -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2026 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d0787a2c232b61f8be080048ea48af7697094c97/ghc" d0787a2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d0787a2c232b61f8be080048ea48af7697094c97" testsuite: Identify framework failures in testsuite summary Currently the testsuite driver tells you how many tests failed due to a framework failure but you need to manually grep through the testsuite output to identify which ones. Test Plan: Validate with, e.g., a timing out testcase Reviewers: austin, thomie Reviewed By: austin, thomie Differential Revision: https://phabricator.haskell.org/D2026 GHC Trac Issues: #11165 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 01:10:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 01:10:02 -0000 Subject: [GHC] #11756: Data.Functor.Classes instances for Proxy In-Reply-To: <049.88e00c8489fafead34a109f21260f2c7@haskell.org> References: <049.88e00c8489fafead34a109f21260f2c7@haskell.org> Message-ID: <064.7ccedeeda6cea28cf4a2fdacee90d0aa@haskell.org> #11756: Data.Functor.Classes instances for Proxy -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: RyanGlScott, ekmett (added) * component: Compiler => Core Libraries * milestone: => 8.0.1 @@ -1,2 +1,2 @@ - It looks like Proxy is missing instances for Eq1, Ord1, Show1, and Read1. - These are all completely trivial. Can I add them? + It looks like `Proxy` is missing instances for `Eq1`, `Ord1`, `Show1`, and + `Read1`. These are all completely trivial. Can I add them? New description: It looks like `Proxy` is missing instances for `Eq1`, `Ord1`, `Show1`, and `Read1`. These are all completely trivial. Can I add them? -- Comment: Sure, feel free to submit a patch. Cc'ing RyanGlScott who has thought more about the implications of these instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 01:34:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 01:34:16 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.e7c4fe0cffde16f481a07edf142b7932@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ryantrinkle): Use cases like pumpkin's `Some` have been cropping up more and more frequently for me; I think this would be pretty useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 01:37:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 01:37:35 -0000 Subject: [GHC] #11756: Data.Functor.Classes instances for Proxy In-Reply-To: <049.88e00c8489fafead34a109f21260f2c7@haskell.org> References: <049.88e00c8489fafead34a109f21260f2c7@haskell.org> Message-ID: <064.f8667ca1c2f207495a1c9edeba829fdb@haskell.org> #11756: Data.Functor.Classes instances for Proxy -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): By all means, start adding instances if you need them. As I noted [https://ghc.haskell.org/trac/ghc/ticket/11135#comment:25 here], I plan to eventually create a language extension for deriving `Eq1` and friends, which will make adding these kinds of instances much less painful in the future. But we don't derive `Eq`, `Ord`, etc. for `Proxy` anyway to make the instances sufficiently lazy, so we should provide similar treatment for `Eq1`, `Ord1`, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 03:35:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 03:35:50 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.c858e94e52b49225365d2272180ef334@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Brought up on #ghc, are there technical reasons why `(,)` ''cannot'' be partially applied with the same meaning as `(&)`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 08:28:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 08:28:27 -0000 Subject: [GHC] #11757: Turn on (and require) C99/C11 mode by default Message-ID: <042.cdde255506f2bc07285d1fee6acec3cf@haskell.org> #11757: Turn on (and require) C99/C11 mode by default -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GCC 5.x started defaulting to C99 (or rather gnu99 mode), while Clang has been defaulting to C99 (or even C11) for a bit longer, as has Apple's patched GCC. So we should try to consistently turn on (if needed) C99 (or C11) support for all compilers supported by GHC, and adapt the code-base to expect C99 compliance (which probably allows us to get rid of a couple of compat-CPP and make the C code more idiomatic and readable in the process...). GNU Autoconf provides a `AC_PROG_CC_C99` which figures out what's needed to have the compiler turn on C99 support, but we need to integrate that with out Requiring C99 will effectively rule out GCC 3.x (which is old enough that we can drop support for that), and possibly also GCC < 4.3 at some point (for reference, even Debian 6 Squeeze didn't have GCC 4.2 anymore), see also https://gcc.gnu.org/c99status.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 08:29:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 08:29:38 -0000 Subject: [GHC] #11757: Turn on (and require) C99/C11 mode by default In-Reply-To: <042.cdde255506f2bc07285d1fee6acec3cf@haskell.org> References: <042.cdde255506f2bc07285d1fee6acec3cf@haskell.org> Message-ID: <057.bc1541e03ecc2d43a21bf0a95c4c1e18@haskell.org> #11757: Turn on (and require) C99/C11 mode by default -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by hvr: @@ -13,1 +13,1 @@ - with out + with our `CONF_CC_OPTS_STAGE[012]` scheme... New description: GCC 5.x started defaulting to C99 (or rather gnu99 mode), while Clang has been defaulting to C99 (or even C11) for a bit longer, as has Apple's patched GCC. So we should try to consistently turn on (if needed) C99 (or C11) support for all compilers supported by GHC, and adapt the code-base to expect C99 compliance (which probably allows us to get rid of a couple of compat-CPP and make the C code more idiomatic and readable in the process...). GNU Autoconf provides a `AC_PROG_CC_C99` which figures out what's needed to have the compiler turn on C99 support, but we need to integrate that with our `CONF_CC_OPTS_STAGE[012]` scheme... Requiring C99 will effectively rule out GCC 3.x (which is old enough that we can drop support for that), and possibly also GCC < 4.3 at some point (for reference, even Debian 6 Squeeze didn't have GCC 4.2 anymore), see also https://gcc.gnu.org/c99status.html -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 09:53:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 09:53:58 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.4deeab9d4109c6343ee2fb3b73d5092b@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by chak): Did anybody file a Radar (Apple bug tracker) about this? (Otherwise, it is rather unlikely to be fixed.) Or maybe this should be reported to the LLVM folks? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 11:07:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 11:07:44 -0000 Subject: [GHC] #11758: Drop x86_64 binutils <2.17 hack Message-ID: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> #11758: Drop x86_64 binutils <2.17 hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc2 (NCG) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `X86.CodeGen.genSwitch` contains this comment, {{{ else -- HACK: On x86_64 binutils<2.17 is only able to generate -- PC32 relocations, hence we only get 32-bit offsets in -- the jump table. As these offsets are always negative -- we need to properly sign extend them to 64-bit. This -- hack should be removed in conjunction with the hack in -- PprMach.hs/pprDataItem once binutils 2.17 is standard. }}} binutils 2.17 is now quite standard; even CentOS 5 shipped with 2.17. I think it is likely safe to remove this hack at this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 12:44:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 12:44:22 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.c11d11a716d8d0c90bc5c2c80881ea88@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by carter): @chak I don't think either has be filed yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 13:28:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 13:28:46 -0000 Subject: [GHC] #10338: GHC Forgets Constraints In-Reply-To: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> References: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> Message-ID: <062.f78e1b9c18b324bbacc4bb0f77a5e6a8@haskell.org> #10338: GHC Forgets Constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by crockeea: @@ -61,1 +61,1 @@ - instead of using the `T (F r)` constraint supplied by `convert`. + instead of using the `T t (F r)` constraint supplied by `convert`. New description: This is possibly fixed by #10195, but I don't have a convenient means of testing it. At any rate, this testcase is considerably simpler than the one in #10195. {{{#!hs {-# LANGUAGE TypeFamilies, FlexibleContexts, GADTs, MultiParamTypeClasses #-} type family F r class (Functor t) => T t r where fromScalar :: r -> t r data Foo t r where Foo :: t (F r) -> Foo t r Scalar :: r -> Foo t r toF :: r -> F r toF = undefined convert :: (T t (F r)) => Foo t r -> Foo t r convert (Scalar c) = let fromScalar' = fromScalar in Foo $ fromScalar' $ toF c }}} This code compiles with GHC 7.8.4. When I add a generic instance for `T` (which requires `FlexibleInstances`): `instance (Functor t, Num r) => T t r` GHC complains: {{{#!hs Could not deduce (Num (F r)) arising from a use of ?fromScalar? from the context (T t (F r)) bound by the type signature for convert :: (T t (F r)) => Foo t r -> Foo t r at Main.hs:(17,12)-(18,23) In the expression: fromScalar In an equation for ?fromScalar'?: fromScalar' = fromScalar In the expression: let fromScalar' = fromScalar in Foo $ fromScalar' $ toF c }}} Of course the problem can be fixed by adding a type signature to `fromScalar` and adding `ScopedTypeVariables`: {{{#!hs convert :: forall t r . (T t (F r)) => Foo t r -> Foo t r convert (Scalar c) = let fromScalar' = fromScalar :: F r -> t (F r) in Foo $ fromScalar' $ toF c }}} Like #10195, this is triggered when a generic instance is in scope. The (main) problem of course is that GHC tries to match the generic instance instead of using the `T t (F r)` constraint supplied by `convert`. A secondary issue is that I think the example should have the same behavior pre- and post-instance, i.e either both should compile or both should not compile. I'm not sure if a monomorphism restriction is actually being triggered here or if that's just a red herring. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 13:31:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 13:31:19 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.b225fbfd559a1d92d745da10a294333f@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by chak): After some talk on the mailing list, there is a simple enough workaround. Just use `nm-classic`. Specifically, check whether `xcode-select -p`/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic or `xcode-select -p`/usr/bin/nm-classic exists. If yes, use that instead of ?nm?; otherwise, use ?nm? as usual. (You need to check for both, because the former is what comes with Xcode and the latter is what comes with the standalone command line tool package.) Printing decimal numbers instead of hex with the '-P' option still looks like an oversight, but I think that would need to be taken up with the LLVM maintainers, instead of trying to route through Apple (who are probably just going to point to 'nm-classic' anyway). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 14:05:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 14:05:48 -0000 Subject: [GHC] #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls In-Reply-To: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> References: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> Message-ID: <061.1e84f161eee54eda2ff0a35bb3649e6b@haskell.org> #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11338, #11337 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The problem is that you need both details from the code generator (to account for the unwind adjustments as described in this ticket) as well as the procedure's control flow graph (in order to push unwind information down to successor blocks). My current plan is, * Introduce a `UNWIND` pseudo-instruction * `CmmUnwind` nodes will be translated by the `UNWIND` instructions * Add a lazy field to `NEWBLOCK` which will capture the successors of the block * Introduce a pass after code generation which traverses the `[Instruction]` of each block and, * extract the `UNWIND` and `DELTA` instructions from a block's `[Instruction]` and use them to build a `LabelMap (UnwindTable, [SuccessorBlockId])` (the `SuccessorBlockId` being taken from the successors field of the block's `NEWBLOCK` instruction) * accumulate a `[BlockId]` to preserve the order in which we must emit unwinding tables (since they must be written in order of increasing address) * Introduce another pass of shape `LabelMap (UnwindTable, [SuccessorBlockId]) -> LabelMap UnwindTable` which pushes blocks' unwind tables "down" to their successors * Pass the resulting `UnwindTable`s to the existing unwinding table generation code -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 15:42:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 15:42:48 -0000 Subject: [GHC] #5683: bug in signum function In-Reply-To: <053.26d0d3539f88a72f2e9c735fa6c69f54@haskell.org> References: <053.26d0d3539f88a72f2e9c735fa6c69f54@haskell.org> Message-ID: <068.70699f8b94928ccc85efe1488a73b95b@haskell.org> #5683: bug in signum function -------------------------------------+------------------------------------- Reporter: tristes_tigres | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.1 Component: Prelude | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnw42): * status: closed => new * resolution: duplicate => Comment: Re-opening because it's not entirely a duplicate. Bug #3070 is blocked because of some fundamental issues with how Haskell handles floating- point, but I don't believe those issues preclude fixing the signum function to preserve NaN. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 15:58:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 15:58:22 -0000 Subject: [GHC] #5683: bug in signum function In-Reply-To: <053.26d0d3539f88a72f2e9c735fa6c69f54@haskell.org> References: <053.26d0d3539f88a72f2e9c735fa6c69f54@haskell.org> Message-ID: <068.27e0e03c784cb44dc20abd5bfff90764@haskell.org> #5683: bug in signum function -------------------------------------+------------------------------------- Reporter: tristes_tigres | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.1 Component: Prelude | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johnw42): Aside from preserving NaN, there's also a question of whether -0.0 should be mapped to 0.0 or left alone. IMHO it should be left unchanged because it permits a nice symmetric implementation: {{{#!hs signum x | x > 0 = 1 | x < 0 = -1 | otherwise = x }}} Aside: there's some good discussion [http://stackoverflow.com/questions/1986152/why-doesnt-python-have-a-sign- function here] of why Python has no signum function. I guess that ship has sailed for Haskell, but it makes me inclined to think there's no universally correct definition, which is why I think having a pretty implementation is as good a reason as any to settle on a definition for the edge cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 16:21:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 16:21:30 -0000 Subject: [GHC] #5683: bug in signum function In-Reply-To: <053.26d0d3539f88a72f2e9c735fa6c69f54@haskell.org> References: <053.26d0d3539f88a72f2e9c735fa6c69f54@haskell.org> Message-ID: <068.01f7802a9ccc3c48df8165a70d34884d@haskell.org> #5683: bug in signum function -------------------------------------+------------------------------------- Reporter: tristes_tigres | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Prelude | Version: 7.0.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: This was fixed in 7.10.1. `signum (-0.0)` is `-0.0` now as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 16:26:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 16:26:55 -0000 Subject: [GHC] #5683: bug in signum function In-Reply-To: <053.26d0d3539f88a72f2e9c735fa6c69f54@haskell.org> References: <053.26d0d3539f88a72f2e9c735fa6c69f54@haskell.org> Message-ID: <068.584b5bfacfa8e57c1e4d653c4d466c67@haskell.org> #5683: bug in signum function -------------------------------------+------------------------------------- Reporter: tristes_tigres | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Prelude | Version: 7.0.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tristes_tigres): Replying to [comment:12 rwbarton]: > This was fixed in 7.10.1. `signum (-0.0)` is `-0.0` now as well. Just tried it on haskell.org page signum(0.0/0.0) -1.0 :: Fractional a => a Doesn't look right to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 16:49:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 16:49:21 -0000 Subject: [GHC] #11725: Performance Regression from 7.8.3 to 7.10.3 In-Reply-To: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> References: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> Message-ID: <061.8ad1669b4e48f97ac6888c02d15dfac1@haskell.org> #11725: Performance Regression from 7.8.3 to 7.10.3 -------------------------------------+------------------------------------- Reporter: dominic | Owner: dominic Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): Good news! After a heroic battle fighting cabal, template-haskell, unnecessarily restrictive upper bounds and the ghc build system on OS X 10.11.3, in which the aforementioned almost won, I managed to get my test program to compile under ghc-8.0.1-rc2. Under ghc-7.10.2 (NB not comparable with the above as that was done on a different machine) I get {{{ Total time 12.764s ( 13.242s elapsed) }}} Under ghc-8.0.1-rc2 I get {{{ Total time 2.896s ( 3.290s elapsed) }}} So better even than 7.83. For info I ran my comparison of 7.8.3 against 7.10.3 on {{{ processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 63 model name : Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz stepping : 2 microcode : 0xffffffff cpu MHz : 2397.169 cache size : 30720 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx lm constant_tsc rep_good nopl eagerfpu pni pclmulqdq ss\ se3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm fsgsbase bmi1 avx2 smep bmi2 erms xsaveopt bugs : bogomips : 4794.33 clflush size : 64 cache_alignment : 64 address sizes : 42 bits physical, 48 bits virtual power management: }}} and I ran my comparison of 7.10.3 againt 8.0.1-rc2 on {{{ Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 16:52:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 16:52:07 -0000 Subject: [GHC] #11725: Performance Regression from 7.8.3 to 7.10.3 In-Reply-To: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> References: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> Message-ID: <061.733c4e6fdf35c48dc263feb68d6e3ce3@haskell.org> #11725: Performance Regression from 7.8.3 to 7.10.3 -------------------------------------+------------------------------------- Reporter: dominic | Owner: dominic Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): There seems little point in keeping this ticket open but how do we stop this sort of performance regression happening in the future? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 20:26:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 20:26:39 -0000 Subject: [GHC] #11754: Error in optCoercion In-Reply-To: <046.bab60c56aeea09df505e0c689289f35b@haskell.org> References: <046.bab60c56aeea09df505e0c689289f35b@haskell.org> Message-ID: <061.a4162c5ee83224e542ff706efa7f44ec@haskell.org> #11754: Error in optCoercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"4da8e73d5235b0000ae27aa8ff8438a3687b6e9c/ghc" 4da8e73/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4da8e73d5235b0000ae27aa8ff8438a3687b6e9c" Fix #11754 by adding an additional check. This was just plain wrong previously. Test case: typecheck/should_compile/T11754 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 20:26:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 20:26:39 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.4d1000936ad471b3b79530fbbf4921bd@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | dependent/should_fail/T11473 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"12a76bebe0864cdf1c9088ed16175d7b34369e24/ghc" 12a76be/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="12a76bebe0864cdf1c9088ed16175d7b34369e24" Check for rep poly on wildcard binders. I had just missed this case when adding my test. This is relevant to ticket #11473. Also adds lots of comments. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 20:28:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 20:28:01 -0000 Subject: [GHC] #11754: Error in optCoercion In-Reply-To: <046.bab60c56aeea09df505e0c689289f35b@haskell.org> References: <046.bab60c56aeea09df505e0c689289f35b@haskell.org> Message-ID: <061.04754b48ccc754b62ceb258c88338fdf@haskell.org> #11754: Error in optCoercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11754 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compile/T11754 * status: new => merge * version: 7.10.3 => 8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 20:29:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 20:29:12 -0000 Subject: [GHC] #11754: Error in optCoercion In-Reply-To: <046.bab60c56aeea09df505e0c689289f35b@haskell.org> References: <046.bab60c56aeea09df505e0c689289f35b@haskell.org> Message-ID: <061.14a56403f6fcd5af4911bc8e34d808f3@haskell.org> #11754: Error in optCoercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11754 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: TypeInType => Comment: Nothing to do with `TypeInType`. I think this was present in 7.10, but maybe impossible to tickle. Anyway, it was clearly wrong before and certainly seems fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 20:31:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 20:31:19 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.443553756154fae01e51f6cf7ded6a51@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | dependent/should_fail/T11473, | typecheck/should_fail/BadUnboxedTuple Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: closed => merge * testcase: dependent/should_fail/T11473 => dependent/should_fail/T11473, typecheck/should_fail/BadUnboxedTuple Comment: Found a corner case that wasn't handled in previous commit. Please merge for 8.0. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 20:56:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 20:56:21 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.eafcf47c76c600f680f76284bb913b51@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yech. I'm beginning to believe that there is something wonky about the instantiation check. As it stands, the check forbids (or tries to) only visible parameters from being instantiated. But in the `TypeInType` world, there's not a rigid difference between visible parameters and invisible ones. It used to be that any parameter upon which another parameter depends (that is, a kind variable) must be invisible. That's not the case now. So doing a check like this based on visibility seems wrong. We could, potentially, do it based on dependency -- it's not so hard figure out which parameters are dependent. And indeed this information is readily available by looking at a `tyConBinders`: the `Named` ones are dependent, and the `Anon` ones are not. This should be as true for a data instance tycon as any other. So perhaps that's the way forward, and it explains why everything up to now has been just wrong: we were doing the wrong check. We were checking for visibility when we meant to check for dependency. So perhaps the check looks something like {{{ if (all isTyVarTy [ arg | (arg, binder) <- tc_args `zip` tyConBinders tc , isAnonBinder binder ]) ... }}} No more fussing with `filterOutInvisibleTypes` and no more bothering with `mkFamilyTyConApp`. Before blindly trying this, though, I'd love someone (Ryan, it seems) who understands Generics to consider what this instantiation check is really trying to do, and why it (previously) avoided looking at kinds. And why it makes sense to look at dependency, as I've proposed here. I've no real clue what's going on, and when I deleted `isKind` (which was what was used previously) I just reached for the closest thing, which was visibility. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 26 21:57:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Mar 2016 21:57:16 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.01b0a35c88b39926905ee218d2462a26@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:6 goldfire]: > Before blindly trying this, though, I'd love someone (Ryan, it seems) who understands Generics to consider what this instantiation check is really trying to do, and why it (previously) avoided looking at kinds. And why it makes sense to look at dependency, as I've proposed here. I've no real clue what's going on, and when I deleted `isKind` (which was what was used previously) I just reached for the closest thing, which was visibility. As I noted [https://ghc.haskell.org/trac/ghc/ticket/11732?replyto=6#comment:1 here], the reason why `gen_Generic_binds` seems to need the instantiation check at the moment is a matter of implementation practicality. Deriving `Generic(1)` is different from any other derived classes in that in generates a type family instance (`Rep`/`Rep1`), so it needs to be able to faithfully reproduce the the same type as what the user provides. GHC's current mechanism for retrieving the type is by examining the `TyCon` (see [http://git.haskell.org/ghc.git/blob/9f73e46c0f34b8b5e8318e6b488b7dade7db68e3:/compiler/typecheck/TcGenGenerics.hs#l482 here] for the code). As a result, GHC only has knowledge of the `tyConTyVars` [http://git.haskell.org/ghc.git/blob/9f73e46c0f34b8b5e8318e6b488b7dade7db68e3:/compiler/typecheck/TcGenGenerics.hs#l384 on the LHS] and [http://git.haskell.org/ghc.git/blob/9f73e46c0f34b8b5e8318e6b488b7dade7db68e3:/compiler/typecheck/TcGenGenerics.hs#l539 on the RHS] of the derived `Rep(1)` instance. If any of those type variables were to be instantiated to a concrete type, it would result in an apparent mismatch between the instance head and the generated `Rep(1)` instance (the subject of ticket #5939), e.g., {{{#!hs data T a b c = T a b c deriving instance Generic (T a Bool c) ==> instance Generic (T a Bool c) where type Rep (T a b c) = a :*: b :*: c -- wrong? }}} But interestingly, it's possible to have this kind of mismatch with clever use of `-XTypeInType`. There's the example in the ticket description, plus this: {{{ ?> :set -XDeriveGeneric -XTypeInType -ddump-deriv ?> import Data.Proxy ?> data P (a :: k) = P (Proxy k) deriving Generic1 ==================== Derived instances ==================== Derived instances: instance GHC.Generics.Generic1 Ghci3.P where GHC.Generics.from1 (Ghci3.P g1_a2b8) = GHC.Generics.M1 (GHC.Generics.M1 (GHC.Generics.M1 (GHC.Generics.K1 g1_a2b8))) GHC.Generics.to1 (GHC.Generics.M1 (GHC.Generics.M1 (GHC.Generics.M1 g1_a2b9))) = Ghci3.P (GHC.Generics.unK1 g1_a2b9) GHC.Generics representation types: type GHC.Generics.Rep1 Ghci3.P = GHC.Generics.D1 ('GHC.Generics.MetaData "P" "Ghci3" "interactive" 'GHC.Types.False) (GHC.Generics.C1 ('GHC.Generics.MetaCons "P" 'GHC.Generics.PrefixI 'GHC.Types.False) (GHC.Generics.S1 ('GHC.Generics.MetaSel 'GHC.Base.Nothing 'GHC.Generics.NoSourceUnpackedness 'GHC.Generics.NoSourceStrictness 'GHC.Generics.DecidedLazy) (GHC.Generics.Rec0 (Data.Proxy.Proxy k_a2b7)))) ?> :kind! Rep1 P Rep1 P :: * -> * = D1 ('MetaData "P" "Ghci3" "interactive" 'False) (C1 ('MetaCons "P" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 (Proxy *)))) }}} Notice how the generated `Rep1 P` instance mentions kind `k_a2b7` when it should be `*`. This probably shouldn't typecheck, but it does... So we really have two issues here: 1. `gen_Generic_binds` doesn't do any type variable substitution in the generated `Rep1` instance. 2. A `deriving Generic1` clause might instantiate more type variables than what would be desirable in a generated `Generic1` instance. Fixing (1) might be doable with some `Type`-related subtitution sorcery. Fixing (2) requires figuring out when a substitution is "undesirable". * In #5939, Pedro [https://ghc.haskell.org/trac/ghc/ticket/5939#comment:2 decided] to make an instantiation of a //type// variable in a `Generic(1)` instance was bad, even in the presence of `-XStandaloneDeriving`. Kinds were excluded from this discussion since, at the time, you couldn't put kinds at the type level. * Alternatively, we could be ultra-permissive and allow //any// type variables to be instantiated when deriving `Generic(1)`, both standalone and using a `deriving` clause. This should be sound (I think) if (1) gets fixed. * You [https://ghc.haskell.org/trac/ghc/ticket/11732?replyto=6#comment:2 proposed] a scheme wherein instantiating type/kind variables in a `Generic(1)` instance is OK with `-XStandaloneDeriving`, but not with just a `deriving` clause. I'd be fine with any approach. But if we picked the first or last option, now that types and kinds are merged, we'd have to figure out a better distinction between what type variables are and aren't allowed to be instantiated in such an instance. Your suggestion of only checking dependent type variables would only be feasible with the third option, I believe, because combining that check with the first option would cause [https://ghc.haskell.org/trac/ghc/ticket/5939#comment:1 this program] to be erroneously accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 27 09:35:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Mar 2016 09:35:48 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.0b881cde85fb47b43d8644b3cb1d22d1@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: andres@? (added) Comment: I can offer only an uninformed opinion on the design question, but that opinion is to be permissive (option 2). It sounds like you're saying it's possible and sound. It also seems that issue (1) needs to be fixed regardless. So why not be permissive? I'm also include Andres on this, as I believe he cares about generics, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 27 13:03:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Mar 2016 13:03:45 -0000 Subject: [GHC] #11339: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> References: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> Message-ID: <057.94b27a4c649832dc5905baf0880e7ee3@haskell.org> #11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Artyom.Kazak): * cc: Artyom.Kazak (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 27 14:46:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Mar 2016 14:46:07 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.bd386cceda75e7a9cebbdf993b2671b3@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Interesting, you'd be alright with the second option? I like that idea since it requires //zero// instantiation checks, but you did object to it earlier: > I claim that > > {{{ > data Proxy k (a :: k) = ProxyCon deriving Generic1 > }}} > > should fail outright. I don't think GHC should be in the business of inferring values for visible parameters like `k`, even when it could. Instead, it should be this: > > {{{ > deriving instance Generic1 (Proxy *) > }}} > > Note that this applies to `Functor` as much as it does to `Generic1`. ... > But > > {{{ > data Proxy k (a :: k) deriving Functor > }}} > > would try instance `Functor (Proxy k)`, which is ill-kinded. GHC is surely clever enough to figure out that it should really do instance `Functor (Proxy *)`, but I think it should refrain from doing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 27 19:57:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Mar 2016 19:57:38 -0000 Subject: [GHC] #11759: can't decompose ghc.exe path Message-ID: <045.78646c85aa5779cba5b2cf0a5492deb5@haskell.org> #11759: can't decompose ghc.exe path --------------------------------------+---------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- {{{ erisco at ERICWIN C:\Users\erisco\haskell-platform-bin $ ghc.exe ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): can't decompose ghc.exe path: "C:\\Users\\erisco\\haskell- platform-bin\\ghc.exe" }}} haskell-platform-bin is a symbolic directory link to "C:\Program Files\Haskell Platform\2014.2.0.0\bin". I did this so there would not be spaces in the path because this is causing other issues for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 27 20:54:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Mar 2016 20:54:26 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.cd33768a9a00c7e59faf273a959b4595@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): I just tried this on x86_64 Debian with ghc-7.10.3 (installed from Debian) and it seems to run fine. At the end I get {{{ 2 1 1 OK (10.16s) +++ OK, passed 100 tests. All 2 tests passed (20.32s) }}} Tried three runs without a single hang. Debian applies a couple of patches to the official GHC 7.10.3 tarball. Those patches are in the file http://ftp.debian- ports.org/debian/pool/main/g/ghc/ghc_7.10.3-7.debian.tar.xz . I've had a brief look at those patches, but none of them seem relevant to this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 27 22:03:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Mar 2016 22:03:57 -0000 Subject: [GHC] #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls In-Reply-To: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> References: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> Message-ID: <061.1851602d7c7fc0200aa63af6dc92cee0@haskell.org> #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11338, #11337 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by scpmw): Not sure why you are worrying about the order - that gets derived from the NCG output using cmmDebugLink. This is precisely so NCG is free to do whatever it wants with blocks, even reorder or optimise them out. My first impulse here would be that you will need some sort of `UNWIND` anyway to have NCG create labels. So maybe have it carry its unwind rules, that would allow NCG to update it. In either case, you would feed that information back roughly the same way that currently `ngs_labels` gets threaded back to debug information generation. As `UNWIND` would carry unique labels, this could just be replacing the current `[Label]` block list with an an ordered `[(Label, [UnwindTable])]` debug label to unwind table map. Not sure - this is exactly the kind of complexity that I tried my best to avoid, so I haven't put a lot of thought into it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 27 22:56:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Mar 2016 22:56:26 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.b0a5772a37b8e9db99c57cf881689cae@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by orion): I just reproduced this on FreeBSD. What follows is the output from cabal freeze --enable-tests: {{{ constraints: QuickCheck ==2.8.2, ansi-terminal ==0.6.2.3, ansi-wl-pprint ==0.6.7.3, array ==0.5.1.0, async ==2.1.0, base ==4.8.2.0, binary ==0.7.5.0, bytestring ==0.10.6.0, clock ==0.6.0.1, containers ==0.5.6.2, deepseq ==1.4.1.1, directory ==1.2.2.0, filepath ==1.4.0.0, ghc-prim ==0.4.0.0, integer-gmp ==1.0.0.0, mtl ==2.2.1, optparse-applicative ==0.12.1.0, parsec ==3.1.9, pretty ==1.1.2.0, primitive ==0.6.1.0, process ==1.2.3.0, random ==1.1, regex-base ==0.93.2, regex-tdfa-rc ==1.1.8.3, rts ==1.0, stm ==2.4.4.1, tagged ==0.8.3, tasty ==0.11.0.2, tasty-quickcheck ==0.8.4, template-haskell ==2.10.0.0, text ==1.2.2.1, tf-random ==0.5, time ==1.5.0.1, transformers ==0.4.2.0, transformers-compat ==0.5.1.4, unbounded-delays ==0.1.0.9, unix ==2.7.1.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 27 23:04:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Mar 2016 23:04:20 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.c40c4baa1112b07a1d7bdca802852252@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Even with the cabal.config file provided by @orion it still doesn't hang on my system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 27 23:12:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Mar 2016 23:12:53 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.2bd1af152ad15b196f91d64e69b4691f@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): My first try at reproducing this hang failed because I didn't read the ticket. The secret is configuring with `-fbad` as follows: {{{ $ cabal configure --enable-tests -fbad }}} With that I got the hang reported by @orion. I then added `-threaded` to the cabal files `ghc-options` line for the `properties` target and now it no longer hangs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 27 23:17:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Mar 2016 23:17:22 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.0ed92e10031365bdd58fe8e375009938@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): @bgamari Is this really a bug? To me (possibly because I've hit this problem before) its not too surprising that use of `MVar`s and `STM` requires use of the threaded RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 00:28:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 00:28:50 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.c2eb51fbd2368f21f88a7b5926084c73@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): If I change the program so that it no longer runs the tests via QuickCheck as follows: {{{ {-# LANGUAGE OverloadedStrings, CPP #-} module Main where import Imports import Control.Concurrent import Control.Concurrent.Async import Data.ByteString instance Arbitrary ByteString where arbitrary = pack <$> arbitrary doFoo :: Bool -> Int -> ByteString -> (ByteString -> IO ()) -> (IO ByteString) -> IO ByteString doFoo _ 0 g _ _ = return g doFoo b i g w r = if b then do w g doFoo False (i-1) g w r else do f <- r doFoo True (i-1) f w r prop :: ByteString -> IO Bool prop x = do chan <- newChan let w s = writeChan chan s r = readChan chan (y, z) <- concurrently (doFoo True 10 x w r) (doFoo False 10 x w r) return $ y == z main :: IO () main = print =<< prop "Hello" }}} then when the program runs it terminates with: {{{ properties: thread blocked indefinitely in an MVar operation }}} Interestingly, it does that regardless of whether the program is compiled with `-threaded` or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 00:57:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 00:57:39 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.29a267462ade26d6c69d5a4309e6b89c@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Went away and did something else and then it occured to me that QuickCheck must be silently swallowing the "blocked MVar" exception. Looking at the code for `readChan` and `writeChan` from `Control.Concurrent.Chan` we can see that they are implemented with `MVars`. Interestingly, the docs for `Control.Concurrent.MVar` do warn about "race conditions, deadlocks or uncaught exceptions", but the docs for `Control.Concurrent.Chan` do not reflect this, and neither do they mention the `STM` implementation of channels in `Control.Concurrent.STM.TChan` which are far more robust than the `MVar` version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 08:26:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 08:26:44 -0000 Subject: [GHC] #11760: runST with lazy blackholing breaks referential transparency Message-ID: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> #11760: runST with lazy blackholing breaks referential transparency -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A thunk created with `runST` can be evaluated twice by different threads producing different results. An example (taken from https://twitter.com/obadzz/status/714081240475951105): {{{#!hs {-# LANGUAGE RecordWildCards #-} import qualified Data.STRef.Lazy as S import Control.Monad import Control.Monad.ST.Lazy import Control.Concurrent data ListRef s a = ListRef { element :: a , readCounter :: Int , rest :: Maybe (S.STRef s (ListRef s a)) } toList :: S.STRef s (ListRef s a) -> ST s [(a, Int)] toList r = do ListRef{..} <- S.readSTRef r S.modifySTRef r $ \e -> e { readCounter = readCounter + 1 } xs <- maybe (return []) toList rest return $ (element, readCounter) : xs circularList :: ST s (S.STRef s (ListRef s Char)) circularList = do x3 <- S.newSTRef (ListRef 'c' 0 Nothing) x2 <- S.newSTRef (ListRef 'b' 0 (Just x3)) x1 <- S.newSTRef (ListRef 'b' 0 (Just x2)) S.modifySTRef x3 $ \e -> e { rest = Just x1 } return x1 l :: [(Char, Int)] l = take 15 $ runST $ circularList >>= toList main :: IO () main = do void $ forkIO $ print l void $ forkIO $ print l void getLine print l }}} The output (run multiple times to reproduce): {{{ $ ghc --make -O -threaded -outputdir=.build test.hs [1 of 1] Compiling Main ( test.hs, .build/Main.o ) Linking test ... $ ./test +RTS -N2 [('b',0),('b',0),('c',0),('b',1),('b',1),('c',1),('b',2),('b',2),('c',2),('b',3),('b',3),('c',3),('b',5),('b',4),('c',4)] [('b',0),('b',0),('c',0),('b',1),('b',1),('c',1),('b',2),('b',2),('c',2),('b',3),('b',3),('c',3),('b',4),('b',4),('c',4)] [('b',0),('b',0),('c',0),('b',1),('b',1),('c',1),('b',2),('b',2),('c',2),('b',3),('b',3),('c',3),('b',4),('b',4),('c',4)] $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 $ }}} Note that the last 3 elements are `('b',5),('b',4),('c',4)` or `('b',4),('b',4),('c',4)`. I was able to reproduce it with few weeks old HEAD. With `-feager- blackholing` it works as expected. `unsafePerformIO` uses `noDuplicate` to prevent such kind of issue. Should `runST` do something similar? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 08:39:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 08:39:05 -0000 Subject: [GHC] #11733: Undeclared identifier 'CLOCK_PROCESS_CPUTIME_ID' on OS X In-Reply-To: <044.34d6ef1f50509835f04a609c09b1a0b3@haskell.org> References: <044.34d6ef1f50509835f04a609c09b1a0b3@haskell.org> Message-ID: <059.b5d712bc010b46b576bfaaae2f928f1e@haskell.org> #11733: Undeclared identifier 'CLOCK_PROCESS_CPUTIME_ID' on OS X -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed Comment: This has been fixed and is currently not applicable to the ghc-8.0 branch as the problem it fixes is not yet on the ghc-8.0 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 09:35:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 09:35:29 -0000 Subject: [GHC] #11729: `make sdist` target fails horribly if `lndir` is unavailable In-Reply-To: <044.fb56a4d177682d7be236a48a26caf9dc@haskell.org> References: <044.fb56a4d177682d7be236a48a26caf9dc@haskell.org> Message-ID: <059.f102180a1c91a4e98ba7f97aa123ef62@haskell.org> #11729: `make sdist` target fails horribly if `lndir` is unavailable -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => wontfix Comment: Not sure of this is worth keeping open. It may be possible to detect its availablity and print an error message during `make sdist` when its missing, but I'm not sure if the effort is worth it. Very few ghc devs actually do `make sdist` and those that do should remember than `lndir` is required. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 10:11:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 10:11:15 -0000 Subject: [GHC] #11761: autoconf 2.69 breaks configure Message-ID: <046.026016968a0f00c4ea3dfc0c8c115a55@haskell.org> #11761: autoconf 2.69 breaks configure -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- linux ppc64 buildbot reveals interesting issue which shows as following while running configure: {{{ ./configure: line 561: save_bash_input: buffer already exists for new fd 417 }}} it looks like this issue is presented in configure only when configure is generated by autoconf 2.69. On the same platform hand installed autoconf 2.68 produces working configure. I guess this is multi-platform so I do not mark platform here. Also as this is in 3th party package I'm reporting this just for the reference of known issue... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 11:01:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 11:01:22 -0000 Subject: [GHC] #11231: GHC's configure script does not honour CC env var In-Reply-To: <042.d7426d5dc7b5e5db91b935fc98bce267@haskell.org> References: <042.d7426d5dc7b5e5db91b935fc98bce267@haskell.org> Message-ID: <057.cbaf00431bf4b8c9587e1a112ec64fcd@haskell.org> #11231: GHC's configure script does not honour CC env var -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9983 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"ffc802e8f617d11de9ece7bed438725bde0300b8/ghc" ffc802e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ffc802e8f617d11de9ece7bed438725bde0300b8" Drop Xcode 4.1 hack and fix ignored CC var issue Xcode 4.1 was released back in 2011 for Mac OSX 10.6/10.7. However, OSX 10.7 reached EOL sometime around the end of 2014. So this `--with-gcc-4.2` hack shouldn't be needed anymore. Moreover, this patch changes ./configure to honor the CC env-var again (and thus fix #11231) while giving `--with-gcc=...` a higher priority over `CC=...`. So the following 3 invocations are equivalent now: CC=... ./configure ./configure CC=... ./configure --with-gcc=... Since `--with-{gcc,clang}=...` is a misnomer (as is made apparent by `--with-gcc=clang` or `--with-clang=gcc`), this would give us a neutral and idiomatic way to tell ./configure which C compiler to use. Moreover, `./configure --help` says at the end of its output: Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L if you have libraries in a nonstandard directory LIBS libraries to pass to the linker, e.g. -l CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory CPP C preprocessor Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. Consequently, by honoring CC=... (rather than ignoring it) we increase consistency and reduce user confusion. Ideally, CC=... would become the recommended way to set the C compiler, and `--with-{clang,gcc}=...` would be demoted to legacy aliases. Reviewed By: erikd, bgamari Differential Revision: https://phabricator.haskell.org/D2046 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 11:13:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 11:13:25 -0000 Subject: [GHC] #11231: GHC's configure script does not honour CC env var In-Reply-To: <042.d7426d5dc7b5e5db91b935fc98bce267@haskell.org> References: <042.d7426d5dc7b5e5db91b935fc98bce267@haskell.org> Message-ID: <057.10f50c9b10cf8948c7c870e6b5a1f75a@haskell.org> #11231: GHC's configure script does not honour CC env var -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9983 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => merge * version: 7.11 => 7.10.3 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 12:43:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 12:43:56 -0000 Subject: [GHC] #10886: Remove the magic from `Any` In-Reply-To: <047.f678cbb73069d1c6ee1f63fe7d449257@haskell.org> References: <047.f678cbb73069d1c6ee1f63fe7d449257@haskell.org> Message-ID: <062.4fcf4d9bb40f49e0b0d0cd20cc83f79f@haskell.org> #10886: Remove the magic from `Any` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2049 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2049 @@ -8,1 +8,1 @@ - {{{ + {{{#!hs New description: The `Any` type used to be very highly magical: a poly-kinded type in a mono-kinded world. Then it became only normally magical: a datatype with a return kind of `k` (instead of `*`). Then it became only a bit magical: a closed type family with no equations. Now that we have non-magical empty closed type families, I believe that we can remove the last bit of magic and just define {{{#!hs type family Any :: k where { } }}} somewhere (`GHC.Types`?), wire it in (like, e.g., `Bool`), and be done with it. Objections? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 12:47:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 12:47:53 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.636deb7a02d121b70b54c6fdd5322b14@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ah, yes, good point. Perhaps I take back that point, then. :) Or, even better, we should ask others for advice. I'll do that shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 12:57:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 12:57:26 -0000 Subject: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC In-Reply-To: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> References: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> Message-ID: <059.36c64350b6cb14c5dc7e5f17995e3680@haskell.org> #4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: kaiha Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2258 | Differential Rev(s): Phab:D2021 Wiki Page: | -------------------------------------+------------------------------------- Comment (by kaiha): Replying to [comment:26 Phyx-]: > Hmm these test break on Windows since they don't properly take note of the application suffix. e.g. on Windows It needs to check for "T4114a.exe" instead of "T4114a". I have uploaded [https://phabricator.haskell.org/D2050 D2050] with a fix for the failing test on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 12:59:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 12:59:39 -0000 Subject: [GHC] #11757: Turn on (and require) C99/C11 mode by default In-Reply-To: <042.cdde255506f2bc07285d1fee6acec3cf@haskell.org> References: <042.cdde255506f2bc07285d1fee6acec3cf@haskell.org> Message-ID: <057.edb6d358a265444483834de336186642@haskell.org> #11757: Turn on (and require) C99/C11 mode by default -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"afc48f8939b99a1a72b43b3e342d56193ed1f34c/ghc" afc48f8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="afc48f8939b99a1a72b43b3e342d56193ed1f34c" Autoconf: detect and set CFLAGS/CPPFLAGS needed for C99 mode This is the first phase of addressing #11757 which aims to make C99 support a base-line requirement for GHC and clean up the code-base to use C99 facilities when sensible. This patch exploits the logic/heuristic used by `AC_PROG_CC_C99` to determine the flags needed in case the C compiler isn't able to compile C99 code in its current mode. We can't use `AC_PROG_CC_C99` directly though because GHC's build-system expects CC to contain a filename without any flags, while `AC_PROG_CC_C99` would e.g. result in `CC="gcc -std=gnu99"`. Morever, we support different `CC`s for stage0/1/2, so we need a version of `AC_PROG_CC_C99` for which we can specify the `CC`/`CFLAGS` variables to operate on. This is what `FP_SET_CFLAGS_C99` does. Note that Clang has been defaulting to C99+ for a long time, while GCC 5 defaults to C99+ as well. So this has mostly an affect on older GCCs versions prior to 5.0 and possibly compilers other than GCC/Clang (which are not officially supported for building GHC anyway). Reviewers: kgardas, erikd, bgamari, austin Reviewed By: erikd Differential Revision: https://phabricator.haskell.org/D2045 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 13:05:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 13:05:47 -0000 Subject: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC In-Reply-To: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> References: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> Message-ID: <059.34895df269502221b88aa2c59abd23c6@haskell.org> #4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: kaiha Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2258 | Differential Rev(s): Phab:D2021 Wiki Page: | Phab:D2050 -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: Phab:D2021 => Phab:D2021 Phab:D2050 Comment: Thanks for the quick fix @kaiha! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 13:17:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 13:17:10 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.2acbee4a379351f1ed9189ca2298582a@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 10458 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): Replying to [comment:7 trommler]: > This will be fixed as part of #10458. Seeing as #10458 is now closed, does this mean this ticket should be closed too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 13:19:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 13:19:50 -0000 Subject: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC In-Reply-To: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> References: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> Message-ID: <059.8fe341ba9fa081275e4abe83af600e1b@haskell.org> #4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: kaiha Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2258 | Differential Rev(s): Phab:D2021 Wiki Page: | Phab:D2050 -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"49b9d80a4666504f3f3524928c9ae7cc436bb8ba/ghc" 49b9d80a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="49b9d80a4666504f3f3524928c9ae7cc436bb8ba" Do not test for existence of the executable Summary: The test for the existence of the executable breaks on MS Windows. It is furthermore needless, because if the test can be executed the executable is obviously there. Reviewers: austin, bgamari, Phyx Reviewed By: Phyx Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2050 GHC Trac Issues: #4114 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 14:02:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 14:02:41 -0000 Subject: [GHC] #11231: GHC's configure script does not honour CC env var In-Reply-To: <042.d7426d5dc7b5e5db91b935fc98bce267@haskell.org> References: <042.d7426d5dc7b5e5db91b935fc98bce267@haskell.org> Message-ID: <057.6ef9f81b24f137a9f9b7f9d35f722c49@haskell.org> #11231: GHC's configure script does not honour CC env var -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9983 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I think some of the other variables in that output you mention do not actually work either, so just fixing `CC` doesn't really reduce user confusion overall. This doesn't fix a real bug, so does it really make sense to merge this to 8.0? How much testing have you done in unusual configurations, e.g., cross-compiling? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 14:13:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 14:13:27 -0000 Subject: [GHC] #11762: GHC 8 superclass chain constraint regression Message-ID: <048.8d3f15d8dce49f095c6c78ab934bfbaf@haskell.org> #11762: GHC 8 superclass chain constraint regression -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems that GHC 8 regresses with regard to GHC 7.10, when it tries to satisfy the constraints, implied by instance context. The following does not build on GHC 8.0.1 RC2, but does on 7.10.3: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} --{-# LANGUAGE UndecidableSuperClasses #-} -- this doesn't matter {-# LANGUAGE UnicodeSyntax #-} module Foo where class Super a class Super a ? Left a class Super a ? Right a instance (Left a) ? Right a }}} the error being: > ? Could not deduce (Super a) > arising from the superclasses of an instance declaration > from the context: Left a > bound by the instance declaration > at repro.hs:9:10-27 > Possible fix: > add (Super a) to the context of the instance declaration > ? In the instance declaration for ?Right a? It also /roughly/ seems that https://phabricator.haskell.org/D1594 could possibly be related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 14:17:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 14:17:50 -0000 Subject: [GHC] #11756: Data.Functor.Classes instances for Proxy In-Reply-To: <049.88e00c8489fafead34a109f21260f2c7@haskell.org> References: <049.88e00c8489fafead34a109f21260f2c7@haskell.org> Message-ID: <064.2f6658f9dcb656d3353bbf47a587bcdc@haskell.org> #11756: Data.Functor.Classes instances for Proxy -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I've added a differential for this on phabricator: https://phabricator.haskell.org/D2051 It's my first time using phabricator and arcanist, so I probably did something wrong. Feel free to point out any conventions that I missed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 14:18:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 14:18:25 -0000 Subject: [GHC] #11756: Data.Functor.Classes instances for Proxy In-Reply-To: <049.88e00c8489fafead34a109f21260f2c7@haskell.org> References: <049.88e00c8489fafead34a109f21260f2c7@haskell.org> Message-ID: <064.1652986da6a358386d132c357b3956c3@haskell.org> #11756: Data.Functor.Classes instances for Proxy -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2051 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2051 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 15:02:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 15:02:39 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.7f7be45b6e03f7d8c2cf8f387ea7e2cf@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * blockedby: 10458 => 11238 Comment: Replying to [comment:8 mboes]: > Replying to [comment:7 trommler]: > > This will be fixed as part of #10458. > > Seeing as #10458 is now closed, does this mean this ticket should be closed too? Unfortunately no. This ticked should be blocked by #11238 now. In #10458 I originally planned to rework dynamic linking but then we settled for a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 15:29:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 15:29:53 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.fd5cd11a4db932ccb125d6f901c2975d@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"eb25381da2e4a95337ad9c2fabff60d699b41bc7/ghc" eb25381d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eb25381da2e4a95337ad9c2fabff60d699b41bc7" Update bytestring submodule to latest snapshot Most notably, this pulls in the following changes > Fix breakByte and spanByte rewrite rules > Implement `stripPrefix`/`stripSuffix` The first patch is related to #11688 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 15:44:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 15:44:02 -0000 Subject: [GHC] #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation Message-ID: <042.d49c422577da41f5c4d9261d67e3806a@haskell.org> #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10970 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since a9c93bdd8b027d6de09a3eada7721e7fd2d3e050 / #10970 GHC is able to generate `MIN_VERSION_...` and `VERSION_...` natively without Cabal's help. Currently, this feature is currently triggered by `-hide-all-packages`. However, additionally, it seems reasonable to be able to control this more explicitly. E.g. either to be able to explicitly disable even if `-hide- all-packages` implicitly enabled the macros, as well as be able to explicitly request macro generation for currently visible packages even without any `-hide-all-package`/`-package` flags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 15:52:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 15:52:13 -0000 Subject: [GHC] #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation In-Reply-To: <042.d49c422577da41f5c4d9261d67e3806a@haskell.org> References: <042.d49c422577da41f5c4d9261d67e3806a@haskell.org> Message-ID: <057.3bc3259867ce9d6ab76dfd075c700dfe@haskell.org> #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10970 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I thought this was already fixed to always generate the macros? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 15:57:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 15:57:47 -0000 Subject: [GHC] #11762: GHC 8 superclass chain constraint regression In-Reply-To: <048.8d3f15d8dce49f095c6c78ab934bfbaf@haskell.org> References: <048.8d3f15d8dce49f095c6c78ab934bfbaf@haskell.org> Message-ID: <063.4aea37366cc0295f24a8c90aba978945@haskell.org> #11762: GHC 8 superclass chain constraint regression -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * failure: None/Unknown => GHC rejects valid program * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 16:12:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 16:12:29 -0000 Subject: [GHC] #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation In-Reply-To: <042.d49c422577da41f5c4d9261d67e3806a@haskell.org> References: <042.d49c422577da41f5c4d9261d67e3806a@haskell.org> Message-ID: <057.30c2d0ec5715ab3f0bdb7886366ea3b9@haskell.org> #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10970 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:1 rwbarton]: > I thought this was already fixed to always generate the macros? even in that case (which doesn't seem to be the case with a current GHC HEAD snapshot), we want the ability to explicitly say `-fno-version- macros` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 18:15:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 18:15:52 -0000 Subject: [GHC] #11764: ghc internal error building llvm-general-3.5.1.2 Message-ID: <049.1e7850c7fbe53a08db3314e9a97a33fc@haskell.org> #11764: ghc internal error building llvm-general-3.5.1.2 -------------------------------------+------------------------------------- Reporter: andrew.wja | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: cabal install | Blocked By: llvm-general | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- $ cabal install llvm-general Resolving dependencies... Configuring llvm-general-3.5.1.2... Building llvm-general-3.5.1.2... Failed to install llvm-general-3.5.1.2 Build log ( /home/andrew/.cabal/logs/llvm-general-3.5.1.2.log ): [1 of 1] Compiling Main ( /tmp/cabal-tmp-12630/llvm- general-3.5.1.2/dist/setup/setup.hs, /tmp/cabal-tmp-12630/llvm- general-3.5.1.2/dist/setup/Main.o ) Linking /tmp/cabal-tmp-12630/llvm-general-3.5.1.2/dist/setup/setup ... Configuring llvm-general-3.5.1.2... Building llvm-general-3.5.1.2... Preprocessing library llvm-general-3.5.1.2... [ 1 of 93] Compiling LLVM.General.Internal.FFI.ByteRangeCallback ( src/LLVM/General/Internal/FFI/ByteRangeCallback.hs, dist/build/LLVM/General/Internal/FFI/ByteRangeCallback.o ) [ 2 of 93] Compiling LLVM.General.Internal.FFI.Transforms ( src/LLVM/General/Internal/FFI/Transforms.hs, dist/build/LLVM/General/Internal/FFI/Transforms.o ) [ 3 of 93] Compiling LLVM.General.Internal.Inject ( src/LLVM/General/Internal/Inject.hs, dist/build/LLVM/General/Internal/Inject.o ) [ 4 of 93] Compiling LLVM.General.Internal.FFI.Context ( src/LLVM/General/Internal/FFI/Context.hs, dist/build/LLVM/General/Internal/FFI/Context.o ) [ 5 of 93] Compiling LLVM.General.Internal.FFI.CommandLine ( src/LLVM/General/Internal/FFI/CommandLine.hs, dist/build/LLVM/General/Internal/FFI/CommandLine.o ) [ 6 of 93] Compiling LLVM.General.Internal.FFI.Iterate ( src/LLVM/General/Internal/FFI/Iterate.hs, dist/build/LLVM/General/Internal/FFI/Iterate.o ) [ 7 of 93] Compiling LLVM.General.Internal.FFI.PtrHierarchy ( src/LLVM/General/Internal/FFI/PtrHierarchy.hs, dist/build/LLVM/General/Internal/FFI/PtrHierarchy.o ) [ 8 of 93] Compiling LLVM.General.Internal.FFI.BasicBlock ( src/LLVM/General/Internal/FFI/BasicBlock.hs, dist/build/LLVM/General/Internal/FFI/BasicBlock.o ) [ 9 of 93] Compiling LLVM.General.Internal.FFI.User ( src/LLVM/General/Internal/FFI/User.hs, dist/build/LLVM/General/Internal/FFI/User.o ) [10 of 93] Compiling LLVM.General.Internal.FFI.GlobalAlias ( src/LLVM/General/Internal/FFI/GlobalAlias.hs, dist/build/LLVM/General/Internal/FFI/GlobalAlias.o ) [11 of 93] Compiling LLVM.General.Internal.FFI.LLVMCTypes ( dist/build/LLVM/General/Internal/FFI/LLVMCTypes.hs, dist/build/LLVM/General/Internal/FFI/LLVMCTypes.o ) [12 of 93] Compiling LLVM.General.Internal.FFI.Attribute ( src/LLVM/General/Internal/FFI/Attribute.hs, dist/build/LLVM/General/Internal/FFI/Attribute.o ) [13 of 93] Compiling LLVM.General.Internal.FFI.GlobalValue ( src/LLVM/General/Internal/FFI/GlobalValue.hs, dist/build/LLVM/General/Internal/FFI/GlobalValue.o ) [14 of 93] Compiling LLVM.General.Internal.FFI.Instruction ( src/LLVM/General/Internal/FFI/Instruction.hs, dist/build/LLVM/General/Internal/FFI/Instruction.o ) [15 of 93] Compiling LLVM.General.Internal.FFI.Type ( src/LLVM/General/Internal/FFI/Type.hs, dist/build/LLVM/General/Internal/FFI/Type.o ) [16 of 93] Compiling LLVM.General.Internal.FFI.Value ( src/LLVM/General/Internal/FFI/Value.hs, dist/build/LLVM/General/Internal/FFI/Value.o ) [17 of 93] Compiling LLVM.General.Internal.FFI.BinaryOperator ( src/LLVM/General/Internal/FFI/BinaryOperator.hs, dist/build/LLVM/General/Internal/FFI/BinaryOperator.o ) [18 of 93] Compiling LLVM.General.Internal.FFI.DataLayout ( src/LLVM/General/Internal/FFI/DataLayout.hs, dist/build/LLVM/General/Internal/FFI/DataLayout.o ) [19 of 93] Compiling LLVM.General.Internal.FFI.SMDiagnostic ( src/LLVM/General/Internal/FFI/SMDiagnostic.hs, dist/build/LLVM/General/Internal/FFI/SMDiagnostic.o ) [20 of 93] Compiling LLVM.General.Internal.FFI.Module ( src/LLVM/General/Internal/FFI/Module.hs, dist/build/LLVM/General/Internal/FFI/Module.o ) [21 of 93] Compiling LLVM.General.Internal.FFI.ExecutionEngine ( src/LLVM/General/Internal/FFI/ExecutionEngine.hs, dist/build/LLVM/General/Internal/FFI/ExecutionEngine.o ) [22 of 93] Compiling LLVM.General.Internal.FFI.Function ( src/LLVM/General/Internal/FFI/Function.hs, dist/build/LLVM/General/Internal/FFI/Function.o ) [23 of 93] Compiling LLVM.General.Internal.FFI.InlineAssembly ( src/LLVM/General/Internal/FFI/InlineAssembly.hs, dist/build/LLVM/General/Internal/FFI/InlineAssembly.o ) [24 of 93] Compiling LLVM.General.Internal.FFI.InstructionDefs ( dist/build/LLVM/General/Internal/FFI/InstructionDefs.hs, dist/build/LLVM/General/Internal/FFI/InstructionDefs.o ) [25 of 93] Compiling LLVM.General.Internal.InstructionDefs ( src/LLVM/General/Internal/InstructionDefs.hs, dist/build/LLVM/General/Internal/InstructionDefs.o ) [26 of 93] Compiling LLVM.General.Internal.FFI.MemoryBuffer ( src/LLVM/General/Internal/FFI/MemoryBuffer.hs, dist/build/LLVM/General/Internal/FFI/MemoryBuffer.o ) [27 of 93] Compiling LLVM.General.Internal.FFI.Metadata ( src/LLVM/General/Internal/FFI/Metadata.hs, dist/build/LLVM/General/Internal/FFI/Metadata.o ) [28 of 93] Compiling LLVM.General.Internal.FFI.GlobalVariable ( src/LLVM/General/Internal/FFI/GlobalVariable.hs, dist/build/LLVM/General/Internal/FFI/GlobalVariable.o ) [29 of 93] Compiling LLVM.General.Internal.FFI.RawOStream ( src/LLVM/General/Internal/FFI/RawOStream.hs, dist/build/LLVM/General/Internal/FFI/RawOStream.o ) [30 of 93] Compiling LLVM.General.Internal.FFI.Assembly ( src/LLVM/General/Internal/FFI/Assembly.hs, dist/build/LLVM/General/Internal/FFI/Assembly.o ) [31 of 93] Compiling LLVM.General.Internal.FFI.Bitcode ( src/LLVM/General/Internal/FFI/Bitcode.hs, dist/build/LLVM/General/Internal/FFI/Bitcode.o ) [32 of 93] Compiling LLVM.General.Internal.FFI.Target ( src/LLVM/General/Internal/FFI/Target.hs, dist/build/LLVM/General/Internal/FFI/Target.o ) [33 of 93] Compiling LLVM.General.Internal.FFI.Threading ( src/LLVM/General/Internal/FFI/Threading.hs, dist/build/LLVM/General/Internal/FFI/Threading.o ) [34 of 93] Compiling LLVM.General.Internal.FFI.Cleanup ( src/LLVM/General/Internal/FFI/Cleanup.hs, dist/build/LLVM/General/Internal/FFI/Cleanup.o ) [35 of 93] Compiling LLVM.General.Internal.FFI.Constant ( src/LLVM/General/Internal/FFI/Constant.hs, dist/build/LLVM/General/Internal/FFI/Constant.o ) ghc: internal error: stg_ap_pv_ret (GHC version 7.10.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: llvm-general-3.5.1.2 failed during the building phase. The exception was: ExitFailure (-6) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 18:25:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 18:25:23 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.a71a4c5189420d080e4792450c3ca065@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: upstream => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 18:27:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 18:27:03 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.03656d1dcb0e77e6decb5abb1de0c617@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | dependent/should_fail/T11473, | typecheck/should_fail/BadUnboxedTuple Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.0` as c4f7363465518be3c68a2bacec79d09554d4a886. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 18:27:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 18:27:47 -0000 Subject: [GHC] #11754: Error in optCoercion In-Reply-To: <046.bab60c56aeea09df505e0c689289f35b@haskell.org> References: <046.bab60c56aeea09df505e0c689289f35b@haskell.org> Message-ID: <061.c0e8f09cb2b8dc43b24c5d575fa13f2b@haskell.org> #11754: Error in optCoercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11754 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed @@ -2,1 +2,1 @@ - {{{ + {{{#!hs New description: This program fails Lint after a run of the simplifier. {{{#!hs {-# LANGUAGE TypeOperators, UndecidableSuperClasses, KindSignatures, TypeFamilies, FlexibleContexts #-} module T11728a where import Data.Kind import Data.Void newtype K a x = K a newtype I x = I x data (f + g) x = L (f x) | R (g x) data (f ? g) x = f x :?: g x class Differentiable (D f) => Differentiable f where type D (f :: Type -> Type) :: Type -> Type instance Differentiable (K a) where type D (K a) = K Void instance Differentiable I where type D I = K () instance (Differentiable f?, Differentiable f?) => Differentiable (f? + f?) where type D (f? + f?) = D f? + D f? instance (Differentiable f?, Differentiable f?) => Differentiable (f? ? f?) where type D (f? ? f?) = (D f? ? f?) + (f? ? D f?) }}} Originally reported in #11728, but it's a totally different problem. Richard has nailed it already... patch coming from him. -- Comment: Merged to `ghc-8.0` as 91a8e92606890ca191ca7227b11a95c9c76cb428. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 18:38:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 18:38:05 -0000 Subject: [GHC] #11725: Performance Regression from 7.8.3 to 7.10.3 In-Reply-To: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> References: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> Message-ID: <061.a1fd904fadbfce70d3294b8798bcafea@haskell.org> #11725: Performance Regression from 7.8.3 to 7.10.3 -------------------------------------+------------------------------------- Reporter: dominic | Owner: dominic Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It's hard saying without knowing more precisely what the performance regression was due to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 18:39:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 18:39:07 -0000 Subject: [GHC] #11386: Improve error message In-Reply-To: <051.64b4ac544b1736e7961207b55efbfb34@haskell.org> References: <051.64b4ac544b1736e7961207b55efbfb34@haskell.org> Message-ID: <066.91c80864b5f2e5fabd56ca9d0cfe3641@haskell.org> #11386: Improve error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #10362 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal * status: new => closed * resolution: => wontfix * milestone: 8.0.1 => Comment: There wasn't really a consensus that special-casing this was worthwhile. Feel free to re-open if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 18:40:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 18:40:32 -0000 Subject: [GHC] #10296: Segfaults when using dynamic wrappers and concurrency In-Reply-To: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> References: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> Message-ID: <061.8c5eca27107deb4a3626a763884aabdb@haskell.org> #10296: Segfaults when using dynamic wrappers and concurrency -------------------------------------+------------------------------------- Reporter: bitonic | Owner: jme Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2031 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest * milestone: 8.2.1 => 8.0.1 Comment: Given that we now have a patch it seems that we should try to get this fix in to 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 18:44:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 18:44:39 -0000 Subject: [GHC] #11231: GHC's configure script does not honour CC env var In-Reply-To: <042.d7426d5dc7b5e5db91b935fc98bce267@haskell.org> References: <042.d7426d5dc7b5e5db91b935fc98bce267@haskell.org> Message-ID: <057.c13e06a0d55f51bbbbd9c907bfbfa96a@haskell.org> #11231: GHC's configure script does not honour CC env var -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9983 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:5 rwbarton]: > I think some of the other variables in that output you mention do not actually work either, so just fixing `CC` doesn't really reduce user confusion overall. didn't notice that yet... will fix that as well *sigh* > This doesn't fix a real bug, so does it really make sense to merge this to 8.0? Well it is a bug nonetheless... and it's easy to fix (fwiw, Cabal had a related bug which caused it to pass a non-standard --with-ghc to configure scripts rather than the standard CC= flag causing subtle problems on Win32) The idea is to switch to CC= as the recommended/documented way, and delaying merging this to 8.0 would mean that the confusion will continue for one year more than necessary. Also, 8.0 marks an easy to remember point in time where CC= became available. If this only starts working with 8.2 it becomes harder to remember. > How much testing have you done in unusual configurations, e.g., cross- compiling? I actually did test crosscompiling to powerpc as well as checked whether `./validate` would pick it up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 18:51:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 18:51:58 -0000 Subject: [GHC] #11725: Performance Regression from 7.8.3 to 7.10.3 In-Reply-To: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> References: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> Message-ID: <061.87b65b6d111c929b850431af87036964@haskell.org> #11725: Performance Regression from 7.8.3 to 7.10.3 -------------------------------------+------------------------------------- Reporter: dominic | Owner: dominic Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): I don't propose to do any archeology myself so feel free to close this. I refer you to https://mail.haskell.org/pipermail/haskell- cafe/2016-January/122660.html though. I may start a suite of my own performance tests as I would prefer not to be caught out again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 19:15:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 19:15:30 -0000 Subject: [GHC] #10930: missing empty-Enumeration and out-of-range warning for `Natural` In-Reply-To: <042.2b93c01d2c091805f9e006b42184d16c@haskell.org> References: <042.2b93c01d2c091805f9e006b42184d16c@haskell.org> Message-ID: <057.707bf53577b7c47f5d52285c50be929f@haskell.org> #10930: missing empty-Enumeration and out-of-range warning for `Natural` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7881, #10929 | Differential Rev(s): Phab:D1306 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 8.0.1 => 8.2.1 Comment: Punting to GHC 8.2.1 (we aren't going to introduce new warnings in a minor release). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 19:16:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 19:16:14 -0000 Subject: [GHC] #11691: Documentation indicates RelaxedPolyRec is optional In-Reply-To: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> References: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> Message-ID: <060.71edab845a09512401e2754a70f848eb@haskell.org> #11691: Documentation indicates RelaxedPolyRec is optional -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 8.0.1 => 8.0.2 Comment: Punting to 8.0.2 - this would be an easy documentation fix for someone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 19:17:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 19:17:44 -0000 Subject: [GHC] #11495: TH_spliceE5_prof is failing with release candidate 8.0.1 In-Reply-To: <045.e71529dd8c6b021f985c7b75a2a26fb0@haskell.org> References: <045.e71529dd8c6b021f985c7b75a2a26fb0@haskell.org> Message-ID: <060.dece41c3b640d856dce8b46c2f2042e6@haskell.org> #11495: TH_spliceE5_prof is failing with release candidate 8.0.1 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 8.0.1 => 8.2.1 Comment: Punting to 8.2.1 (there's clearly more to discuss here that we don't have time for in the 8.x series). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 19:18:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 19:18:47 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.7ed8b324d0ca91ebf9aad51e93a0fcfb@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 8.0.1 => 8.2.1 Comment: Replying to [comment:14 goldfire]: > Thanks for merging the typo fix. But that's nowhere near the nub of this ticket. We might well decide to do nothing, but I'm not convinced we've converged on that solution yet. Agreed - in the mean time, let's put this to 8.2.1 since we're probably not going to introduce any large changes for 8.x. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 19:20:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 19:20:36 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.3ae7bcaab379ee0d76d4499ab6297e2e@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 8.0.1 => 8.0.2 Comment: We're likely not going to get to this for 8.0.1, but something like this would be 'nice to have' for 8.0.2, so I'm tentatively punting this there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 19:22:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 19:22:41 -0000 Subject: [GHC] #10853: Refine addTopDecls In-Reply-To: <047.c86dd8a253022fe77935e07f26b94dc1@haskell.org> References: <047.c86dd8a253022fe77935e07f26b94dc1@haskell.org> Message-ID: <062.a5251d7352cdedcaf806caad1f5a6ac6@haskell.org> #10853: Refine addTopDecls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 8.0.1 => 8.2.1 Comment: Replying to [comment:6 siddhanathan]: > I haven't been able to keep up the TH changes in master, and I'm getting some weird behavior on current master with the restriction removed. I think someone else would be able to do this faster than I could. Thanks for the update. I'm of the opinion to punt this to the 8.2.x series, so if you'd still like to take a swing at this (and have more breathing room) or something, feel free. Otherwise just feel free to leave it unassigned, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 19:28:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 19:28:16 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.6e3bfd61bfbcdf8a23f2bbc38158a962@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: normal => high Comment: I'm bumping the priority on this and keeping it in 8.0.1, as it seems rather bad to leave open on OS X, especially if the fix in comment:4 can work (use USE_PTHREAD_FOR_ITIMER, if I'm following correctly). Would anyone like to test this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 19:29:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 19:29:09 -0000 Subject: [GHC] #10789: Notify user when a kind mismatch holds up a type family reduction In-Reply-To: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> References: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> Message-ID: <062.2886daa4a7e99f295f7c74bc7218a1dd@haskell.org> #10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ssequeira Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer, | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 8.0.1 => 8.0.2 Comment: I'm bumping this to 8.0.2 and moving this from the 8.0.1 queue, since it's not critical but would be 'nice to have' for error messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 19:30:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 19:30:26 -0000 Subject: [GHC] #10536: Clear up how to turn off dynamic linking in build.mk In-Reply-To: <045.541a8a1a6994293a5767d3af2bef8566@haskell.org> References: <045.541a8a1a6994293a5767d3af2bef8566@haskell.org> Message-ID: <060.53bdb6efdf7e0b427e22d7b14a43508e@haskell.org> #10536: Clear up how to turn off dynamic linking in build.mk -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1021 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 8.0.1 => 8.2.1 Comment: Bumping out to 8.2.x -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 19:43:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 19:43:05 -0000 Subject: [GHC] #11755: Seed unsafeGlobalDynFlags with enough information to use ppr In-Reply-To: <046.9f7b4239d14bbc3c0460e17161c92902@haskell.org> References: <046.9f7b4239d14bbc3c0460e17161c92902@haskell.org> Message-ID: <061.911683c011cafb04d1287ea19a76801a@haskell.org> #11755: Seed unsafeGlobalDynFlags with enough information to use ppr -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2036 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * failure: None/Unknown => Compile-time crash * resolution: => fixed * milestone: => 8.0.1 Comment: Merged to `ghc-8.0` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 19:56:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 19:56:31 -0000 Subject: [GHC] #10623: Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection In-Reply-To: <046.3a764cfd54e5a4e4443ef4864c8fddbf@haskell.org> References: <046.3a764cfd54e5a4e4443ef4864c8fddbf@haskell.org> Message-ID: <061.70dab0a4ab94d3cfd04ea9717f28814d@haskell.org> #10623: Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Test Suite | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T8958a Blocked By: | Blocking: Related Tickets: #10298, #7695 | Differential Rev(s): Phab:D1059, Wiki Page: | Phab:D1085 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 8.0.1 => 8.0.2 Comment: Punting to 8.0.2, since this just affects the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 20:19:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 20:19:53 -0000 Subject: [GHC] #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied In-Reply-To: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> References: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> Message-ID: <060.0e0e6986fd356055e44b5d7e593790b9@haskell.org> #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9636 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 8.0.1 => 8.2.1 Comment: Punting to 8.2.1, since it seems any real 'fix' will require a bit of design work (and in the mean time, from a quick skim, it seems `TypeError` is fine here.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 20:20:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 20:20:56 -0000 Subject: [GHC] #11663: GHC 8.0 type assignment in arguments of lambda working without Scoped Type Variables In-Reply-To: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> References: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> Message-ID: <063.2492934cb2fc0c27dc3d13eaba2faf79@haskell.org> #11663: GHC 8.0 type assignment in arguments of lambda working without Scoped Type Variables -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: normal => high Comment: We should definitely bump this and look at it, since it seems to clearly be some kind of regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 20:29:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 20:29:12 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.948b1c6456ae28c93b1e351e23c36e7d@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1961 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Mmm, this is a good point. My first thought here was to look for kind errors in specified type arguments and provide the user with a better error (including the full type of the applied function) in the case of a unification error. Austin and I discussed this and he suggested that perhaps `-XTypeApplications` should imply `-fprint-explicit-runtime-reps`. This sounds reasonable (if a bit surprising) at first glance given how likely it is that you will experience `RuntimeRep` arguments with `TypeApplications`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 20:29:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 20:29:55 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.f3f10a00f207ffe169d17aaec221df95@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1961 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: closed => new * priority: highest => normal * resolution: fixed => * owner: goldfire => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 20:30:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 20:30:09 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.18a6b344dcf095496301edbfdc030add@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1961 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * version: 8.1 => 8.0.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 20:31:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 20:31:53 -0000 Subject: [GHC] #11762: GHC 8 superclass chain constraint regression In-Reply-To: <048.8d3f15d8dce49f095c6c78ab934bfbaf@haskell.org> References: <048.8d3f15d8dce49f095c6c78ab934bfbaf@haskell.org> Message-ID: <063.0ea08324448fc2b2aa5d1be16c1a26f8@haskell.org> #11762: GHC 8 superclass chain constraint regression -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonpj (added) * priority: high => highest Comment: Pinging simonpj. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 20:32:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 20:32:21 -0000 Subject: [GHC] #11746: I encountered an: internal error: evacuate: strange closure type 803645000 In-Reply-To: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> References: <044.aa2d5c70936d934e77a4152edf0034bf@haskell.org> Message-ID: <059.7c7b798faa51db48c5646eed27d11b87@haskell.org> #11746: I encountered an: internal error: evacuate: strange closure type 803645000 -------------------------------+-------------------------------------- Reporter: hkBst | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #11108 | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate Comment: Lovely. Thanks jme! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 20:35:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 20:35:35 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.a1758e85674db001773d9760407c874e@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 20:37:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 20:37:54 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.5edce1ae457dcd99c2aa52a92a13db4d@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari Comment: I can test comment:4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 20:44:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 20:44:30 -0000 Subject: [GHC] #11554: Self quantification in GADT data declarations In-Reply-To: <046.bec85a0842a04f6c9921baff0e29a2a1@haskell.org> References: <046.bec85a0842a04f6c9921baff0e29a2a1@haskell.org> Message-ID: <061.0211b8afbcb3b736107f86315c4fd096@haskell.org> #11554: Self quantification in GADT data declarations -------------------------------------+------------------------------------- Reporter: Rafbill | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: goldfire (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 20:46:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 20:46:48 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.ebf80847ece34205ad2c0bba0897fe16@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 21:29:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 21:29:13 -0000 Subject: [GHC] #11386: Improve error message In-Reply-To: <051.64b4ac544b1736e7961207b55efbfb34@haskell.org> References: <051.64b4ac544b1736e7961207b55efbfb34@haskell.org> Message-ID: <066.a5f12eb01f9e6d5735a12b76670382a9@haskell.org> #11386: Improve error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #10362 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I'm fine with closing it -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 22:08:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 22:08:14 -0000 Subject: [GHC] #11762: GHC 8 superclass chain constraint regression In-Reply-To: <048.8d3f15d8dce49f095c6c78ab934bfbaf@haskell.org> References: <048.8d3f15d8dce49f095c6c78ab934bfbaf@haskell.org> Message-ID: <063.a3084899ae9d74562506b9ff537568dc@haskell.org> #11762: GHC 8 superclass chain constraint regression -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11427 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jme): * related: => #11427 Comment: This seems to be the same as #11427--see especially ticket:11427#comment:3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 22:23:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 22:23:01 -0000 Subject: [GHC] #11663: GHC 8.0 type assignment in arguments of lambda working without Scoped Type Variables In-Reply-To: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> References: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> Message-ID: <063.69263daab0ef453a455c90fb970aa792@haskell.org> #11663: GHC 8.0 type assignment in arguments of lambda working without Scoped Type Variables -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2054 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2054 Comment: In the case of GHC 7.10 it appears the error is thrown from `RnTypes.badKindSigErr`, strangely enough. It appears that this broke in 1e041b7382b6aa329e4ad9625439f811e0f27232. I've opened Phab:D2054 to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 22:43:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 22:43:58 -0000 Subject: [GHC] #11554: Self quantification in GADT data declarations In-Reply-To: <046.bec85a0842a04f6c9921baff0e29a2a1@haskell.org> References: <046.bec85a0842a04f6c9921baff0e29a2a1@haskell.org> Message-ID: <061.7eff774b17abaca90858425a952e236e@haskell.org> #11554: Self quantification in GADT data declarations -------------------------------------+------------------------------------- Reporter: Rafbill | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): We're going to just mention this in the user's guide -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 22:56:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 22:56:06 -0000 Subject: [GHC] #11765: Allow documentary type signatures Message-ID: <045.51543a8e2596876e20358182acc17b6e@haskell.org> #11765: Allow documentary type signatures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In some cases (e.g., `lens`) it's useful to document a binding with a more specific type signature than the true one, to show a useful special case. Unfortunately, this documentation can potentially be wrong or go out of date. I'd like to propose a pragma for this: {{{#!hs {-# Documentary #-} f :: T -> U }}} would ask the type checker to verify that `f :: T -> U`. Specifically, it would have the effect of creating and type checking, but then discarding, a hidden binding {{{#!hs f_doc :: T -> U f_doc t = f t }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 28 23:06:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Mar 2016 23:06:42 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.d6e3d079675ebece5d6754f2d7cbf384@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1961 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.0.2 Comment: Unfortunately I don't see an easy way to make comment:11 happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 07:32:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 07:32:31 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.9edbc4151cbd037745a5282574f2bd80@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hang on. Isn't there already somewhere in VTA where you already instantiate where it's not strictly necessary? Maybe somewhere like {{{ f x = g }}} where `g` has a polytype. With lazy instantiation you might well get an inferred type {{{ f :: forall a. Eq a => a -> forall b. Ord b => blah }}} but I think we don't. I think there is somewhere this happens, although I am not sure where. The `:t` context looks to me like another place where this eager instantiation should happen, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 07:35:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 07:35:17 -0000 Subject: [GHC] #11762: GHC 8 superclass chain constraint regression In-Reply-To: <048.8d3f15d8dce49f095c6c78ab934bfbaf@haskell.org> References: <048.8d3f15d8dce49f095c6c78ab934bfbaf@haskell.org> Message-ID: <063.7e7941292835cedef51d8b076df1b8e8@haskell.org> #11762: GHC 8 superclass chain constraint regression -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11427 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by _deepfire): Oh my god, does it mean we are going to sacrifice the very convenient, simple and obvious (for some value of "simple" and "obvious") implication on the altar of recursive superclasses? Because #11427 seems to conclude in that way.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 08:02:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 08:02:20 -0000 Subject: [GHC] #10918: Float once-used let binding into a recursive function In-Reply-To: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> References: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> Message-ID: <061.22982f715cf94332e261c0a37844b44d@haskell.org> #10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I suppose that would work, although I don?t like solving such issues by slamming just another pass to the end of the pipeline, instead of making sure the passes work well together (which is indeed tricky here). I agree with the principle here. But it does seem hard. The float-out pass assumes, crudely, that it's good to float out a redex of any called- many lambda. But, as we see here, that's wrong for case branches that are only evaluated on one of those calls (the final one in this case). Not only is that info hard to record in the syntax tree, but it's also potentially quite fragile to program transformation, like other sorts of cardinality information. So refraining from let-floating after the final call-arity/simplifier pass does seem plausible. Annoyingly, it's just possible that inlining `(foo ys` into that `[]` branch might then put it in a context when `foo` inlines, leading to a cascade of further transformations. So it's not necessarily just a little delta. It'd be good to understand the paraffins thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 08:42:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 08:42:44 -0000 Subject: [GHC] #11736: Allow unsaturated uses of unlifted types in Core In-Reply-To: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> References: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> Message-ID: <061.3bf17509807571935e8e0ea8f414f3d6@haskell.org> #11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Oh bother, yes, you are right about unboxed tuples. What do you mean about "there is an explicit check for this"? You mean: we allow unrestricted un-saturated primitive type constructors, but enforce some other invariant? There really is a paper here somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 09:04:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 09:04:12 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.c721b0160bdac8fc87daa00058b29201@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): But the `Some` at the link is this: {{{ data Some tag :: (k -> *) -> * where This :: !(tag t) -> Some k tag }}} There's no reason why this can't be a `newtype` today, is there? So it doesn't look relevant to this ticket. (Except I suppose that if comment:9 was implemented, it'd be efficient already.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 09:06:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 09:06:48 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.d53cbd565ee388f89a87880f20a77083@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:16 Iceland_jack]: > Brought up on #ghc, are there technical reasons why `(,)` ''cannot'' be partially applied with the same meaning as `(&)`? I'm lost. What is `(&)`? How is this connected with this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 09:14:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 09:14:41 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.23e5924a6b1abe1132522c93b0fd092b@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Combining `Constraint` with `*` would also * resolve #9547 * Allow partial applications like `(,) (Eq a) :: Constraint -> Constraint` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 09:16:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 09:16:59 -0000 Subject: [GHC] #11761: autoconf 2.69 breaks configure In-Reply-To: <046.026016968a0f00c4ea3dfc0c8c115a55@haskell.org> References: <046.026016968a0f00c4ea3dfc0c8c115a55@haskell.org> Message-ID: <061.742acde00b4d3ba83583130499580ae2@haskell.org> #11761: autoconf 2.69 breaks configure -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): can you compare the generated `./configure` scripts to see what differs in line 561? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 09:17:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 09:17:06 -0000 Subject: [GHC] #11757: Turn on (and require) C99/C11 mode by default In-Reply-To: <042.cdde255506f2bc07285d1fee6acec3cf@haskell.org> References: <042.cdde255506f2bc07285d1fee6acec3cf@haskell.org> Message-ID: <057.d9b89a338fc4213ca08a5b9d83a013d9@haskell.org> #11757: Turn on (and require) C99/C11 mode by default -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: kgardas (added) Comment: related change regarding `_XOPEN_SOURCE`/`_POSIX_C_SOURCE`: 91b96e1ccce6a642d710ce40211e1795d01abf04 and phab:D2053 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 09:25:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 09:25: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.b9550a70418e5e2ec16c52afd6d3cb11@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by liyang): * cc: liyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 09:47:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 09:47:09 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.34005c3d9d43b099889e68904b60e331@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Implementation simplicity can also lead to programmer simplicity. The reverse is certainly often true: a torturous implementation can lead to a specification that is hard to explain to users. I have not examined the details here, but I like th idea of "zero instantiation checks"! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 10:21:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 10:21:11 -0000 Subject: [GHC] #11762: GHC 8 superclass chain constraint regression In-Reply-To: <048.8d3f15d8dce49f095c6c78ab934bfbaf@haskell.org> References: <048.8d3f15d8dce49f095c6c78ab934bfbaf@haskell.org> Message-ID: <063.1f6851d22475f068d7d269ad1d5345fe@haskell.org> #11762: GHC 8 superclass chain constraint regression -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11427 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, it's the same as #11427. It doesn't bite often, and it's also easy to fix, thus {{{ instance (Super a, Left a) ? Right a }}} What I most dislike about it is that it's hard to explain and justify. I would like a better way to do this, but I don't know one. Better ideas welcome! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 10:29:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 10:29:07 -0000 Subject: [GHC] #11108: Weak references related crash In-Reply-To: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> References: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> Message-ID: <061.41481a19884deefe59fcc9f145f2c5e1@haskell.org> #11108: Weak references related crash -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: jme Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11746 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hkBst): * cc: hkbst (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 10:34:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 10:34:15 -0000 Subject: [GHC] #11766: Lazy application gives "No instance" error while strict application works Message-ID: <047.6457ae8316e008d1f2f63e8e30939ea4@haskell.org> #11766: Lazy application gives "No instance" error while strict application works -------------------------------------+------------------------------------- Reporter: MichaelK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This might make sense if there were any IO. Here's the code: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE OverlappingInstances #-} {-# LANGUAGE UndecidableInstances #-} import Data.Maybe (isJust) data Wrapper a = Wrapper a deriving (Show) class Resolution a instance Resolution (Wrapper a) class (Resolution b, Resolution d) => C a b c d | a -> b, c -> d, a d -> c, b c -> a where cfun :: (b -> d) -> a -> c instance (Resolution b, Resolution d, a ~ b, c ~ d) => C a b c d where cfun = ($) instance (Eq a, C b c d e) => C (Maybe a -> b) c (Maybe a -> d) e where cfun f b = \x -> cfun f (b x) foo :: Maybe a -> Wrapper Bool foo = Wrapper . isJust }}} Applying `Nothing` strictly or in a `let` clause gives the expected answer (I expect that `cfun id foo` would be equivalent to `foo`): {{{#!hs *Main> cfun id foo $! Nothing Wrapper False *Main> let f = cfun id foo in f Nothing Wrapper False }}} But regular application (or just `(cfun id foo) Nothing`) returns the following error: {{{#!hs *Main> cfun id foo $ Nothing :6:1: No instance for (Resolution (Maybe a0 -> Wrapper Bool)) (maybe you haven't applied enough arguments to a function?) arising from a use of ?cfun? In the expression: cfun id foo In the expression: cfun id foo $ Nothing In an equation for ?it?: it = cfun id foo $ Nothing }}} In case it helps, the purpose of this code is for `cfun` to have the effective type of {{{#!hs cfun :: (Eq a0, Eq a1, .., Eq an) => (Wrapped b -> Wrapped c) -> (Maybe a0 -> Maybe a1 -> .. -> Maybe an -> Wrapped b) -> (Maybe a0 -> Maybe a1 -> .. -> Maybe an -> Wrapped c) }}} i.e. apply a function to the "wrapped" return value of another function of the above form. Tested on GHC 8.0.1-rc2 (most recent OSX binary as of now) and 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 10:35:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 10:35:26 -0000 Subject: [GHC] #11554: Self quantification in GADT data declarations In-Reply-To: <046.bec85a0842a04f6c9921baff0e29a2a1@haskell.org> References: <046.bec85a0842a04f6c9921baff0e29a2a1@haskell.org> Message-ID: <061.d3df7a06f645c57a63ce2a1b4ff93011@haskell.org> #11554: Self quantification in GADT data declarations -------------------------------------+------------------------------------- Reporter: Rafbill | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"aa611746aa860e1884c9ad623d6939791f2645ff/ghc" aa61174/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aa611746aa860e1884c9ad623d6939791f2645ff" users-guide: Add references to various issues in bugs section Test Plan: Read it Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2052 GHC Trac Issues: #7411, #11197, #11554, #11715 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 10:35:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 10:35:26 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.789657e8cf8fdea6d265e77eacee53d8@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"aa611746aa860e1884c9ad623d6939791f2645ff/ghc" aa61174/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aa611746aa860e1884c9ad623d6939791f2645ff" users-guide: Add references to various issues in bugs section Test Plan: Read it Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2052 GHC Trac Issues: #7411, #11197, #11554, #11715 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 10:35:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 10:35:26 -0000 Subject: [GHC] #11197: Overeager deferred type errors In-Reply-To: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> References: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> Message-ID: <062.97a9dfb91185dced6847df899d71bdd0@haskell.org> #11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"aa611746aa860e1884c9ad623d6939791f2645ff/ghc" aa61174/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aa611746aa860e1884c9ad623d6939791f2645ff" users-guide: Add references to various issues in bugs section Test Plan: Read it Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2052 GHC Trac Issues: #7411, #11197, #11554, #11715 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 10:35:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 10:35:26 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.cf05006913855e451df4a1490cdede90@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"aa611746aa860e1884c9ad623d6939791f2645ff/ghc" aa61174/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aa611746aa860e1884c9ad623d6939791f2645ff" users-guide: Add references to various issues in bugs section Test Plan: Read it Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2052 GHC Trac Issues: #7411, #11197, #11554, #11715 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 10:51:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 10:51:39 -0000 Subject: [GHC] #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation In-Reply-To: <042.d49c422577da41f5c4d9261d67e3806a@haskell.org> References: <042.d49c422577da41f5c4d9261d67e3806a@haskell.org> Message-ID: <057.75b8c8b5e409b91c55e0142ccba4f484@haskell.org> #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10970 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Not yet; Phab:D1869 enables macro generation always, but I've held off on merging it in hopes that someone would pick up this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 10:52:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 10:52:28 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.8646615954763cacd4db5b74422bd283@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1349, Wiki Page: | Phab:D1869 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Comment: This (Phab:D1869) will be merged when #11763 is implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 10:54:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 10:54:41 -0000 Subject: [GHC] #11725: Performance Regression from 7.8.3 to 7.10.3 In-Reply-To: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> References: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> Message-ID: <061.9ab671eeb8ef5052e2c23a1692253687@haskell.org> #11725: Performance Regression from 7.8.3 to 7.10.3 -------------------------------------+------------------------------------- Reporter: dominic | Owner: dominic Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:9 dominic]: > I don't propose to do any archeology myself so feel free to close this. I refer you to https://mail.haskell.org/pipermail/haskell- cafe/2016-January/122660.html though. I may start a suite of my own performance tests as I would prefer not to be caught out again. If you can come up with any tests that have minimal build dependencies (ideally none although boot libraries are acceptable) please contribute them to `nofib`. We are in bad need of better coverage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 10:56:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 10:56:24 -0000 Subject: [GHC] #11725: Performance Regression from 7.8.3 to 7.10.3 In-Reply-To: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> References: <046.8d7c34a701635a2c5b91cd82d4b96973@haskell.org> Message-ID: <061.e7945b3bcb60574a1e5b227872207ea2@haskell.org> #11725: Performance Regression from 7.8.3 to 7.10.3 -------------------------------------+------------------------------------- Reporter: dominic | Owner: dominic Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: This seems to be one of many performance regressions in 7.10 which has mysteriously improved with 8.0. There have been a variety of performance improvements made in 8.0; it would be great to know which of these helped here. You, the reader, can help here by identifying which commit(s) are responsible for this improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 11:02:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 11:02:58 -0000 Subject: [GHC] #11745: In GHC Download section it is not stated that ARMv7 build is only for 32bit ARM In-Reply-To: <045.95fbc89e237ba959ef056a0b0ce1db9b@haskell.org> References: <045.95fbc89e237ba959ef056a0b0ce1db9b@haskell.org> Message-ID: <060.8a21d32409fb33f454f44c0059bbd753@haskell.org> #11745: In GHC Download section it is not stated that ARMv7 build is only for 32bit ARM --------------------------------------+------------------------------ Reporter: varosi | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Documentation bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+------------------------------ Changes (by bgamari): * status: new => closed * cc: erikd (added) * resolution: => fixed Comment: ARMv7 is a 32-bit architecture; if you have a 64-bit ARM box then you are using an ARMv8 chip. We currently don't have a binary distribution for ARMv8. Regardless, I can update the download page language to clear up any confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 11:09:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 11:09:46 -0000 Subject: [GHC] #11639: `:print` being wacky In-Reply-To: <048.c516bc228e8d9a9b263488a0df177e98@haskell.org> References: <048.c516bc228e8d9a9b263488a0df177e98@haskell.org> Message-ID: <063.450a14b256b1b54639eafa3d1841cecd@haskell.org> #11639: `:print` being wacky -------------------------------+---------------------------------------- Reporter: TheKing42 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: This appears to be fixed in 8.0, {{{ $ ghci GHCi, version 8.0.0.20160328: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ben/.ghci ?> let x = 1:x ?> :print x x = (_t1::Num a => [a]) ?> head _t1 :3:6: error: ? No instance for (Num a) arising from a use of ?_t1? ? In the first argument of ?head?, namely ?_t1? In the expression: head _t1 In an equation for ?it?: it = head _t1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 11:12:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 11:12:07 -0000 Subject: [GHC] #11760: runST with lazy blackholing breaks referential transparency In-Reply-To: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> References: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> Message-ID: <059.f1e9ac59bbe867b6063257e666e2a891@haskell.org> #11760: runST with lazy blackholing breaks referential transparency -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: simonmar, rnewton (added) Comment: This looks bad. Do you have a more detailed theory? Our thinking about lazy blackholing is that if two threads start to evaluate the same thunk, they may waste work but shoudl still get the same value. But that is not happening here and I'd like to understand why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 11:16:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 11:16:59 -0000 Subject: [GHC] #11629: reify returns Dec that use ConT instead of PromotedT In-Reply-To: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> References: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> Message-ID: <060.3fa4418b6dc90136cb5a1aaf1531e54d@haskell.org> #11629: reify returns Dec that use ConT instead of PromotedT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 Comment: Hmm, this is still reproducible on a recent GHC 8.0 snapshot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 11:31:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 11:31:35 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.c62116c6d05f85e0bcacc112a99b00eb@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"73935326e0cf85ed077b9ab7dd8f197d39e2cd5b/ghc" 73935326/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="73935326e0cf85ed077b9ab7dd8f197d39e2cd5b" Use a correct substitution in tcInstType `ty` doesn't have to be a closed type, so we need to add its free vars to the in-scope set. They don't seem to be available anywhere nearby, so we have to compute them. Test Plan: ./validate Reviewers: goldfire, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D2042 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 11:31:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 11:31:35 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.8216c13c5d53ea0604ee6c996812150a@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a49228e3b6e3737da750bce59ec721b3b2f18eed/ghc" a49228e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a49228e3b6e3737da750bce59ec721b3b2f18eed" Build correct substitution in instDFunType We will use `ty` in the range of the substitution, hence the substitution needs `ty`'s free vars in-scope. They don't seem easily available by other means, so we just compute them. Test Plan: ./validate Reviewers: austin, goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D2043 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 11:31:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 11:31:35 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.5b47826d7fe15facb52413b4e7a83088@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4a93e4f9a86a62d1cdf2e666f977b8b58e61eaaf/ghc" 4a93e4f9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4a93e4f9a86a62d1cdf2e666f977b8b58e61eaaf" Use the correct substitution in lintCoercion We need the free vars of `t2` to satisfy the substitution invariant. Luckily they are in the in-scope carried around. Test Plan: ./validate Reviewers: bgamari, austin, goldfire, simonpj Reviewed By: simonpj Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D2044 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 11:31:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 11:31:35 -0000 Subject: [GHC] #11756: Data.Functor.Classes instances for Proxy In-Reply-To: <049.88e00c8489fafead34a109f21260f2c7@haskell.org> References: <049.88e00c8489fafead34a109f21260f2c7@haskell.org> Message-ID: <064.4fd6b2583b3abf88f31df9bb05e1869c@haskell.org> #11756: Data.Functor.Classes instances for Proxy -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2051 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5097f3802124cfbe6810bff8110df91d4c52096b/ghc" 5097f38/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5097f3802124cfbe6810bff8110df91d4c52096b" Add Data.Functor.Classes instances for Proxy (trac issue #11756) Test Plan: currently no test plan Reviewers: hvr, RyanGlScott, bgamari, austin Reviewed By: RyanGlScott, bgamari, austin Subscribers: thomie, RyanGlScott, andrewthad Differential Revision: https://phabricator.haskell.org/D2051 GHC Trac Issues: #11756 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 11:42:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 11:42:19 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.1143f6ba9952751fcc0a5ebab98d2cbc@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard's consultation is [https://mail.haskell.org/pipermail/ghc- devs/2016-March/011631.html this email thread]. Just to be clear to everyone else, we are discussing {{{ data P1 (a :: k) = MkP1 deriving Functor data P2 k (a :: k) = MkP2 deriving Functor }}} Here `P2` has an explicit kind arg, which must appear in any use of `P2`; thus {{{ f :: P2 * Int -> Bool }}} The question before the house is whether to reject either or both 'deriving' clauses, on the grounds that both instantiate 'k'; and ask for a stand-alone deriving declaration instead. Or we could accept either or both, getting {{{ instance Functor (P1 (a :: *)) instance Functor (P2 * (a ::*)) }}} In principle we could say Yes/Yes, Yes/No, or No/No to the two cases. As Richard points out, a 'deriving' clause attached to a 'data' decl infers some instance context. That context must be written explicitly in a standalone deriving declaration. For example: {{{ data Maybe a = Nothing | Just a deriving( Eq ) }}} we get the derived instance {{{ instance Eq a => Eq (Maybe a ) where (==) x y = ...blah... }}} The `Eq a` context in this instance declaration is magically inferred from the form of the data type declaration. This inference process gets pretty tricky for Functor and Traversable. To use the instance declarations you have to understand what the inferred instance context is; GHC should really provide a way to tell you. Richard points out (later in the thread) that "instantiating k" is like adding a constraint `k ~ *` to the instance, thus {{{ instance (k ~ *) => Functor (P1 (a :: k)) }}} That's not quite true, because this instance will match for any k, and hence overlaps with putative instances for k's other than `*`; whereas {{{ instance Functor P1 (a :: *) }}} matches only for the `*` case. And that is a subtle distinction indeed! Hmm. I am rather persuaded by Richard's argument. '''Proposal:''' just regard the kind constraints as extra inferred constraints, and hence generate {{{ instance (k ~ *) => Functor (P1 (a :: k)) }}} Now the derived instance always has type variables in the head; but those type variables may be constrained by the context. I like that. It's not quite what happens now, so there would be a little implementation work to do. It might quite possibly actually be simpler. I'm going to dump this email into the ticket. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 12:00:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 12:00:15 -0000 Subject: [GHC] #11767: Add @since annotations for base instances Message-ID: <046.80486230653199e8f5fef1dcd513180c@haskell.org> #11767: Add @since annotations for base instances -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 7.10.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Up until now we haven't been adding `@since` annotations for instances that we add to `base` (see Phab:D2051 for the discussion that spurred this ticket). We should try to get better coverage here. Unfortunately, we currently have no way to place Haddock comments on derived instances, which limits our ability consistently add these annotations. We'll need to work out some mechanism for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 12:01:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 12:01:47 -0000 Subject: [GHC] #11768: Need a way to attach Haddock documentation to derived instances Message-ID: <046.f8385aa0e2bf22414748bbc6aca23dc7@haskell.org> #11768: Need a way to attach Haddock documentation to derived instances -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the case of `base` we'd like to be able to attach Haddock `@since` annotations on new typeclass instances. Unfortunately many instances are derived, which we can't currently attach Haddock documentation to. Fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 12:02:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 12:02:03 -0000 Subject: [GHC] #11768: Need a way to attach Haddock documentation to derived instances In-Reply-To: <046.f8385aa0e2bf22414748bbc6aca23dc7@haskell.org> References: <046.f8385aa0e2bf22414748bbc6aca23dc7@haskell.org> Message-ID: <061.c0b5654f9ddc6ac72a6e58f437e2c244@haskell.org> #11768: Need a way to attach Haddock documentation to derived instances -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11767 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #11767 @@ -2,3 +2,3 @@ - annotations on new typeclass instances. Unfortunately many instances are - derived, which we can't currently attach Haddock documentation to. Fix - this. + annotations on new typeclass instances (see #11767). Unfortunately many + instances are derived, which we can't currently attach Haddock + documentation to. Fix this. New description: In the case of `base` we'd like to be able to attach Haddock `@since` annotations on new typeclass instances (see #11767). Unfortunately many instances are derived, which we can't currently attach Haddock documentation to. Fix this. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 12:02:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 12:02:23 -0000 Subject: [GHC] #11767: Add @since annotations for base instances In-Reply-To: <046.80486230653199e8f5fef1dcd513180c@haskell.org> References: <046.80486230653199e8f5fef1dcd513180c@haskell.org> Message-ID: <061.5352d2dce508803d34f5866b723f0aa7@haskell.org> #11767: Add @since annotations for base instances -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11768 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #11768 @@ -7,1 +7,1 @@ - annotations. We'll need to work out some mechanism for this. + annotations. We'll need to work out some mechanism for this (see #11768). New description: Up until now we haven't been adding `@since` annotations for instances that we add to `base` (see Phab:D2051 for the discussion that spurred this ticket). We should try to get better coverage here. Unfortunately, we currently have no way to place Haddock comments on derived instances, which limits our ability consistently add these annotations. We'll need to work out some mechanism for this (see #11768). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 12:07:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 12:07:06 -0000 Subject: [GHC] #11765: Allow documentary type signatures In-Reply-To: <045.51543a8e2596876e20358182acc17b6e@haskell.org> References: <045.51543a8e2596876e20358182acc17b6e@haskell.org> Message-ID: <060.df633e786c144ac5c7f6e796ad5b125b@haskell.org> #11765: Allow documentary type signatures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Not a bad idea; and easy to implement given syntax that everyone is happy with. In SPECIALISE pragmas the type is inside the pragma, and this is a variant of `SPECIALISE`. Indeed, maybe it ''is'' `SPECIALISE`, except that GHC might notice that there was nothing to be gained from specialising and so discard the code and rule. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 12:53:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 12:53:32 -0000 Subject: [GHC] #11760: runST with lazy blackholing breaks referential transparency In-Reply-To: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> References: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> Message-ID: <059.d47b1514487270d521e9c07d86c749e1@haskell.org> #11760: runST with lazy blackholing breaks referential transparency -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Yuras): Replying to [comment:1 simonpj]: > This looks bad. Do you have a more detailed theory? Our thinking about lazy blackholing is that if two threads start to evaluate the same thunk, they may waste work but shoudl still get the same value. But that is not happening here and I'd like to understand why. Reeveluating a thunk gives the same result only for pure computation, it is clearly not the case for (lazy) `ST`. In this particular case, the thunk captures mutable variables, and we have a race condition when two threads access them. The result depends on ordering. Also, I don't think `-feager-blackholing` actually fixes the issue. AFAIK it doesn't introduce a write barrier then replacing a thunk with a hole, so the race is still possible (though is harder to reproduce). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 13:02:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 13:02:06 -0000 Subject: [GHC] #11765: Allow documentary type signatures In-Reply-To: <045.51543a8e2596876e20358182acc17b6e@haskell.org> References: <045.51543a8e2596876e20358182acc17b6e@haskell.org> Message-ID: <060.58eac091d4985f1196796ec706a3e270@haskell.org> #11765: Allow documentary type signatures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 simonpj]: > Not a bad idea; and easy to implement given syntax that everyone is happy with. In SPECIALISE pragmas the type is inside the pragma, and this is a variant of `SPECIALISE`. > > Indeed, maybe it ''is'' `SPECIALISE`, except that GHC might notice that there was nothing to be gained from specialising and so discard the code and rule. It's certainly quite similar! It sometimes declines to generate code/rules (insufficient specialization, too complicated), and here we'd probably prefer to skip generation rather than generate and discard. But it seems likely that machinery could be shared. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 13:14:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 13:14:56 -0000 Subject: [GHC] #11765: Allow documentary type signatures In-Reply-To: <045.51543a8e2596876e20358182acc17b6e@haskell.org> References: <045.51543a8e2596876e20358182acc17b6e@haskell.org> Message-ID: <060.dac771389c5bc15b82ab222d905527d0@haskell.org> #11765: Allow documentary type signatures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): See #11439 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 13:18:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 13:18:24 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.4a7249ef3c84b7d18da4a2a2317f2a92@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:17 simonpj]: > Replying to [comment:16 Iceland_jack]: > > Brought up on #ghc, are there technical reasons why `(,)` ''cannot'' be partially applied with the same meaning as `(&)`? > > I'm lost. What is `(&)`? How is this connected with this ticket? `(&) :: Constraint -> Constraint -> Constraint` is defined by {{{#!hs class (p, q) => p & q instance (p, q) => p & q }}} at the beginning of this ticket. This would actually be solved by #11715 (per your comment ticket:11715#comment:14) > * Allow partial applications like `(,) (Eq a) :: Constraint -> Constraint` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 14:33:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 14:33:48 -0000 Subject: [GHC] #11769: Support and redistributables for ARM64 (64bit) Message-ID: <045.030b06e47c0acc2ce7486f79378606ec@haskell.org> #11769: Support and redistributables for ARM64 (64bit) ---------------------------------------+--------------------------------- Reporter: varosi | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+--------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 14:35:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 14:35:19 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.7dd2b3e6ba3a77f5659f73596bea04a2@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): You're talking about `Note [Instantiate when inferring a type]` in !TcBinds. Yes. When we infer a type, we instantiate. The Note has the details, but this design makes it so that values with inferred types never have any variables available for type application. This is good. With `:type`, though, we don't want to instantiate, because doing so might change specified variables to invisible ones. Or in cases like `forall a. (a ~ Int) => ...`, instantiating and then solving will actually get rid of a variable. Instantiating ''when there are no more specified variables'' isn't ruinous, but I'm sure implementing the special case will cause confusion. Given that this is, essentially, a pretty-printing issue, maybe it should be controlled by `-fprint-explicit-foralls`? With the flag set, we never instantiate. Otherwise, we always instantiate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 14:38:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 14:38:07 -0000 Subject: [GHC] #11736: Allow unsaturated uses of unlifted types in Core In-Reply-To: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> References: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> Message-ID: <061.98f174c46e62cdbecaec0d0a80351f44@haskell.org> #11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): See `Note [Unboxed tuples in representation polymorphism check]` in !TcHsSyn. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 14:41:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 14:41:04 -0000 Subject: [GHC] #11757: Turn on (and require) C99/C11 mode by default In-Reply-To: <042.cdde255506f2bc07285d1fee6acec3cf@haskell.org> References: <042.cdde255506f2bc07285d1fee6acec3cf@haskell.org> Message-ID: <057.d6cf80180c645d258753222cdd94086d@haskell.org> #11757: Turn on (and require) C99/C11 mode by default -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): be2a7baf15c6cf414e2287bff3ed345c50de88bd / phab:D2056 (reference added manually due to missing Trac ticket reference in commit msg) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 14:41:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 14:41:23 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.276ed109806b7ba00871204017d6cd98@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:19 goldfire]: > With `:type`, though, we don't want to instantiate, because doing so might change specified variables to invisible ones. Or in cases like `forall a. (a ~ Int) => ...`, instantiating and then solving will actually get rid of a variable. I'm not sure I agree. `:type` takes an ''expression'' and ''infers'' its most general type. Sometimes that expression is a bare function name, but not always. In contrast `:info` takes a name, and tells you about it, with its un- instantiated type. So in cases like `forall a. (a~Int) => Int -> a -> Int` I think it would be absolutely acceptable to get rid of the variable in `:type`. Moreover, you can't consistently ''prevent'' it happening. Why should `:type f` and `:type (f 3)` behave so differently (when `f` has the type given earlier in this para)? In short, I suspect that using `Note [Instantiate when inferring a type]` for `:type` would be a jolly good thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 14:48:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 14:48:51 -0000 Subject: [GHC] #11745: In GHC Download section it is not stated that ARMv7 build is only for 32bit ARM In-Reply-To: <045.95fbc89e237ba959ef056a0b0ce1db9b@haskell.org> References: <045.95fbc89e237ba959ef056a0b0ce1db9b@haskell.org> Message-ID: <060.18c586f2d2d28f80f62f1507949173b8@haskell.org> #11745: In GHC Download section it is not stated that ARMv7 build is only for 32bit ARM --------------------------------------+------------------------------ Reporter: varosi | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Documentation bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+------------------------------ Comment (by varosi): Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 14:50:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 14:50:41 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.23cf049f20f0b7f564ba93bb32dcba8e@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"80d4fdf0756ce7edc534b9277d7c6c63c8ceb501/ghc" 80d4fdf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="80d4fdf0756ce7edc534b9277d7c6c63c8ceb501" SpecConstr: Transport strictness data to specialization?s argument?s binders This is a result of the discussion in ticket:11731#comment:9. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 15:07:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 15:07:30 -0000 Subject: [GHC] #11769: Support and redistributables for ARM64 (64bit) In-Reply-To: <045.030b06e47c0acc2ce7486f79378606ec@haskell.org> References: <045.030b06e47c0acc2ce7486f79378606ec@haskell.org> Message-ID: <060.36313d2f211ad3ded8197c18bfbef817@haskell.org> #11769: Support and redistributables for ARM64 (64bit) ------------------------------------+------------------------------- Reporter: varosi | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+------------------------------- Changes (by bgamari): * cc: erikd (added) * architecture: arm => aarch64 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 15:13:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 15:13:00 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.f36798e1cf5fa0e7ea66b2285b742da8@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): There is a small problem here: {{{ instance (k ~ *) => Functor (P1 (a :: k)) }}} doesn't type-check. The problem is that this requires "immediate" use of the kind equality. In other words, we would need to give a name to the kind equality in order to cast by it later in the same type. But, last spring, Simon and I decided it would be simpler not to allow binding of kind equalities in types -- we can now bind them only in terms. (See also the first bullet [wiki:DependentHaskell/Phase1#Answers here].) Ignoring this issue, let's consider 1. `instance (k ~ *) => Functor (P2 k)` 2. `instance Functor (P2 *)` I claim that these (if the first were to type-check) instances are entirely equivalent. Normally, inlining an equality constraint changes the meaning of an instance, but not here. The first instance matches `Functor (P2 k)` for any value of `k`. What's interesting is that the second instance, exactly as written, does too. That's because the only possible value for `k` in `Functor (P2 k)` is `*`. Anything else is surely ill- typed. Accordingly, we should be comfortable just using the second instance. And I believe that anytime this sort of instantiation would happen has this property (that anything else would be ill-typed). This all means we can just do nothing about this particular issue. Which is nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 15:44:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 15:44:00 -0000 Subject: [GHC] #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration Message-ID: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After quite a while of staring at the core of nofib?s `fft2` benchmark, where my dynamic entry counting code (#10613), I found the problem. Here is a small example: {{{ foo :: Int -> Int -> Int foo 10 c = 0 foo n c = let bar :: Int -> Int bar n = n + c {-# NOINLINE bar #-} in bar n + foo (bar (n+1)) c }}} Clearly, `bar` is not single-entry. But the demand analyzer believes it is: {{{ Rec { -- RHS size: {terms: 32, types: 12, coercions: 0} foo [Occ=LoopBreaker] :: Int -> Int -> Int [LclIdX, Arity=2, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 0] 192 20}] foo = \ (ds [Dmd=] :: Int) (c [Dmd=] :: Int) -> case ds of wild [Dmd=] { I# ds [Dmd=] -> case ds of ds { __DEFAULT -> let { bar [InlPrag=NOINLINE, Dmd=] :: Int -> Int [LclId, Arity=1, CallArity=1, Str=m {axl->}, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 30 0}] bar = \ (n [Dmd=, OS=OneShot] :: Int) -> $fNumInt_$c+ n c } in case bar wild of _ [Occ=Dead, Dmd=] { I# x [Dmd=] -> case foo (bar (I# (+# ds 1#))) c of _ [Occ=Dead, Dmd=] { I# y [Dmd=] -> I# (+# x y) } }; 10# -> lvl } } end Rec } }}} The reason is that during the first fixed-point iteration for `foo`, `foo` itself is assumed to not put any demand on its arguments. Under this assumption, it is correct to find that `bar` is called at most once. This is then noted in the lambda binder. The second iteration corrects the demand, but not the one-shot annotation, because that is only added by the demand analyzer, never dropped: {{{#!hs setOneShotness :: Count -> Id -> Id setOneShotness One bndr = setOneShotLambda bndr setOneShotness Many bndr = bndr }}} This can be fixed by changing that code (from `DmdAnal.hs`) to {{{#!hs setOneShotness :: Count -> Id -> Id setOneShotness One bndr = setOneShotLambda bndr setOneShotness Many bndr = clearOneShotLambda bndr }}} But this would have other consequences, e.g. erasing any possible manual one-shot annotations using `oneShot`. Or maybe `setOneShotness` should not be set by the demand analyzer during its work, but once at the end, or maybe even the next simplifier pass should take care of that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 15:50:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 15:50:29 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.31b8516f5b8fba53a4df722a3059b892@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ryantrinkle): Hmm, when I try to convert it to a newtype, like this: {{{ newtype Some tag = forall t. This (tag t) }}} I get this error: {{{ src/Data/Some.hs:17:20: A newtype constructor cannot have existential type variables This :: forall (k :: BOX) (tag :: k -> *) (t :: k). tag t -> Some tag In the definition of data constructor ?This? In the newtype declaration for ?Some? }}} Is there a different way of converting it to a newtype that I'm overlooking? Here's a link to the original source of that Some: https://hackage.haskell.org/package/dependent-sum-0.3.2.1/docs/src/Data- Some.html#Some . The Hoogle output is more confusing to me than the original. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 15:53:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 15:53:12 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.dd494b52292b10521190e70b9483eeef@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Oh sorry, my fault. I stupidly missed the fact that `t` was existential. Just ignore comment:24. So this is an example of the ticket. Back to comment:9 then, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 16:27:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 16:27:26 -0000 Subject: [GHC] #11771: ghc.exe: `panic'! (the 'impossible' happened); thread blocked indefinitely in an MVar operation Message-ID: <048.fac6b544c2d3d144dfdcb6fd33b2e2c7@haskell.org> #11771: ghc.exe: `panic'! (the 'impossible' happened); thread blocked indefinitely in an MVar operation ----------------------------------------+------------------------------- Reporter: YoYoYonnY | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- Here's a "fun" one: {{{#!hs *Main> main Interrupted. *Main> *Main> !cl ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > ghci --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 }}} Don't mind the {{{!cl}}}, GHC crashed as soon as the interupt was registered, I usually {{{:!cls}}} after I execute main. I will backup the code in case someone wants to see if it's a bug in my program, but I didn't use multithreading myself, and I don't think the vector, unordered-containers, bytestring and parsec packages use threading either (all heavily at work, though)... The interupt was nececairy because my code was generating a infinite (oops) collection of these bad boys, using all sorts of folds, maps, etc.: {{{#!hs newtype ParserData = ParserData { unpackParserData :: HashMap ByteString (ParserData -> Either ByteString (Parser ())) } }}} I am wondering if this could be a problem with Windows, because the system was running slow at the time of the interupt; The {{{Alt+Tab}}} screen didn't appear until after the interupt. I don't think I can manage to reproduce this bug, which is unfortunate aswell (low priority because of that :c). Either way, it crashed, that's all I can tell you for sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 16:56:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 16:56:13 -0000 Subject: [GHC] #11663: GHC 8.0 type assignment in arguments of lambda working without Scoped Type Variables In-Reply-To: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> References: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> Message-ID: <063.3d2f947388f02cd0f80e97fc89dee858@haskell.org> #11663: GHC 8.0 type assignment in arguments of lambda working without Scoped Type Variables -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2054 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d5d6804d37960ece2652196f3661604a70c12ffc/ghc" d5d6804d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d5d6804d37960ece2652196f3661604a70c12ffc" rename: Disallow type signatures in patterns in plain Haskell This should require -XScopedTypeVariables. It seems this was previously handled by RnTypes.rnHsBndrSig which called RnTypes.badKindSigErr but this was broken in Simon's refactor of wildcards, 1e041b7382b6aa329e4ad9625439f811e0f27232. Here we re-introduce a check in RnPat. See #11663. Test Plan: Validate with `T11663` Reviewers: austin, simonpj Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2054 GHC Trac Issues: #11663 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 17:00:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 17:00:42 -0000 Subject: [GHC] #11663: GHC 8.0 type assignment in arguments of lambda working without Scoped Type Variables In-Reply-To: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> References: <048.31aaccc85ccc72df05dc4d5011dee2c7@haskell.org> Message-ID: <063.fef3f791dad9ae7b29d137a9636c9660@haskell.org> #11663: GHC 8.0 type assignment in arguments of lambda working without Scoped Type Variables -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2054 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 01786339bce247cc8ca008d2be20a7b4b5519d40. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 17:01:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 17:01:30 -0000 Subject: [GHC] #11756: Data.Functor.Classes instances for Proxy In-Reply-To: <049.88e00c8489fafead34a109f21260f2c7@haskell.org> References: <049.88e00c8489fafead34a109f21260f2c7@haskell.org> Message-ID: <064.6097b3b84abeffddef4a593c47122fa3@haskell.org> #11756: Data.Functor.Classes instances for Proxy -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2051 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as dc81cca703559ffd4acb0a2f47c2f20956c22a3a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 17:39:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 17:39:29 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.dd47d4158795ccf65a2c17aa7ca5d79b@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:13 goldfire]: > This all means we can just do nothing about this particular issue. Which is nice. That is nice! What then, should we do about this program? (from [https://mail.haskell.org/pipermail/ghc-devs/2016-March/011645.html here]) {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeInType #-} module Cat where import Data.Kind class Cat k (cat :: k -> k -> *) where catId :: cat a a catComp :: cat b c -> cat a b -> cat a c instance Cat * (->) where catId = id catComp = (.) newtype Fun a b = Fun (a -> b) deriving (Cat k) }}} Currently, this generates an instance of the form `instance Cat * Fun` (i.e., the same thing as if you had written `deriving (Cat *)`. Would this be acceptable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 17:45:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 17:45:53 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.760845a63380ca36d6a3399c7bd31685@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): But this would lead to confusing behavior if there are any uninstantiated specified variables. If we did instantiation, then `:t f` would answer `Int -> Int -> Int`. That's reasonable enough, but then it's quite surprising when `:t f @Int` is accepted! In a somewhat similar scenario, say `bar :: forall a b. Show a => a -> b -> a`. What should `:t bar @Int` say? I offer 4 choices: 1. `forall b. Show Int => Int -> b -> Int` 2. `forall b. Int -> b -> Int` 3. `forall {b}. Int -> b -> Int` 4. `Int -> b -> Int` Here is how these could be produced: 1. This is what is currently done. No instantiation at `:type`. 2. This would require some new algorithm that instantiates a type and regeneralizes, being very careful to somehow notice when the instantiated variable arose from a specified variable and mark the re-generalized variable as specified. This becomes quite hard (both to implement and to specify) when equality constraints are in the mix and might combine a specified variable with an invisible one. 3. Instantiate and regeneralize. But now it looks like `bar @Int @Bool` should be rejected, even though it's actually OK. 4. Instantiate and do not regeneralize. Here, the user can't know that `bar @Int @Bool` is OK, but at least we're not suggesting that it should be rejected. As you can see, I prefer (1). It's conceivable to make a different choice when there are no top-level specified variables (so that a further type parameter would be an error), but I don't think we should. (Before arguing against me here, consider `quux :: forall a. Int -> forall b. Show a => b -> a -> Bool`. What should `:type quux @Int` say?) Another option I'd be happy with: Option (1) when `-fprint-explicit- foralls` is on, and option (3) when it's not. This might be surprising to users, but the benefits may outweigh the costs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 17:53:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 17:53:42 -0000 Subject: [GHC] #11772: GHC.CString.unpackCStringUtf8# is inlineable Message-ID: <046.23a256ea5dc7bfb61f0a59f301131ecb@haskell.org> #11772: GHC.CString.unpackCStringUtf8# is inlineable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core | Version: 7.10.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While looking through the logs of a build of a project I have lying around with a GHC 8.0 snapshot, I noticed that there may still be some fragile rules in the `text` package (see #11528 for a previous issue). The problem is that `GHC.CString.unpackCStringUtf8#` may be inlined, which may preempt the `TEXT literal UTF8` rule in `Data.Text.Show`. `unpackCStringUtf8#` doesn't seem like a terribly great candidate for inlining as it produces a list, {{{#!hs unpackCStringUtf8# :: Addr# -> [Char] }}} Moreover, the other functions in this module along these lines (e.g. `unpackCString#` are marked `NOINLINE`. Perhaps this should have a `NOINLINE` pragma as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 17:54:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 17:54:17 -0000 Subject: [GHC] #11772: GHC.CString.unpackCStringUtf8# is inlineable, shouldn't be? (was: GHC.CString.unpackCStringUtf8# is inlineable) In-Reply-To: <046.23a256ea5dc7bfb61f0a59f301131ecb@haskell.org> References: <046.23a256ea5dc7bfb61f0a59f301131ecb@haskell.org> Message-ID: <061.d3e0f1c50ea9398b2cf332de0bd3c3c1@haskell.org> #11772: GHC.CString.unpackCStringUtf8# is inlineable, shouldn't be? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 17:54:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 17:54:32 -0000 Subject: [GHC] #11772: GHC.CString.unpackCStringUtf8# is inlineable, shouldn't be? In-Reply-To: <046.23a256ea5dc7bfb61f0a59f301131ecb@haskell.org> References: <046.23a256ea5dc7bfb61f0a59f301131ecb@haskell.org> Message-ID: <061.57b0990410cc94815228c927bc2015c0@haskell.org> #11772: GHC.CString.unpackCStringUtf8# is inlineable, shouldn't be? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bos (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 17:59:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 17:59:04 -0000 Subject: [GHC] #11772: GHC.CString.unpackCStringUtf8# is inlineable, shouldn't be? In-Reply-To: <046.23a256ea5dc7bfb61f0a59f301131ecb@haskell.org> References: <046.23a256ea5dc7bfb61f0a59f301131ecb@haskell.org> Message-ID: <061.4cbe62b7813256d2b72756afa8d57671@haskell.org> #11772: GHC.CString.unpackCStringUtf8# is inlineable, shouldn't be? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2057 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2057 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 17:59:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 17:59:56 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.15d03ab5d565f64f412549293fd44220@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): As I just wrote in the email thread: we can argue that GHC is inferring a `k ~ *` constraint on the `Cat` instance. With that understanding, we're not so poorly off here. Just a reminder to all: we've strayed quite far from the original ticket, which concerns a bespoke instantiation check for `Generic` and `Generic1`. So my "do nothing" comment does not mean we can just close the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 18:09:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 18:09:16 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.326b6954c23e2c1ddee8e30286b6cc02@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5939 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #5939 Comment: OK, it sounds like we're converging on a consensus of being ultra- permissive in allowing GHC to unify visible type parameters when deriving instances. With that in mind, here's what we still need to do to fix this ticket: 1. When generating a `Rep`/`Rep1` instance [http://git.haskell.org/ghc.git/blob/eb6b7094c80fda5cc7c1d1ed3386486996f24bff:/compiler/typecheck/TcGenGenerics.hs#l482 here], do the appropriate type variable substitutions depending on the types the user provides. 2. Remove the broken instantiation check [http://git.haskell.org/ghc.git/blob/eb6b7094c80fda5cc7c1d1ed3386486996f24bff:/compiler/typecheck/TcGenGenerics.hs#l155 here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 18:13:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 18:13:03 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.8a7a7c11e9f7d4aa84c493a0b6df0ae9@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 18:28:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 18:28:15 -0000 Subject: [GHC] #11108: Weak references related crash In-Reply-To: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> References: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> Message-ID: <061.b25b4946003053670602913159b04c25@haskell.org> #11108: Weak references related crash -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: jme Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11746 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jme): In case anyone needs a workaround for this bug, try running with `+RTS -G1 -RTS` (so the garbage collector only uses one generation). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 20:05:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 20:05:44 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.96281ebc15bdafe8f33a5a81f32d3d36@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5939 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good points in comment:13, Richard. I'm happy with what Ryan suggests in comment:16. But it would be good to have a substantial `Note` to explain the thinking, with a link to this ticket. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 20:11:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 20:11:10 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.cfdb5ebcbd912bfe130f8964085e289c@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What should `:t bar @Int` say? I answer: the same as whatever type we infer for {{{ it = bar @Int }}} I guess that's answer (3): `it :: forall {b}. Int -> b -> Int`. No, it doesn't imply that `bar @Int @Bool` is illegal, any more than inferring that type for `it` implies that `bar @Int @Bool` is illegal. Use `:info` if you want to see which variables are specified! This rule is simple. Just infer the type, precisely as if it was a let- binding. No more and no less. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 21:33:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 21:33:03 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.82ac9377ef3e1d66bedcf6456adc72e9@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Grumble. Option (3) gives me no way to see what the next type parameter should be if I've already written a handful. I suppose we could introduce a new GHCi command that doesn't instantiate. I do agree that choosing (3) will be less surprising to more users than my option (1). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 21:34:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 21:34:43 -0000 Subject: [GHC] #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation In-Reply-To: <042.d49c422577da41f5c4d9261d67e3806a@haskell.org> References: <042.d49c422577da41f5c4d9261d67e3806a@haskell.org> Message-ID: <057.0fcefba8591a2fd160664e36bf99a82e@haskell.org> #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation -------------------------------------+------------------------------------- Reporter: hvr | Owner: ezyang Type: feature request | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10970 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 21:38:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 21:38:11 -0000 Subject: [GHC] #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation In-Reply-To: <042.d49c422577da41f5c4d9261d67e3806a@haskell.org> References: <042.d49c422577da41f5c4d9261d67e3806a@haskell.org> Message-ID: <057.460837700f47bc15215fbe2e2762c464@haskell.org> #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation -------------------------------------+------------------------------------- Reporter: hvr | Owner: ezyang Type: feature request | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10970 | Differential Rev(s): Phab:D2058 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D2058 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 21:47:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 21:47:51 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.905ed47825b4e7c1c96afb4a4e1a1c88@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: infoneeded => closed * resolution: => fixed Comment: The documentation for `Control.Concurrent.Chan` in the GHC git tree has been updated to include a warning that `Chan` inherits all the caveats of `MVar`s and suggests the use of `TChan` from the `stm` library instead. Closing this as "wontfix" but the "fix" is to use `TChan` instead of `Chan`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 21:48:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 21:48:14 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.9d5e51388329a8e08214b90c766eaeba@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Fair point, but I still think (3) is best. Are we agreed? I'm pretty sure it's a small change, but not sure where to make it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 22:05:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 22:05:22 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.422e056074f80ee96652cfcf74c89ecf@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Look in `TcRnDriver.tcRnExpr`. After the `tcInferSigma`, but still in the `pushLevelAndCaptureConstraints`, use `deeplyInstantiate` and `mkLHsWrap`. I'm afraid I can't conveniently test this right now, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 22:20:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 22:20:29 -0000 Subject: [GHC] #11766: Lazy application gives "No instance" error while strict application works In-Reply-To: <047.6457ae8316e008d1f2f63e8e30939ea4@haskell.org> References: <047.6457ae8316e008d1f2f63e8e30939ea4@haskell.org> Message-ID: <062.53c0fe842a79f2d6abd2209b9d9d1638@haskell.org> #11766: Lazy application gives "No instance" error while strict application works -------------------------------------+------------------------------------- Reporter: MichaelK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Happily this works in HEAD. Can someone check on the 8.0 branch? It'd might be easier for the regression test to use these defns {{{ t1 = cfun id foo $! Nothing t2 = let f = cfun id foo in f Nothing t3 = cfun id foo Nothing t4 = cfun id foo $ Nothing }}} But then remove the `Eq a` constraint from the `C` instance, which is ambiguous and only resolved by GHCi's generous defaulting. Check that `t4` does not work with RC2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 29 23:45:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Mar 2016 23:45:52 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.0a22969322955e72bfc040fc40523685@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I would have thought that if we're not hitting a fixed point in the attached example, we'd have a similar breakage in the example in the description, because we'd see the same tower of Nat's there, but that stripped down version compiles just fine. Is this something that only comes up when I ''use'' constraints like this somehow? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 03:22:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 03:22:48 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.50548706dbbdcf091d122cf298d2c1bd@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * cc: niteria (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 04:15:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 04:15:43 -0000 Subject: [GHC] #11732: Deriving Generic1 interacts poorly with TypeInType In-Reply-To: <047.27a25c470c88bbba69595642672c1832@haskell.org> References: <047.27a25c470c88bbba69595642672c1832@haskell.org> Message-ID: <062.330f5c4ac6798db6799a770d96844d2d@haskell.org> #11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5939 | Differential Rev(s): Phab:D2061 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2061 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 04:32:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 04:32:08 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.d2704a9a1b583665bcaab296a25f24a8@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): I've run into this while trying to hack together something like http://gcc.godbolt.org/, but for Haskell, with Core, Stg, Cmm and Asm output. With `-g` all the location data is already nicely tracked all the way to Asm and the only piece missing is a way to pretty print with some annotations about the ranges. I took a stab at adding a parameter to `Doc`, but I haven't gone through with it because [https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/main/ErrUtils.hs;eb6b7094c80fda5cc7c1d1ed3386486996f24bff$75-132 some other types] use it transitively and I couldn't decide between `SDoc a` and `SDoc Void` there. [http://hackage.haskell.org/package/pretty-1.1.3.2/docs/Text-PrettyPrint- Annotated.html pretty] appears to be the same library GHC uses and as pointed out by bgamari already supports annotations. Does anyone know if they diverged in functionality/semantics? If not, would it be a useful step to migrate GHC's `Doc` to annotated version? I think an argument against it is that it doesn't have a `Monad` instance, but I don't immediately see the benefit of having it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 06:34:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 06:34:12 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.b42c32a89d500d05ab13e7c1512dd7a9@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:19 niteria]: > Does anyone know if they diverged in functionality/semantics? If not, would it be a useful step to migrate GHC's `Doc` to annotated version? In #10735, I made GHC's copy of `pretty` pretty much the same as pretty-1.2.0, except GHC's copy uses `FastString` instead of `String`. pretty-1.2.1 has 2 more commits, but I didn't apply them because of performance worries (`compiler/utils/Pretty.hs` is incredibly performance sensitive!), see ticket:10735#comment:23. Right after pretty-1.2.1, those annotations were added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 06:44:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 06:44:29 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.8b2142655a41a85542fd50c4f4b6c7dd@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): comment:14 explains why there is no fixed point. Did the explanation make sense? Do you think there is a fixed point? The existence or otherwise of a fixpoint should not be related to how you use constraints. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 06:45:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 06:45:19 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.2dd79684e7e228ea229110d9ba5951f3@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > I've run into this while trying to hack together something like ?http://gcc.godbolt.org/, but for Haskell, Ahh, interesting. > `?pretty` appears to be the same library GHC uses and as pointed out by bgamari already supports annotations. Does anyone know if they diverged in functionality/semantics? If not, would it be a useful step to migrate GHC's `Doc` to annotated version? There were a few deviations, although I think most of them have been patched up by thomie (see #10735). > I think an argument against it is that it doesn't have a `Monad` instance, but I don't immediately see the benefit of having it. I think you ultimately **need** a `Monad` instance since this allows you to project your annotations back to the output currently producted by GHC. AFAICT the Hughes pretty-printer doesn't admit an efficient, correct monadic bind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 07:17:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 07:17:31 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.163e84f86d23808f628c7fb70e80d778@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8731 #10858 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 07:18:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 07:18:04 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.20e9e681af923410e01a7f23b5818898@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 07:19:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 07:19:24 -0000 Subject: [GHC] #8731: long compilation time for module with large data type and partial record selectors In-Reply-To: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> References: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> Message-ID: <060.0f5d745e0f1c6897111ae361520840b1@haskell.org> #8731: long compilation time for module with large data type and partial record selectors -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 07:21:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 07:21:19 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.57e382b08cafec7a06dd67013782de77@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 07:27:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 07:27:25 -0000 Subject: [GHC] #11184: panic tcMonoExpr _ with bad indentation in TH code In-Reply-To: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> References: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> Message-ID: <066.77e6861182eafc63dbcd755b1cc11e55@haskell.org> #11184: panic tcMonoExpr _ with bad indentation in TH code -------------------------------------+------------------------------------- Reporter: TeroLaitinen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): The panic occurs for the `EWildPat` constructor and the comments for that constructor (and some others) say (in the file compiler/hsSyn/HsExpr.hs): {{{ -- These constructors only appear temporarily in the parser. -- The renamer translates them into the Right Thing. }}} so the problem isn't really that the `EWildPat` constructor isn't handled, but rather that an error should have been reported when the renamer failed to translate it into the Right Thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 07:38:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 07:38:23 -0000 Subject: [GHC] #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration In-Reply-To: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> References: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> Message-ID: <061.8080b218bd3051739c1414bdf90477b2@haskell.org> #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yikes! That's terrible! As well as that outright bug, there's a strange duplication: * the demand analyser goes to some effort to annotate one-shot info (e.g. `annLamWithShotness`) * but so does the occurrence analyser (see the `occ_one_shots` field of `OccEnv`) Let's do it in the occurrence analyser, as now. So try this: * Get rid of all one-shot setting in the demand analyser, letting the occurrence analyser do the work. The demand analyser would then annotate only demand info. * BUT in `OccAnal.oneShotGroup` I'm suspicious of that `updOneShotInfo` which keeps one-shot info if it was there before. I don't think it's an actual bug, but I'd be much more comfortable with using `setIdOneShotInfo` instead. That's an orthogonal change. Would you like to try those two changes (ideally independently) and see what effect it has? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 07:49:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 07:49:49 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.78b4a5a5dbcd98901e28acda80a4b247@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1349, Wiki Page: | Phab:D1869 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:14 bgamari]: > This (Phab:D1869) will be merged when #11763 is implemented. #11763 has been implemetned already... but we should make sure that the Cabal 1.24 bundled with GHC 8 is updated to use `-fno-version-macros` so that Cabal controls 100% of which macros are made available to programs; it's a bad idea IMHO to have both, `cabal_macros.h` and `-fversion-macros` in effect even if it doesn't cause apparent problems *yet*. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 07:55:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 07:55:42 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.92f4300e1580d809688169bb6d6aafd1@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1349, Wiki Page: | Phab:D1869 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:7 rwbarton]: > Cabal builds with `-hide-all-packages` anyways, so this is no behavior change compared to what's currently implemented when building with Cabal. minor nitpick: This claim does not apply to `Setup.hs` unless a `custom- setup` section exists (and is understood by Cabal). However, things are becoming way more "interesting" for `Setup.hs` starting with GHC 8 & Cabal 1.24 & Stack ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 07:58:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 07:58:26 -0000 Subject: [GHC] #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration In-Reply-To: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> References: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> Message-ID: <061.f39312645462521c71d545eb38a3c6fa@haskell.org> #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"cb9a1e6875ac636f7c150ffacc272a2594a192dc/ghc" cb9a1e68/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cb9a1e6875ac636f7c150ffacc272a2594a192dc" Add testcase for #11770 and use normalise_errmsg_fun to check the core output in all.T, instead relying on code in the Makefile. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 08:05:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 08:05:19 -0000 Subject: [GHC] #11773: linux/powepc : ghc-stage1 segfaults when building unregisterised Message-ID: <044.a4a61ba55383f88cbd05cc1baa6706bc@haskell.org> #11773: linux/powepc : ghc-stage1 segfaults when building unregisterised --------------------------------+---------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Building unregisterised to test code paths that don't get tested in the registerised compile mode. The segfault: {{{ "inplace/bin/ghc-stage1" -static -O -H64m -Wall -Iincludes -Iincludes/dist \ -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header \ -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP \ -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen \ -Irts/dist/build -Irts/dist/build/autogen -O2 -Wnoncanonical-monad- instances \ -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o }}} seems to occur on powerpc, but not on x86_64 or armhf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 08:07:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 08:07:27 -0000 Subject: [GHC] #11773: linux/powepc : ghc-stage1 segfaults when building unregisterised In-Reply-To: <044.a4a61ba55383f88cbd05cc1baa6706bc@haskell.org> References: <044.a4a61ba55383f88cbd05cc1baa6706bc@haskell.org> Message-ID: <059.8634e6c0b7fef7248969bd2dd965a635@haskell.org> #11773: linux/powepc : ghc-stage1 segfaults when building unregisterised ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): If I add `-v2` to this command line I get: {{{ Created temporary directory: /tmp/ghc8899_0 *** C Compiler: *** ParseCmm [/tmp/ghc8899_0/ghc_1.cmmcpp]: !!! ParseCmm [/tmp/ghc8899_0/ghc_1.cmmcpp]: finished in 0.61 milliseconds, allocated 1.019 megabytes *** Deleting temp files: Warning: deleting non-existent /tmp/ghc8899_0/ghc_4.c Warning: deleting non-existent /tmp/ghc8899_0/ghc_3.hc *** Deleting temp dirs: ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160330 for powerpc-unknown-linux): hscCmmFile: no_mod }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 08:22:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 08:22:03 -0000 Subject: [GHC] #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration In-Reply-To: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> References: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> Message-ID: <061.c6389459699188ad5541421fd1b0d796@haskell.org> #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Get rid of all one-shot setting in the demand analyser, letting the occurrence analyser do the work. The demand analyser would then annotate only demand info. But would that not mean that useful one-shot information determined by the demand analyzer will not be reflected here, and hence not used in later passes, e.g. by the simplifier when trying to to floating a let into a lambda? > I'm suspicious of that updOneShotInfo which keeps one-shot info if it was there before. Note that due to the magic `oneShot` function, there might be one-shot info worth preserving. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 08:39:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 08:39:44 -0000 Subject: [GHC] #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration In-Reply-To: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> References: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> Message-ID: <061.d4c58c0fb0f292c166b614f6b3c62814@haskell.org> #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:3 nomeata]: > But would that not mean that useful one-shot information determined by the demand analyzer will not be reflected here, and hence not used in later passes, e.g. by the simplifier when trying to to floating a let into a lambda? No, that'll be fine: the occurrence analyser runs before each pass of the simplifier. > Note that due to the magic `oneShot` function, there might be one-shot info worth preserving. Good point! Please comment this prominently with `updOneShotInfo`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 09:20:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 09:20:55 -0000 Subject: [GHC] #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration In-Reply-To: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> References: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> Message-ID: <061.fdb2e56fa0f8fad69b4ac8fc9057aec6@haskell.org> #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > No, that'll be fine: the occurrence analyser runs before each pass of the simplifier. Aha, the OccurAnal code actually looks at `idDemandInfo` of a let-bound expression. Didn?t know that, but it makes sense now. I?ll add that to the relevant note. > Good point! Please comment this prominently with updOneShotInfo. Done, in `wip/T11770` for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 09:29:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 09:29:42 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.a7936dd823cc200663553b29ffbffe9b@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This recently come up again on ghc-devs, https://mail.haskell.org/pipermail/ghc-devs/2016-March/011655.html. It has also come up repeatedly in the past as pointed out in that thread, ? 2016: https://mail.haskell.org/pipermail/haskell- cafe/2016-February/122874.html ? 2012: http://stackoverflow.com/questions/14039726/how-to-make-haskell- or-ghci-able-to-show-chinese-characters-and-run-chinese-char ? 2012 again: https://mail.haskell.org/pipermail/haskell- cafe/2012-July/102569.html ? 2011: http://stackoverflow.com/questions/5535512/how-to-hack-ghci-or- hugs-so-that-it-prints-unicode-chars-unescaped ? 2010: https://mail.haskell.org/pipermail/haskell- cafe/2010-August/082823.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 10:56:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 10:56:43 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.218993c23ad77442ce36be4406bb6867@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D2064 Comment: A small change to `exprIsTrivial` fixes this at least for the test case produced above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 11:27:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 11:27:34 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.cc9e197f51def4e97f8fc3efc9d67633@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): For the record, here is the proposed fix (currently on a wip branch): {{{ commit 7ac5610606e8f338cd2eb92eb5d711e054d9d55a Author: Joachim Breitner Date: Wed Mar 30 12:55:10 2016 +0200 Used-once variables are not trivial The specification for exprIsTrivial demands that we are unconditionally happy to duplicate the expression. This is not true for variables where we would like to exploit (or already have exploited) that they are used at most once. In order to preserve this property, they must not be duplicated nilly-willy. This fixes #11731 and comes with a test case. >--------------------------------------------------------------- 7ac5610606e8f338cd2eb92eb5d711e054d9d55a compiler/coreSyn/CoreUtils.hs | 12 +++++++- testsuite/.gitignore | 1 + testsuite/tests/simplCore/should_run/T11731.hs | 36 ++++++++++++++++++++++ testsuite/tests/simplCore/should_run/T11731.stderr | 1 + testsuite/tests/simplCore/should_run/all.T | 1 + 5 files changed, 50 insertions(+), 1 deletion(-) diff --git a/compiler/coreSyn/CoreUtils.hs b/compiler/coreSyn/CoreUtils.hs index 1d9b83b..d02b934 100644 --- a/compiler/coreSyn/CoreUtils.hs +++ b/compiler/coreSyn/CoreUtils.hs @@ -62,6 +62,7 @@ import DataCon import PrimOp import Id import IdInfo +import Demand ( isUsedOnce ) import Type import Coercion import TyCon @@ -755,6 +756,13 @@ Note [exprIsTrivial] Note [Variables are trivial] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Variables are usually trivial. + +Except if 'isUsedOnce (idDemandInfo v) == True': +In this case we have previously determined that a variable is used at +most once, and we likely rely on this information, e.g. during code +generation. In this case, we are not unconditionally happy to duplicate, so we don?t. See #11731. + There used to be a gruesome test for (hasNoBinding v) in the Var case: exprIsTrivial (Var v) | hasNoBinding v = idArity v == 0 @@ -793,7 +801,9 @@ it off at source. -} exprIsTrivial :: CoreExpr -> Bool -exprIsTrivial (Var _) = True -- See Note [Variables are trivial] +exprIsTrivial (Var v) -- See Note [Variables are trivial] + | isUsedOnce (idDemandInfo v) = False + | otherwise = True exprIsTrivial (Type _) = True exprIsTrivial (Coercion _) = True exprIsTrivial (Lit lit) = litIsTrivial lit }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 11:30:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 11:30:58 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.74c0bd6e618f8c1f9edbdb2319e0ac4d@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): The change is also visible at Phab:D2064. (So much duplication of code.. :-() Unfortunately, while it fixes the problem in the above test case, it does not yet fix the instance observed in nofib. I?m investigating... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 12:14:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 12:14:06 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.808b151b7894f3338e2059f097466c59@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 12:42:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 12:42:37 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.7ff7e9629f2104724e90af2bb98e0ccf@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"1757dd8ebed0732018319e43e6468b868a6aceeb/ghc" 1757dd8e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1757dd8ebed0732018319e43e6468b868a6aceeb" Don't recompute some free vars in lintCoercion As pointed out by @simonpj on D2044 we don't need to compute the free vars of the range of the substitution as most of them are already carried by the monad. This should be a tiny performance improvement over the version from before D2044. Also removes an extra function that is now unnecessary. Test Plan: ./validate && ./validate --slow Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: thomie, simonmar, simonpj Differential Revision: https://phabricator.haskell.org/D2060 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 12:46:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 12:46:30 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.3d512ccbeb842362964511db9264cd7e@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I think I nailed it. With the above change, demand information becomes something that we should try to keep hold on. But we don?t: {{{#!hs simplExprF1 env expr@(Lam {}) cont = simplLam env zapped_bndrs body cont -- The main issue here is under-saturated lambdas -- (\x1. \x2. e) arg1 -- Here x1 might have "occurs-once" occ-info, because occ-info -- is computed assuming that a group of lambdas is applied -- all at once. If there are too few args, we must zap the -- occ-info, UNLESS the remaining binders are one-shot where (bndrs, body) = collectBinders expr zapped_bndrs | need_to_zap = map zap bndrs | otherwise = bndrs need_to_zap = any zappable_bndr (drop n_args bndrs) n_args = countArgs cont -- NB: countArgs counts all the args (incl type args) -- and likewise drop counts all binders (incl type lambdas) zappable_bndr b = isId b && not (isOneShotBndr b) zap b | isTyVar b = b | otherwise = zapLamIdInfo b }}} Here, we would remove the demand information from the parameters of a top- level function (unless all of them happen to be one-shot-binders). I don?t fully understand the comment here. Does "occurs-once" refer to occurence information only? But `zapLamInfo` in `IdInfo` also removes Demand information...sometimes. This looks delicate. Why does demand information (which is calculated from the body of the lamda, not how it is being used) need to be zapped in `zapLamInfo` at all? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 16:03:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 16:03:08 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.ece760ff38e57c9d9cb374ab2a02f78b@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > A small change to exprIsTrivial fixes this And almost validates, with one exception. There is an increase of allocations in T5549 by 10%. The -ddump-simpl differs only slightly: In the code of {{{#!hs aux (_,0) _ = ([],0) aux _ (_,0) = ([],0) aux (a@(ha:as),la) (b@(hb:bs), lb) | ha == hb = let (s,n) = aux (as,la-1) (bs,lb-1) in (ha : s, n+1) | otherwise = let (sa,na) = aux (as,la-1) (b,lb) -- ? (sb,nb) = aux (a,la) (bs,lb-1) in if na > nb then (sa,na) else (sb,nb) }}} the marked recursive call to `aux` re-assembles the second tuple argument, instead of passing the tuple that was passed to `aux`; this is CSE failing. CSE uses `exprIsTrivial` in `tryForCSE`. From my reading of the code, in the context of {{{ case foo of foo' { (x [Dmd=], y) -> ... case x of z { ... (x,y) ... } }}} it would previously *not* CSE the inner mention of `x` to `z`, as `x` is trivial, and then successfully replace `(x,y)` with `foo'`. But after my change, `x` is no longer trivial, so it does CSE it to `z`, and then leave `(z,y)` as it is. Digging further into it, I found some code smell in CSE. Note `Case binders 2` says that with trivial scrutinees, we want a mapping `case binder -> scrutinee` instead of the usual `scrutinee -> case binder`. Nevertheless, `cseExpr` in the case for `Case` adds the unwanted mapping via `cseRhs`. Only the check for `exprIsTrivial` in `tryForCSE` prevents this entry from being used. Fixing this code smell (I?ve just updated Phab:D2064 in a moment) fixes this particular regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 16:06:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 16:06:21 -0000 Subject: [GHC] #11774: Regression on GHC 8 branch (vs 7.10.3) when using the GHC API to parse code that uses TH Message-ID: <050.40af602ae9a228b0dca3c0dd3ac155f0@haskell.org> #11774: Regression on GHC 8 branch (vs 7.10.3) when using the GHC API to parse code that uses TH ----------------------------------------+--------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- If you use the GHC API to parse code that uses TH, the code does not work after a {{{:reload}}} in {{{ghci}}} anymore. = Steps to reproduce Given the following three modules {{{#!hs module Extract where import Prelude hiding (mod) import Data.Generics import DynFlags import FastString import GHC import GHC.Paths import Control.Monad import Digraph (flattenSCCs) extractDocStrings :: IO [String] extractDocStrings = do concatMap (extract . pm_parsed_source . tm_parsed_module) <$> do runGhc (Just libdir) $ do _ <- getSessionDynFlags >>= setSessionDynFlags . setHaddockMode guessTarget "Foo.hs" Nothing >>= setTargets . return mods <- depanal [] False >>= enableCompilation let sortedMods = flattenSCCs (topSortModuleGraph False mods Nothing) mapM (parseModule >=> typecheckModule >=> loadModule) sortedMods where setHaddockMode :: DynFlags -> DynFlags setHaddockMode dynflags = (gopt_set dynflags Opt_Haddock) extract :: ParsedSource -> [String] extract m = [unpackFS s | HsDocString s <- everything (++) ([] `mkQ` return) m] enableCompilation :: ModuleGraph -> Ghc ModuleGraph enableCompilation modGraph = do let enableComp d = let platform = targetPlatform d in d { hscTarget = defaultObjectTarget platform } modifySessionDynFlags enableComp let upd m = m { ms_hspp_opts = enableComp (ms_hspp_opts m) } let modGraph' = map upd modGraph return modGraph' modifySessionDynFlags :: (DynFlags -> DynFlags) -> Ghc () modifySessionDynFlags f = do dflags <- getSessionDynFlags let dflags' = case lookup "GHC Dynamic" (compilerInfo dflags) of Just "YES" -> gopt_set dflags Opt_BuildDynamicToo _ -> dflags _ <- setSessionDynFlags (f dflags') return () }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Foo where import Bar -- | some documentation foo :: Int foo = $(bar) }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bar where bar = [|23|] }}} == Expected (GHC 7.10.2 behavior) {{{ $ ghci Extract.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help *Extract> extractDocStrings [" some documentation"] *Extract> :reload *Extract> extractDocStrings [" some documentation"] }}} == Actual (GHC 8.0.0.20160329 behavior) {{{ $ ghci Extract.hs GHCi, version 8.0.0.20160329: http://www.haskell.org/ghc/ :? for help *Extract> extractDocStrings [" some documentation"] *Extract> :reload *Extract> extractDocStrings /tmp/ghc24970_1/libghc_7.so: file not recognized: File truncated collect2: error: ld returned 1 exit status *** Exception: `gcc' failed in phase `Linker'. (Exit code: 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 16:07:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 16:07:46 -0000 Subject: [GHC] #11774: Regression on GHC 8 branch (vs 7.10.3) when using the GHC API to parse code that uses TH In-Reply-To: <050.40af602ae9a228b0dca3c0dd3ac155f0@haskell.org> References: <050.40af602ae9a228b0dca3c0dd3ac155f0@haskell.org> Message-ID: <065.50ae14fa965560100c1907490bf20595@haskell.org> #11774: Regression on GHC 8 branch (vs 7.10.3) when using the GHC API to parse code that uses TH -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by SimonHengel): * failure: None/Unknown => Incorrect result at runtime -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 16:45:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 16:45:39 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.3a6da126853cc05896ad2bdae8f2822b@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I agreed comment:18 is odd, but first why does "demand information become something we should try to keep hold on"? What, specifically, goes wrong? The reasoning here is as follows. Consider {{{ let f = \xy. x+y in ...map (f expensive).... }}} Now, in `f`'s definition `x` and `y` are both marked * `OneOcc not-in-lambda` (syntactically occurring once not inside a lambda; added by the occurrence analyser) * Demanded (added by the demand analyser) These annotations assume that `f` is fully applied But when we inline `f` at this partial application site, we get {{{ ...map (let x = expensive in \y. x+y)... }}} and now `x` jolly well shouldn't be marked as occurring not inside a lambda; nor should it be marked as strictly demanded. Hence the `zapLamIdInfo`. What I had forgotten (and has somehow never arisen) is that this ''also'' happens at `f` definition site. Maybe it doesn't matter. Back to the quesion at the beginning: why does it matter? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 17:26:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 17:26:46 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.c39af23b9b1d6c23f1830b13c0e7e507@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Over at Phab you write > I still think this is the wrong approach. but now I?m confused. Where did you say what?s wrong with this approach? This approach is my attempt to implement your suggestion ?Perhaps we should simply refrain from inlining x under these circumstances? from comment:5! From this suggestion, we need to detect ?these circumstances?, which requires us to detect that ?The demand signature on y is marked "used- once"?. And this implies that looking at demand information. And this implies that we need to keep hold to it. Personally, I quite agree that the annotation should *not* be something we need to hold on to, although I don?t have a convincing solution, only the rough ideas above that boil down to systematically distinguishing between variables that guarantee to have sharing behavior and those where this is not guaranteed. Anyways, thanks for the explanation about `zapLamIdInfo`. It makes perfect sense when inlining a function into an expression. But do you agree that it should not be done to `f`?s definition? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 19:20:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 19:20:23 -0000 Subject: [GHC] #11772: GHC.CString.unpackCStringUtf8# is inlineable, shouldn't be? In-Reply-To: <046.23a256ea5dc7bfb61f0a59f301131ecb@haskell.org> References: <046.23a256ea5dc7bfb61f0a59f301131ecb@haskell.org> Message-ID: <061.81462594236e0b774b63bfc56c882908@haskell.org> #11772: GHC.CString.unpackCStringUtf8# is inlineable, shouldn't be? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2057 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"58bbb40ba23860df2ede1275493ef32ba69a2083/ghc" 58bbb40b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="58bbb40ba23860df2ede1275493ef32ba69a2083" ghc-prim: Mark unpackCStringUtf8# and unpackNBytes# as NOINLINE There is no benefit to be had from inlining this function and it may defeat rewrite rules if inlined early. See #11772.. Test Plan: Validate, nofib Reviewers: simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2057 GHC Trac Issues: #11772 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 19:36:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 19:36:09 -0000 Subject: [GHC] #11775: singleton classes in ghc.generics are defined but not exported Message-ID: <045.c976fcd38645e557c12a54aae45ad035@haskell.org> #11775: singleton classes in ghc.generics are defined but not exported -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed in the bottom of the GHC.Generics module in the RC candidate that theres some type classea and instnaces involving singletons included and notated as copied from the singletons package but not exported {{{ -------------------------------------------------------------------------------- -- Copied from the singletons package -------------------------------------------------------------------------------- -- | The singleton kind-indexed data family. data family Sing (a :: k) -- | A 'SingI' constraint is essentially an implicitly-passed singleton. -- If you need to satisfy this constraint with an explicit singleton, please -- see 'withSingI'. class SingI (a :: k) where -- | Produce the singleton explicitly. You will likely need the @ScopedTypeVariables@ -- extension to use this method the way you want. sing :: Sing a -- | The 'SingKind' class is essentially a /kind/ class. It classifies all kinds -- for which singletons are defined. The class supports converting between a singleton -- type and the base (unrefined) type which it is built from. class (kparam ~ 'KProxy) => SingKind (kparam :: KProxy k) where -- | Get a base type from a proxy for the promoted kind. For example, -- @DemoteRep ('KProxy :: KProxy Bool)@ will be the type @Bool at . type DemoteRep kparam :: * -- | Convert a singleton to its unrefined version. fromSing :: Sing (a :: k) -> DemoteRep kparam }}} etc, is this deliberate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 19:44:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 19:44:41 -0000 Subject: [GHC] #11775: singleton classes in ghc.generics are defined but not exported In-Reply-To: <045.c976fcd38645e557c12a54aae45ad035@haskell.org> References: <045.c976fcd38645e557c12a54aae45ad035@haskell.org> Message-ID: <060.3a60a9ac09e173b10fe5e215bc16b2e0@haskell.org> #11775: singleton classes in ghc.generics are defined but not exported -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yes, it's used in instances defined in `GHC.Generics`. e.g., {{{#!hs instance (KnownSymbol n, SingI f, SingI r) => Constructor ('MetaCons n f r) where conName _ = symbolVal (Proxy :: Proxy n) conFixity _ = fromSing (sing :: Sing f) conIsRecord _ = fromSing (sing :: Sing r) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 19:44:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 19:44:57 -0000 Subject: [GHC] #11775: singleton classes in ghc.generics are defined but not exported In-Reply-To: <045.c976fcd38645e557c12a54aae45ad035@haskell.org> References: <045.c976fcd38645e557c12a54aae45ad035@haskell.org> Message-ID: <060.107aaee5001a274915982239a1ac004c@haskell.org> #11775: singleton classes in ghc.generics are defined but not exported -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 19:48:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 19:48:04 -0000 Subject: [GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing In-Reply-To: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> References: <048.afe018e9c476201f0e5d365a705b643c@haskell.org> Message-ID: <063.f598e93bdf93b3deee906ea98982ccc3@haskell.org> #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've given the same treatment to the `Ord` instances in c0e3e63eca6b0f7a21ae51d992c88821195ad94d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 19:50:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 19:50:11 -0000 Subject: [GHC] #11772: GHC.CString.unpackCStringUtf8# is inlineable, shouldn't be? In-Reply-To: <046.23a256ea5dc7bfb61f0a59f301131ecb@haskell.org> References: <046.23a256ea5dc7bfb61f0a59f301131ecb@haskell.org> Message-ID: <061.fc49047aa3e273b5f115ce051f0d040b@haskell.org> #11772: GHC.CString.unpackCStringUtf8# is inlineable, shouldn't be? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2057 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as c8163959e03d9c5777d3b02be38f3591d3d169a2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 20:25:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 20:25:15 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.994b9ac3bf7884303b05d137b9760836@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well that's extremely annoying. I'd typed a long comment in, but Trac has binned it somehow. Sigh. I have concluded that the approach in comment:16 (based on my suggestion in comment:5) is too fragile. * As Ben points out there are other `exprIsTrivial` variants. * We'd probably need to do similar surgery for `exprIsCheap`, lest we change sharing by floating something like {{{ x = case v of (p,q) -> p }}} out, aand then discover we know that `v` is a pair `(x,y)`, so it all turns into `x=y` in short, I'm just not confident that we can be sure to maintain this single-entry property. Moreover, ''these restrictions cripple otherwise-useful transformations''. For example, we might end up with a function that claims to evaluate its argument at most once, but to maintain that claim looks like `\x. let y = x in ...body...`. So now two thunks get allocated for every call, one single entry, and one indirection-thunk that does the update. This is bad bad. Much better, I think, to do this: * Allow unrestricted transformation, as now, with no guarantees about maintaining single-entry-nes. Indeed maybe the demand analyser should not even record signle-entry-ness in the Ids, since it is so fragile. * Just before code generation, perhaps even after `CorePrep`, do demand analysis ''but not worker-wrapper''. So all it does is pin on the single- entry-ness to each thunk, just before it is needed in `CoreToStg`. No simplifier pass afterwards to mess it up! That should nail it in a robust way. Note that this final demand-analysis is there solely to attach single- entry-ness. We might still want to do "late demand analysis" with `-O2`, as now, complete with worker/wrapper and subsequent simplification pass, to exploit the usual w/w benefits of strictness exposed at later stages of the pipeline. That becomes an independent choice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 20:46:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 20:46:52 -0000 Subject: [GHC] #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation In-Reply-To: <042.d49c422577da41f5c4d9261d67e3806a@haskell.org> References: <042.d49c422577da41f5c4d9261d67e3806a@haskell.org> Message-ID: <057.6cd63124d6a80b329d882ae02fd633b8@haskell.org> #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation -------------------------------------+------------------------------------- Reporter: hvr | Owner: ezyang Type: feature request | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10970 | Differential Rev(s): Phab:D2058 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bc953fcdbc76ffbb4f06a2b74be271268f73328f/ghc" bc953fc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bc953fcdbc76ffbb4f06a2b74be271268f73328f" Add -f(no-)version-macro to explicitly control macros. Test Plan: validate Reviewers: thomie, austin, bgamari Reviewed By: bgamari Subscribers: hvr Differential Revision: https://phabricator.haskell.org/D2058 GHC Trac Issues: #11763 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 20:46:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 20:46:52 -0000 Subject: [GHC] #10886: Remove the magic from `Any` In-Reply-To: <047.f678cbb73069d1c6ee1f63fe7d449257@haskell.org> References: <047.f678cbb73069d1c6ee1f63fe7d449257@haskell.org> Message-ID: <062.edd2329aaee3d4a5f68b3d64831216c4@haskell.org> #10886: Remove the magic from `Any` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2049 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"24d761531cfc18152598becc0aeb90376fd19198/ghc" 24d76153/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="24d761531cfc18152598becc0aeb90376fd19198" Kill the magic of Any This turns `Any` into a standard wired-in type family defined in `GHC.Types`, instead its current incarnation as a magical creature provided by the `GHC.Prim`. Also kill `AnyK`. See #10886. Test Plan: Validate Reviewers: simonpj, goldfire, austin, hvr Reviewed By: simonpj Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2049 GHC Trac Issues: #10886 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 20:46:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 20:46:52 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.04f7d8187b616f4794474eb7ac60461e@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1349, Wiki Page: | Phab:D1869 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e9c2555ac666912f7dff56448ced4bfa06d14e76/ghc" e9c2555/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e9c2555ac666912f7dff56448ced4bfa06d14e76" Don't require -hide-all-packages for MIN_VERSION_* macros Define MIN_VERSION_pkgname and VERSION_pkgname macros for all exposed packages, without requiring -hide-all-packages. See #10970 comment 7-10 for discussion. Reviewers: duncan, ezyang, bgamari, austin Reviewed By: ezyang Subscribers: hvr, rwbarton Differential Revision: https://phabricator.haskell.org/D1869 GHC Trac Issues: #10970 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 20:57:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 20:57:10 -0000 Subject: [GHC] #11776: RTS segfaults when printing profiling information which refers to unloaded objects Message-ID: <046.fc47333743fc6f4f1fd8d834c9aff42c@haskell.org> #11776: RTS segfaults when printing profiling information which refers to unloaded objects -------------------------------------+------------------------------------- Reporter: afarmer | Owner: afarmer Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running a profiled binary which loads/unloads objects via the RTS's linker results in a CCS tree with pointers to the shared objects. These references are not checked by checkUnload before unloading the object. Then, when the profiling report is printed at the end of the program, a segfault occurs. Plan: 1. Add a test case for this. 2. Modify checkUnload to prevent objects from being unloaded if the CCS tree points to them. 3. Modify generateCCSReport to prune the CCS tree after a report is printed. 4. Expose some way to generate a report on demand, so long-running programs don't keep every object loaded forever. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 22:18:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 22:18:37 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.789db071413f6efdf840d043beb53e1b@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Sounds reasonable, but it raises a few questions: > Indeed maybe the demand analyser should not even record signle-entry- ness in the Ids, since it is so fragile. Yes, I?m all for not storing information that we do not keep up-to-date, as it will just be too likely that a later pass uses them, and things break again in obscure places. But then this should also apply to the strictness-and-demand signature of functions, which should be stripped of any `1*` information! But that?s not too bad; the final, non-ww pass could attach full strictness signatures to exported functions (at least as long as we don?t have CSE as a STG-to-STG-transformation as proposed in #9291). What should be the consequence for `OneShot` annotations on lambda binders? Don?t all the same considerations apply here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 22:24:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 22:24:21 -0000 Subject: [GHC] #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration In-Reply-To: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> References: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> Message-ID: <061.9fe1c10f1b887ebc5689a65f45955009@haskell.org> #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2070 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D2070 Comment: The branch with this patch on has passed through validation a few times, so I think it?s safe to merge this; put it up for a brief review at Phab:D2070. Code removal is always nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 23:10:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 23:10:42 -0000 Subject: [GHC] #11776: RTS segfaults when printing profiling information which refers to unloaded objects In-Reply-To: <046.fc47333743fc6f4f1fd8d834c9aff42c@haskell.org> References: <046.fc47333743fc6f4f1fd8d834c9aff42c@haskell.org> Message-ID: <061.042f4524dc66ef8c6f93fc7462bc3094@haskell.org> #11776: RTS segfaults when printing profiling information which refers to unloaded objects -------------------------------------+------------------------------------- Reporter: afarmer | Owner: afarmer Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:2067 Wiki Page: | Phab:2068 Phab:2069 Phab:2071 -------------------------------------+------------------------------------- Changes (by afarmer): * status: new => patch * differential: => Phab:2067 Phab:2068 Phab:2069 Phab:2071 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 30 23:11:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Mar 2016 23:11:18 -0000 Subject: [GHC] #11776: RTS segfaults when printing profiling information which refers to unloaded objects In-Reply-To: <046.fc47333743fc6f4f1fd8d834c9aff42c@haskell.org> References: <046.fc47333743fc6f4f1fd8d834c9aff42c@haskell.org> Message-ID: <061.66479e177458e2d171c0ae6eb4092253@haskell.org> #11776: RTS segfaults when printing profiling information which refers to unloaded objects -------------------------------------+------------------------------------- Reporter: afarmer | Owner: afarmer Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2067 Wiki Page: | Phab:D2068 Phab:D2069 Phab:D2071 -------------------------------------+------------------------------------- Changes (by afarmer): * differential: Phab:2067 Phab:2068 Phab:2069 Phab:2071 => Phab:D2067 Phab:D2068 Phab:D2069 Phab:D2071 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 01:11:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 01:11:44 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.33ea6c6fe18a0e764cfc638293919643@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chak): Replying to [comment:2 dfeuer]: > Absolutely any code in the entire world that relies on the current behavior will break. The current behavior is expressed in the reference implementation in the Haskell 2010 report. Frankly, changing it ''is not an option''. You can write your own function to unescape valid Unicode. You can also write your own `UShow` class if you like with a method for showing various things using Unicode generally. You can then try to convince other developers to depend on your package and write instances of your class. I disagree. I think, the current implementation is actually wrong and does not adhere to the standard. The standard states in 16.6 that `showLitChar` be defined as follows: > Convert a character to a string using only printable characters, using Haskell source-language escape conventions. However, the current implementation of `showLitChar` fail to use `isPrint`; instead it uses a naive condition, `c > '\DEL'`, to determine printability. This is wrong. The solution is simple, replace the condition `c > '\DEL'` by `not (isPrint c)` in the definition of `showLitChar`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 02:26:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 02:26:16 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.0de3e25418316b589364e8da126c3d68@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by allbery_b): isPrint does not answer the question "can this character be displayed by the current user given their current locale?". That would require it to be in IO, and would limit the ability to use it in other contexts. isPrint answers the question "is the Unicode codepoint contained in the given Char considered printable by the version of the Unicode standard to which the runtime conforms?". It is not the correct question to ask here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 03:14:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 03:14:18 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.72f29e3f7986d18a4bcbe8f043db7678@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 07:12:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 07:12:03 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.cf9e2208fe5eabe9531031dfb232e52e@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): * The awkwardness of not recording top-level 1* info is that we'd need a demand-analyser flag to tell it whether to do so or not. * I've just realised that this final sweep (dmd anal only) must be just before `CoreTidy`. Reason: currently anyway, `CoreTidy` establishes the exported strictness signatures. We do want to export `f` with a "I use my arg at most once" `1*` annotation. So we want to pin in reliable info just before we freeze it for export, and then not invalidate it. One thing I have longed to do for some time is to get CAF info from the STG form, and combine that CAF info into the `ModIface` bindings. Currently we ''predict'' what it'll be at `CoreTidy`, which is fragile. Maybe the same holds for strictness/usage info. * `OneShot` annotations on lambda binders are a different matter. They say something about the use of the ''function'', not about the use of the binder in the function body. Can a `OneShot` annotation go wrong? Yes if we call that function twice instead of once. But GHC really is pretty paranoid about duplicating arbitrary amounts of work so we are at least much safer here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 07:48:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 07:48:19 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.32567eaa7c26ea8f2ebbed8be63d9f54@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > The awkwardness of not recording top-level `1*` info is that we'd need a demand-analyser flag to tell it whether to do so or not. Not too awkward, there is `AnalEnv` that can hold on to it. But alternatively, we could do a second sweep that goes through the AST after DmdAnal and remove the bits we want removed. This would allow the demand analyzer to set and make use of `1*` internally, e.g. during fixed- point iteration and such. This pass would also allow us to set the `OneShot` annotations on lambda binders based on the demand on the function, before we remove it ? the occurrence analyzer cannot do it for us any more. Or we move the onus of removing invalidated demand signatures onto the pass that actually invalidates them, and just be much more aggressive about this. The occurrence analyzer (if we think of it as the first thing done by the simplifier) would be a natural choice, with the added benefit that it can still use the information to set `OneShot` information before zapping it. > Can a `OneShot` annotation go wrong? I cannot construct an example out of my head that would still work if we eradicated thanks that are wrongly marked as single entry, so we might be safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 08:47:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 08:47:33 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.36dc2bad6335284edf6c0ab71add0377@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Let's be careful to distinguish three kinds of `IdInfo`, all pinned on an `Id`: * `demandInfo`: says how the `Id` is used (demanded) by its scope. * `strictnessInfo`: describes the demand transformer for the `Id`; it tnansforms a demand on the `Id` to a demand on its arguments and free variables. * `oneShotInfo`: for lambda-bound `Id`s only, says whether the function is called at most once. (It says nothing about how the `Id` is used in the body of the lambda.) I think we have decided (#11770) that * only the demand analyser sets `demandInfo` and `strictnessInfo` * only the occurrence analyser sets `oneShotInfo`. The `demandInfo` on an `Id` includes `1*` usage info, which is fragile so perhaps we should erase it. The `strictnessInfo` on an `Id` also contains `1*` usage info, e.g about the function arguments. That too is fragile to transformations of the function body, so perhaps we should erase it too. I've just realised that a convenient place to erase it might be the worker/wrapper pass. So then we'd have * the demand analyser sets `demandInfo` and `strictnessInfo` * the worker-wrapper pass erases 1* info from `demandInfo` and `strictnessInfo` * the occurrence analyser sets `oneShotInfo` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 08:54:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 08:54:19 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.eda4c3420b22c36b8c26c29f0846a674@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Sounds like a plan. I am currently checking the effect of a very late, non-ww, demand analyzer. Are you sure that that is the most convenient place? * It would no longer get erased with `-fstrictness -fno-worker-wrapper`. Although we might argue that this is not a supported configuration. * Since the worker-wrapper pass happens before the next occurrence analyzer (does it?), the occurrence analyzer no longer sees the `1*` `demandInfo` and thus cannot set the `oneShotInfo`. Why not do it in the occurrence analyser? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 08:57:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 08:57:52 -0000 Subject: [GHC] #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration In-Reply-To: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> References: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> Message-ID: <061.aeee32fc94c28b499fa4d8b0bba8be16@haskell.org> #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2070 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"28fe0eea4d161b707f67aae26fddaa2e60d8a901/ghc" 28fe0ee/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="28fe0eea4d161b707f67aae26fddaa2e60d8a901" Demand Analyzer: Do not set OneShot information as suggested in ticket:11770#comment:1. This code was buggy (#11770), and the occurrence analyzer does the same job anyways. This also elaborates the notes in the occurrence analyzer accordingly. Differential Revision: https://phabricator.haskell.org/D2070 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 09:00:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 09:00:36 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.2356e69f8992cec2897ebc5387c9b333@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > * It would no longer get erased with `-fstrictness -fno-worker- wrapper`. Although we might argue that this is not a supported configuration. I'm very dubious about `-no-worker-wrapper`. Maybe we should kill it off. > * Since the worker-wrapper pass happens before the next occurrence analyzer (does it?), the occurrence analyzer no longer sees the `1*` `demandInfo` and thus cannot set the `oneShotInfo`. False. The occurrence analyser uses call-once `C1` info (the `Count` argument to `UCall`). It does not use the demanded-once `1*` info (the `Count` field to `Use`). It is the latter that we are going to erase, NOT the former. > Why not do it in the occurrence analyser? By "it" I guess you mean the erasure? Because the occurrence analyser runs repeatedly; no sense in repeatedly erasing info that is already erased. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 09:03:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 09:03:11 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.0f6909465375645e4de0e8f4b30b46ae@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > It is the latter that we are going to erase, NOT the former. Ah, thanks for the clarification; I must admit that I did not think it through with sufficient detail. I?ll give it a shot as outlined by you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 09:06:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 09:06:49 -0000 Subject: [GHC] #11777: RTS source code issues Message-ID: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> #11777: RTS source code issues -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tiago Silva writes: Last night I started looking at the C files used in GHC and noticed these issues: {{{ /driver/utils/cwrapper.c : int main(int, char **); }}} `void *p` is apparently unused, even if the compiler optimizes it away.. you should check if something went missing. {{{ /rts/RetainerProfile.c : static nat sanityCheckHeapClosure(StgClosure *) }}} `StgInfoTable *info` has the same issue as above {{{ /rts/RetainerSet.c #elif defined(RETAINER_SCHEME_CC) // Retainer scheme 3: retainer = cost centre void printRetainerSetShort(FILE *f, RetainerSet *rs, nat max_length) { char tmp[max_length + 1]; int size; nat j; } }}} Unlike the other functions around it, this function does nothing. Its variables are also not unused? {{{ /rts/sm/MarkWeak.c : void markWeakPtrList (void); if (w->header.info == &stg_DEAD_WEAK_info) { last_w = &(w->link); } else { last_w = &(w->link); } }}} Not sure what's going on here. Regardless of the test the two branches do the same thing. {{{ /rts/win32/IOManager.c : AddIORequest, AddDelayRequest, AddProcRequest functions }}} If `(!ioMan || !wItem)` the functions either return 0 or FALSE, but they don't free `wItem` before. Is this optimized by the compiler? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 09:07:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 09:07:49 -0000 Subject: [GHC] #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration In-Reply-To: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> References: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> Message-ID: <061.1443b7a95ce25172bcf2c597b2dac86a@haskell.org> #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2070 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 09:24:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 09:24:55 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.6fc0bb104bfaabff597f74e68f25e7b3@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Meanwhile, there is a separate issue in comment:20. It seems that for any un-saturated lambda, we nuke (a) the `occInfo` on the binders (fair enough; the next run of the occurrence analyser will regenerate it), and (b) the `demandInfo` on the binders. The reasoning is explained in comment:20. But (b) is permanent; it won't be re-generated until the next run of the demand analyser. And, worse, it applies to function definitions {{{ f = \xy . x+y }}} Here `x` and `y` will be marked as strictly demanded, but that info will get stripped after the first run of the simplifier. Try it on {{{ f :: [Int] -> [Int] -> Int f x y = head x + head y }}} After the demand analyser we have {{{ f = \ (x_amY [Dmd=] :: [Int]) (y_amZ [Dmd=] :: [Int]) -> ... }}} but after the first run of the simplifier we get {{{ f = \ (x_amY :: [Int]) (y_amZ :: [Int]) -> ... }}} (`f` itself still has a strictness signature that says it is strict in both args.) Does this matter? Well, the main reason is that if `f` is inlined, we'd like to get a strict `let`. And now we won't. Happily I think it is easily fixed. The key thing is that when doing beta-reduction, which effectively does `(\x.e) b` into `let x=b in e`, we must kill off x's demand/occurrence info if the lambda is not saturated. So, idea, in `Simplify.hs`: * Give an extra `Bool` to `simplLam` indictating "saturated". * Compute (value) saturation in the `simplExprF1 env expr@(Lam {}) cont`, before calling `simpLam`, but do no zapping. * In `simplLam`, in the beta-reduction case, {{{ simplLam env (bndr:bndrs) body (ApplyToVal { sc_arg = arg, sc_env = arg_se , sc_cont = cont }) = do { tick (BetaReduction bndr) ; simplNonRecE env' (zap_unfolding bndr) (arg, arg_se) (bndrs, body) cont } }}} do the binder-zapping right there, if "saturated" is not true. (That neatly puts it with the unfolding-zapping code.) Now the non-beta-reduced lambdas won't be zapped, which is right. Would you like to try that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 09:28:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 09:28:40 -0000 Subject: [GHC] #11778: Preserve demandInfo on lambda binders in the simpifier Message-ID: <046.5117a79f39656b69a41ce129289968cf@haskell.org> #11778: Preserve demandInfo on lambda binders in the simpifier -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In ticket:11731#comment:30, simonpj writes: > Meanwhile, there is a separate issue in ticket:11731#comment:20. It seems that for any un-saturated lambda, we nuke (a) the `occInfo` on the binders (fair enough; the next run of the occurrence analyser will regenerate it), and (b) the `demandInfo` on the binders. The reasoning is explained in comment:20. > > But (b) is permanent; it won't be re-generated until the next run of the demand analyser. And, worse, it applies to function definitions > {{{ > f = \xy . x+y > }}} > Here `x` and `y` will be marked as strictly demanded, but that info will get stripped after the first run of the simplifier. Try it on > {{{ > f :: [Int] -> [Int] -> Int > f x y = head x + head y > }}} > After the demand analyser we have > {{{ > f = \ (x_amY [Dmd=] :: [Int]) (y_amZ [Dmd=] :: [Int]) -> ... > }}} > but after the first run of the simplifier we get > {{{ > f = \ (x_amY :: [Int]) (y_amZ :: [Int]) -> ... > }}} > (`f` itself still has a strictness signature that says it is strict in both args.) > > Does this matter? Well, the main reason is that if `f` is inlined, we'd like to get a strict `let`. And now we won't. > > Happily I think it is easily fixed. The key thing is that when doing beta-reduction, which effectively does `(\x.e) b` into `let x=b in e`, we must kill off x's demand/occurrence info if the lambda is not saturated. > > So, idea, in `Simplify.hs`: > > * Give an extra `Bool` to `simplLam` indictating "saturated". > > * Compute (value) saturation in the `simplExprF1 env expr@(Lam {}) cont`, before calling `simpLam`, but do no zapping. > > * In `simplLam`, in the beta-reduction case, > {{{ > simplLam env (bndr:bndrs) body (ApplyToVal { sc_arg = arg, sc_env = arg_se > , sc_cont = cont }) > = do { tick (BetaReduction bndr) > ; simplNonRecE env' (zap_unfolding bndr) (arg, arg_se) (bndrs, body) cont } > }}} > do the binder-zapping right there, if "saturated" is not true. (That neatly puts it with the unfolding-zapping code.) > > Now the non-beta-reduced lambdas won't be zapped, which is right. > > Would you like to try that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 09:29:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 09:29:02 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.bb24685d69714961a47a39878bc3fa39@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I moved that separate issue to #11778, and will comment after lunch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 11:25:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 11:25:24 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.d5993b7ef1d6285b8080ba348cfe6fda@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Sounds like a plan. I am currently checking the effect of a very late, non-ww, demand analyzer. It does fix the bug here (both as observed in nofib, and the test case I produced here). The numbers for thunks are the same as with `-flate-dmd- anal`, though. I wonder: What else (besides the code-generator) uses the used-once information in a critical way? In particular, `isUsedOnce` is *only* mentioned in `CoreToStg`. Should we even bother removing the information then? Anyways, I implemented it (wip/T11731 for now). I did put the code into DmdAnal.hs, after all, that?s where it belongs, and added a boolean flag to `CoreDoStrictness`. A full validation is running. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 12:12:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 12:12:50 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.b5c7f4721c40cdee1794671230479fa1@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I wonder: What else (besides the code-generator) uses the used-once information in a critical way? In particular, `isUsedOnce` is *only* mentioned in `CoreToStg`. Should we even bother removing the information then? I think nothing. And that's why I said it's optional to erase it. It's just a little smelly to have info in the tree that is wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 12:15:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 12:15:07 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.e8b9d42c164e716774644f0523bc841d@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Crumbs. I see that you are doing an entire pass of the program to erase this info. That does seem like overkill, to remove info that is never examined anyway. I'd much rather not do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 14:40:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 14:40:49 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.16fb40fbbc5037ce8fa47f1102e1a264@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2073 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * differential: Phab:D2064 => Phab:D2073 Comment: > Crumbs. I see that you are doing an entire pass of the program to erase this info. That does seem like overkill, to remove info that is never examined anyway. I'd much rather not do this. Agreed, I reverted it; the final result (with Note) is now in Phab:D2073. I did look at the worker/wrapper module, but found that it would be quite ugly to do it there. For example, clear ?In this case do nothing? code paths would have to turn to ?In this case, do nothing (besides this change to all binders that we happen to do here).? One clear implementation would have been to adjust the calls to `setIdDemandInfo` in `DmdAnal`, but that would go wrong because of the Cunning Plan with fixed-point iteration, where later iterations use the existing annotations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 14:51:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 14:51:51 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.7ce0f6cc5030dba43c155f4cfa92ad34@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2073 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > One clear implementation would have been to adjust the calls to `setIdDemandInfo` in `DmdAnal`, but that would go wrong because of the Cunning Plan with fixed-point iteration, where later iterations use the existing annotations. Well imagine that the demand analyser simply NEVER attributed single-use to anything; e.g. `mkOnceUsedDmd` returned `Use Many ...`. Then we'd get no useful use-once info from the analyser so we wouldn't need to erase it. Not sure if it's worth it. There are other occurrence of the string `Use One` in `Demand`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 16:30:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 16:30:40 -0000 Subject: [GHC] #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration In-Reply-To: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> References: <046.967e6cf10d023cf3fe98f3cad192e65a@haskell.org> Message-ID: <061.0bfad1f47f82429fef7237d1580648eb@haskell.org> #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2070 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: I must have mis-validated this, so I did not notice noticeable performance regressions; reverted it in 6ea42c72dc924eddba3f2ee22fa4e514084fa5cc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 16:36:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 16:36:49 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.7322f334d92b00b764b2a1c3aba35aed@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2073 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): That would be a clean approach... but I?m worried that we?d get less useful information also for called-once, and thus needlessly cripple the analysis. Isn?t the information about single-use demand used internally to determine that certain functions are called once? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 16:39:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 16:39:58 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.568230e9079f24ccc41bd47d1e3a7a3c@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2073 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:37 nomeata]: > Isn?t the information about single-use demand used internally to determine that certain functions are called once? No, I don't think so. I'm 85% certain! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 16:41:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 16:41:25 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.bae7f76ab40df85d578085787616aabc@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2073 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Then I?ll give it a shot: I?ll re-add the `Bool` parameter to the demand analysis which indicates whether we want used-once-information, modify the calls to `mkOnceUsedDmd`, and just see what happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 16:44:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 16:44:10 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.ff7993cb54c1478f85356798e45d90af@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2073 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Trouble is that there ''are'' other places where `Use One` shows up in `Demand.hs`, and we'd need to look at all of them too. But I think this alone will kill off a lot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 17:17:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 17:17:42 -0000 Subject: [GHC] #11778: Preserve demandInfo on lambda binders in the simpifier In-Reply-To: <046.5117a79f39656b69a41ce129289968cf@haskell.org> References: <046.5117a79f39656b69a41ce129289968cf@haskell.org> Message-ID: <061.d91d0a3c0c6d7db08e8abb96ea833c9b@haskell.org> #11778: Preserve demandInfo on lambda binders in the simpifier -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Just to confirm my understanding: Looking at the code, it seems the same effect could be achieved with less code change by changing {{{ need_to_zap = any zappable_bndr (drop n_args bndrs) n_args = countArgs cont }}} to {{{ need_to_zap = n_args > 0 && any zappable_bndr (drop n_args bndrs) n_args = countArgs cont }}} because the problem only occurs if there is some, but not enough beta- reduction. In particular, when simplifying the definition, `n_args` will be zero. (I?m not saying that this is a better implementation. But maybe it is, as it is more local.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 18:31:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 18:31:30 -0000 Subject: [GHC] #11778: Preserve demandInfo on lambda binders in the simpifier In-Reply-To: <046.5117a79f39656b69a41ce129289968cf@haskell.org> References: <046.5117a79f39656b69a41ce129289968cf@haskell.org> Message-ID: <061.f441a28ad95dea80ef8478aa4c376cdf@haskell.org> #11778: Preserve demandInfo on lambda binders in the simpifier -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes but it seem weirdly ad-hoc to zap if (a) the function is not saturated, but (b) it is applied to at least one argument. The approach I describe doesn't have this odd bump, AND it doesn't zap the binders on lambdas that aren't beta-reduced. So I prefer the suggestion I made. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 20:32:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 20:32:12 -0000 Subject: [GHC] #10436: Excessive numbers of packages loaded for TH In-Reply-To: <045.b8bbf0247835752ace9434694fd31689@haskell.org> References: <045.b8bbf0247835752ace9434694fd31689@haskell.org> Message-ID: <060.c9a7dfac22120b9a0b1571f264291283@haskell.org> #10436: Excessive numbers of packages loaded for TH -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #2437 | Differential Rev(s): Phab:D973 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D973 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 20:32:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 20:32:47 -0000 Subject: [GHC] #10436: Excessive numbers of packages loaded for TH In-Reply-To: <045.b8bbf0247835752ace9434694fd31689@haskell.org> References: <045.b8bbf0247835752ace9434694fd31689@haskell.org> Message-ID: <060.2193fa7b1940ecdfbcbb4c9dcbc447f8@haskell.org> #10436: Excessive numbers of packages loaded for TH -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #2437 | Differential Rev(s): Phab:D973 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): This is closely related to #2437 but this is a more accurate description of a different (but related) problem, so I'm going to keep this open. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 31 21:24:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Mar 2016 21:24:04 -0000 Subject: [GHC] #11779: Merge "Skip TEST=TcCoercibleFail when compiler_debugged" Message-ID: <046.dc5ce26ca4c4467286d60cdc7155ea47@haskell.org> #11779: Merge "Skip TEST=TcCoercibleFail when compiler_debugged" -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, please merge 49c55e68aae9841c166430ae566b0d9bdc03c99d into ghc-8.0, to keep the test suite (and travis) useful. Thanks, Joachim -- Ticket URL: GHC The Glasgow Haskell Compiler