From ghc-devs at haskell.org Mon Jun 1 03:47:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 03:47:35 -0000 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> References: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> Message-ID: <075.73a8687c91ed8482d846e71fa7d6ee27@haskell.org> #3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: msosn MartijnVanSteenbergen | Status: new Type: feature request | Milestone: 7.12.1 Priority: low | Version: 6.10.4 Component: Compiler (Type | Keywords: newcomer checker) | Architecture: Resolution: | Unknown/Multiple Operating System: Unknown/Multiple | Test Case: Type of failure: None/Unknown | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by msosn): * owner: => msosn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 06:38:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 06:38:04 -0000 Subject: [GHC] #10101: ghci :e throws exception after type error In-Reply-To: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> References: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> Message-ID: <062.9e9426e2474cd738871fb28881fdfd27@haskell.org> #10101: ghci :e throws exception after type error -------------------------------------+------------------------------------- Reporter: diatchki | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D930 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 06:47:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 06:47:35 -0000 Subject: [GHC] #10442: Loading of shared libraries is problematic in ghc 7.10.1 In-Reply-To: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> References: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> Message-ID: <068.a61a02e86b299cca4fc9f44f57d941aa@haskell.org> #10442: Loading of shared libraries is problematic in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by artella.coding): * cc: thoughtpolice (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 06:50:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 06:50:20 -0000 Subject: [GHC] #10442: Loading of shared libraries is problematic in ghc 7.10.1 In-Reply-To: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> References: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> Message-ID: <068.11bca30708efce3cdd2f662c6f3aa21a@haskell.org> #10442: Loading of shared libraries is problematic in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by artella.coding): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 07:07:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 07:07:29 -0000 Subject: [GHC] #10126: Test framework should not assume that GHC tools are in the same directory as GHC itself In-Reply-To: <049.61f3d3a5528377e9b91a5702a2f7acf2@haskell.org> References: <049.61f3d3a5528377e9b91a5702a2f7acf2@haskell.org> Message-ID: <064.b53c1d8a921bd3cfa2e1d5a8219e2108@haskell.org> #10126: Test framework should not assume that GHC tools are in the same directory as GHC itself -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.2 Component: Test Suite | Version: 7.8.4 Resolution: fixed | Keywords: test Operating System: Unknown/Multiple | framework makefile Type of failure: Other | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D705 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 07:15:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 07:15:35 -0000 Subject: [GHC] #10101: ghci :e throws exception after type error In-Reply-To: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> References: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> Message-ID: <062.903ce2f7c291bdf31707cf90ce842702@haskell.org> #10101: ghci :e throws exception after type error -------------------------------------+------------------------------------- Reporter: diatchki | Owner: archblob Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D930 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 07:15:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 07:15:37 -0000 Subject: [GHC] #10101: ghci :e throws exception after type error In-Reply-To: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> References: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> Message-ID: <062.8db30f08ba8661cc8f1eb1aa8df3eaac@haskell.org> #10101: ghci :e throws exception after type error -------------------------------------+------------------------------------- Reporter: diatchki | Owner: archblob Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D930 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"4756438962a76d2dcedf63b90ec789cb054f9556/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4756438962a76d2dcedf63b90ec789cb054f9556" Catch canonicalizePath exceptions, fix #10101 Summary: Introduce by #95 'canonicalizePath' throws and exception when given an invalid file in a call to 'sameFile'. There are two cases when this can happen when using ghci: 1) If there is an error at the interactive prompt, "" file is searched for and not found. 2) If there is an error in any loaded file and editing an inexistent/new file with 'e: foo'. Both cases are now tested. Test Plan: validate Reviewers: austin, #ghc Reviewed By: austin, #ghc Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D930 GHC Trac Issues: #10101 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 07:15:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 07:15:37 -0000 Subject: [GHC] #95: GHCi :edit command should jump to the the last error In-Reply-To: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> References: <052.52d2f4855a60cbba938e5d2b851635de@haskell.org> Message-ID: <067.e60cf2ff16965a4855549cae7a127f05@haskell.org> #95: GHCi :edit command should jump to the the last error -------------------------------------+--------------------------------- Reporter: martijnislief | Owner: lortabac Type: feature request | Status: closed Priority: normal | Milestone: ? Component: GHCi | Version: None Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by Austin Seipp ): In [changeset:"4756438962a76d2dcedf63b90ec789cb054f9556/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4756438962a76d2dcedf63b90ec789cb054f9556" Catch canonicalizePath exceptions, fix #10101 Summary: Introduce by #95 'canonicalizePath' throws and exception when given an invalid file in a call to 'sameFile'. There are two cases when this can happen when using ghci: 1) If there is an error at the interactive prompt, "" file is searched for and not found. 2) If there is an error in any loaded file and editing an inexistent/new file with 'e: foo'. Both cases are now tested. Test Plan: validate Reviewers: austin, #ghc Reviewed By: austin, #ghc Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D930 GHC Trac Issues: #10101 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 07:24:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 07:24:37 -0000 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images In-Reply-To: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> References: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> Message-ID: <059.978e349f5fb2731471ec56b3992a14cf@haskell.org> #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): This was apparently changed (on purpose) by b30c6012c7552c874281050d40e5a59012b2c5e7, but I'm not sure why. I'll try to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 08:29:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 08:29:02 -0000 Subject: [GHC] #7521: Simplifier ticks exhausted when compiling Accelerate example. In-Reply-To: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> References: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> Message-ID: <061.1fdb5c44ae06fb44432b464ccf8ae69f@haskell.org> #7521: Simplifier ticks exhausted when compiling Accelerate example. -------------------------------------+------------------------------------- Reporter: eamsden | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: chak (added) Comment: I'm not sure what you mean, George. As I understand comment:8 everything is just fine so long as you don't meddle with the `.cabal` file. Or is there an actual problem. Manuel? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 08:42:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 08:42:39 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.b645cbea6efc5ad67f9e75e6a29c72a8@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D852 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a52f1444ea4045a2075dc88bb973a9289ee7e2cf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a52f1444ea4045a2075dc88bb973a9289ee7e2cf" In ghci linker, link against all previous temp sos (#10322) The OS X dlopen() appears to only resolve undefined symbols in the direct dependencies of the shared library it is loading. Reviewed By: trommler, austin Differential Revision: https://phabricator.haskell.org/D852 GHC Trac Issues: #10322 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 09:06:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 09:06:38 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.0265d88a1b64e05d82746b22e104d3a5@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): This is interesting, but I lack the bandwidth to follow it in detail. I urge against a design that requires the programmer to predict the behaviour of the constraint solver in order to decide what code the "deriving" will generate. I think it's be much better to say that it depends on the syntactic form of the declaration. So for `MkT1` and `MkT3` you'd get the first argument included in the fold, but for `MkT2` you would not. You need to think what to do about cases like this: {{{ data S a where MKS :: b -> c -> S (b,c) }}} Perhaps y'all can work out a design, document it on a wiki page, and even implement it. (I can advise.) I'd really love the same page to document the behaviour of deriving for `Functor` and `Traversable` too! Many thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 09:20:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 09:20:30 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.428c32d515ae0c3e33440f9f7a3fe14b@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D924 -------------------------------------+------------------------------------- Comment (by simonpj): Well someone should preferably just check that whatever fusion used to happen still happens, and ideally add a performance test to make sure it stays that way. That done, go ahead if the Core Libraries Committee is happy. (And Edward is presumably speaking as its chair in comment:4.) I'm unconvinced it's worth merging to 7.10. After all, it changes nothing except omitting one line of code from a library, right? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 09:22:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 09:22:53 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.c2e044dedb42a1d8fd27882aeb302846@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D852 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 09:35:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 09:35:41 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.f6193947a831249548a138fffb123406@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #1241, #2247, | Blocking: #8356, #9103, #9227 | Differential Revisions: Phab:D69 -------------------------------------+------------------------------------- Comment (by simonpj): It looks stalled to me. Wojciech was going to work on some aspects (notably making the pragma work per-instance rather than globally) but nothing has happened. I'm happy to advise anyone who wants to take up the cudgels here. It's not too hard, despite this very long thread. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 09:51:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 09:51:20 -0000 Subject: [GHC] #10452: ApiAnnotations : rationalise tests In-Reply-To: <044.92365aad7d7f8e3dca664006b00e42b6@haskell.org> References: <044.92365aad7d7f8e3dca664006b00e42b6@haskell.org> Message-ID: <059.3f04667a8fc9e723810cc1275297bf7f@haskell.org> #10452: ApiAnnotations : rationalise tests -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"e00910b0f83eaafd91dcb59cec0779b3ea9f0d30/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e00910b0f83eaafd91dcb59cec0779b3ea9f0d30" ApiAnnotations : rationalise tests Summary: At the moment the API Annotations tests have a driver that has been copy/pasted multiple times. Compile it once, and run it for each test case. Test Plan: ./validate Reviewers: hvr, austin Reviewed By: austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D913 GHC Trac Issues: #10452 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 10:05:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 10:05:34 -0000 Subject: [GHC] #10470: Allocating StablePtrs leads to GC slowdown even after they're freed Message-ID: <046.30cfca5d1594218e8487b9ef0746ec54@haskell.org> #10470: Allocating StablePtrs leads to GC slowdown even after they're freed -------------------------------------+------------------------------------- Reporter: bitonic | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If we allocate and then free a lot of StablePtrs the GC performance will be degrated for the rest of the execution. I have attached a program that performs a GC-heavy task (foldr'ing a long list of Ints) before and after allocating and then freeing a million StablePtrs. After the StablePtrs are freed the task takes more than twice as long. The reason for this is that {{stable_ptr_table}} in {{Stable.c}} is never resized, and is looped over for every GC pause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 10:55:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 10:55:26 -0000 Subject: [GHC] #70: Read for Arrays does not work In-Reply-To: <045.87ed54c22c2a5d8161b869085e6f45cb@haskell.org> References: <045.87ed54c22c2a5d8161b869085e6f45cb@haskell.org> Message-ID: <060.0cbbb4ddea6649f76e2d0042ad083d0a@haskell.org> #70: Read for Arrays does not work --------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: hslibs/lang | Version: 5.02 Resolution: Fixed | Keywords: --------------------------+-------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"7dd0ea7428379df848e3d13528921b39b7bf5b95/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7dd0ea7428379df848e3d13528921b39b7bf5b95" Update binary submodule to 0.7.5.0 release Quoting the changelog, this pulls in the following fixes: binary-0.7.5.0 -------------- - Fix performance bug that was noticable when you get a big strict ByteString and the input to the decoder consists of many small chunks. - https://github.com/kolmodin/binary/issues/73 - https://github.com/kolmodin/binary/pull/76 - Fix memory leak when decoding Double and Float. - Commit 497a181c083fa9faf7fa3aa64d1d8deb9ac76ecb - We now require QuickCheck >= 2.8. Remove our version of arbitrarySizedNatural. binary-0.7.4.0 -------------- - Some invalid UTF-8 strings caused an exception when decoded. Those errors will now now fail in the Get monad instead. See issue 70. Patch contributed by @ttuegel. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 11:32:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 11:32:28 -0000 Subject: [GHC] #7521: Simplifier ticks exhausted when compiling Accelerate example. In-Reply-To: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> References: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> Message-ID: <061.6930e7b47f61bfbbe6b35eb9d4b7cf5a@haskell.org> #7521: Simplifier ticks exhausted when compiling Accelerate example. -------------------------------------+------------------------------------- Reporter: eamsden | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): Right, there is no actual problem along as you don't meddle with the Accelerate .cabal file but the subject/title of this ticket: ""Simplifier ticks exhausted when compiling Accelerate example" suggests there is. I guess a new subject would be something like "Accelerate examples does not compile with default value of -fsimpl-tick-factor" Once we have that title it isn't clear that the priority of this bug should be high, normal or low seems more appropriate to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 11:41:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 11:41:04 -0000 Subject: [GHC] #10460: Allow foreign prim to return Any In-Reply-To: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> References: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> Message-ID: <060.06c8fb94399759480270e056ec8531af@haskell.org> #10460: Allow foreign prim to return Any -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Generally ok but * The ability to pass `Any` to `foreign import prim` is not documented in [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi.html #ffi-prim 8.1.3 of the user manual], and it jolly well should be. If you want to extend this to arbitrary FFI imports then we should document that too. * Who converts the argument to `Any`? The caller? With `unsafeCoerce`? * You should never combine a '''safe''' foreign import with `Any`. "Safe" means that the call may block and GC may happen, so passing a pointer into the heap is a bad idea. (And this constraint should be documented.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 12:16:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 12:16:35 -0000 Subject: [GHC] #10313: ApiAnnotations : strings in warnings do not return SourceText In-Reply-To: <044.808d3812fac81928344a0fd1bb2faa89@haskell.org> References: <044.808d3812fac81928344a0fd1bb2faa89@haskell.org> Message-ID: <059.8c86dea570a8a8a0d2addc8e9c33c1f3@haskell.org> #10313: ApiAnnotations : strings in warnings do not return SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D907 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"e6191d1cc37e98785af8b309100ea840084fa3ba/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e6191d1cc37e98785af8b309100ea840084fa3ba" ApiAnnotations : strings in warnings do not return SourceText Summary: The strings used in a WARNING pragma are captured via strings :: { Located ([AddAnn],[Located FastString]) } : STRING { sL1 $1 ([],[L (gl $1) (getSTRING $1)]) } .. The STRING token has a method getSTRINGs that returns the original source text for a string. A warning of the form {-# WARNING Logic , mkSolver , mkSimpleSolver , mkSolverForLogic , solverSetParams , solverPush , solverPop , solverReset , solverGetNumScopes , solverAssertCnstr , solverAssertAndTrack , solverCheck , solverCheckAndGetModel , solverGetReasonUnknown "New Z3 API support is still incomplete and fragile: \ \you may experience segmentation faults!" #-} returns the concatenated warning string rather than the original source. This patch now deals with all remaining instances of getSTRING to bring in a SourceText for each. This updates the haddock submodule as well, for the AST change. Test Plan: ./validate Reviewers: hvr, austin, goldfire Reviewed By: austin Subscribers: bgamari, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D907 GHC Trac Issues: #10313 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 13:05:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 13:05:05 -0000 Subject: [GHC] #10471: Confusing parse error when forgetting "deriving" Message-ID: <056.982b2e32ded2af2b7b3154c77dfdc00e@haskell.org> #10471: Confusing parse error when forgetting "deriving" -------------------------------------+------------------------------------- Reporter: | Owner: AlexanderThiemann | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: | warning at compile-time Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This code: {{{ module Main where data Foo = Foo { f_x :: Int , f_y :: Int } (Eq, Show) }}} Produces this error message: {{{ foo.hs:5:7: Not in scope: `f_x' foo.hs:6:7: Not in scope: `f_y' }}} I'm not sure how easy it is to improve the error message; but a "Not in scope" seems very confusing to me... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 13:55:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 13:55:46 -0000 Subject: [GHC] #10236: DWARF unwind info is broken In-Reply-To: <052.423eb6b33b554d26dbce2d20e8e80a98@haskell.org> References: <052.423eb6b33b554d26dbce2d20e8e80a98@haskell.org> Message-ID: <067.31775ec947b81ad7ac54872fe714d4f6@haskell.org> #10236: DWARF unwind info is broken -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Debugging) | Keywords: dwarf Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Phab:D792 Related Tickets: | -------------------------------------+------------------------------------- Comment (by scpmw): See D792 - it's slightly tricky, because the only meaningful test would involve taking the produced object file apart. Best approach in my opinion would be to do some sanity checks on `objdump`/`dwarfdump` output. Still not exactly trivial to formulate a robust "all Haskell code covered" test. Maybe calculate `.text` section size and compare it with the sum of ranges from `.debug_info`? Side note: If/when we equip the RTS to consume DWARF this could become a lot more straightforward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 14:28:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 14:28:38 -0000 Subject: [GHC] #7521: Accelerate examples does not compile with default value of -fsimpl-tick-factor (was: Simplifier ticks exhausted when compiling Accelerate example.) In-Reply-To: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> References: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> Message-ID: <061.01dc6ada40c0f954e58475cb6162330c@haskell.org> #7521: Accelerate examples does not compile with default value of -fsimpl-tick- factor -------------------------------------+------------------------------------- Reporter: eamsden | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): See also #8613, #9070, #8319, #10459 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 14:58:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 14:58:54 -0000 Subject: [GHC] #10317: Event manager: Multishot registrations only fire once In-Reply-To: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> References: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> Message-ID: <061.6e0172c35cd1aaaf90633d2c8165787c@haskell.org> #10317: Event manager: Multishot registrations only fire once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D849 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"1c3832597b3e75456fc61628c4cd289d211c733b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1c3832597b3e75456fc61628c4cd289d211c733b" Fix dropped event registrations D347 introduced a bug wherein the event manager would drop registrations that should be retained during processing. This occurs when an fd has multiple registrations, not all of which fire, as well as the case of multi-shot registrations. I also do some general house-keeping, try to better document things, and fix a bug which could result in unnecessary calls to `epoll_ctl` Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D849 GHC Trac Issues: #10317 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 14:59:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 14:59:50 -0000 Subject: [GHC] #10317: Event manager: Multishot registrations only fire once In-Reply-To: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> References: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> Message-ID: <061.113e1f7449598868eafd422e3ec0e985@haskell.org> #10317: Event manager: Multishot registrations only fire once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D849 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 15:03:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 15:03:26 -0000 Subject: [GHC] #10317: Event manager: Multishot registrations only fire once In-Reply-To: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> References: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> Message-ID: <061.47b2b8df3fbc89414a97ab70121f2ea3@haskell.org> #10317: Event manager: Multishot registrations only fire once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D849 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 15:04:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 15:04:41 -0000 Subject: [GHC] #10101: ghci :e throws exception after type error In-Reply-To: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> References: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> Message-ID: <062.e81cb99f719793b4f4b080630f04b55c@haskell.org> #10101: ghci :e throws exception after type error -------------------------------------+------------------------------------- Reporter: diatchki | Owner: archblob Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D930 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 15:18:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 15:18:18 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.7b45ebff4f26cbeb6816503231c62629@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D852 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 15:20:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 15:20:30 -0000 Subject: [GHC] #8613: simplifier ticks exhausted In-Reply-To: <044.3c96d4abc261f1969033a0de42af80e6@haskell.org> References: <044.3c96d4abc261f1969033a0de42af80e6@haskell.org> Message-ID: <059.33f7a25f93d907f0cb69eff885b37cea@haskell.org> #8613: simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): we need the 7.10.1 or later version of RedBlackStencilOpt.hs? as the one attached here doesn't compile under 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 15:27:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 15:27:17 -0000 Subject: [GHC] #10196: Regression regarding Unicode subscript characters in identifiers In-Reply-To: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> References: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> Message-ID: <060.ea6e8efc3877c488321a3402147fcfec@haskell.org> #10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Compiler | Milestone: 7.10.2 (Parser) | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #5108 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: hvr => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 15:35:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 15:35:58 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.5f0ce5b1a4b589e2ff8def395d79c849@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch * milestone: 7.12.1 => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 15:36:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 15:36:07 -0000 Subject: [GHC] #10470: Allocating StablePtrs leads to GC slowdown even after they're freed In-Reply-To: <046.30cfca5d1594218e8487b9ef0746ec54@haskell.org> References: <046.30cfca5d1594218e8487b9ef0746ec54@haskell.org> Message-ID: <061.e583998b592e3e1cfb2438d1b084aa56@haskell.org> #10470: Allocating StablePtrs leads to GC slowdown even after they're freed -------------------------------------+------------------------------------- Reporter: bitonic | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bitonic: Old description: > If we allocate and then free a lot of StablePtrs the GC performance will > be degrated for the rest of the execution. > > I have attached a program that performs a GC-heavy task (foldr'ing a long > list of Ints) before and after allocating and then freeing a million > StablePtrs. After the StablePtrs are freed the task takes more than > twice as long. > > The reason for this is that {{stable_ptr_table}} in {{Stable.c}} is never > resized, and is looped over for every GC pause. New description: If we allocate and then free a lot of StablePtrs the GC performance will be degrated for the rest of the execution. I have attached a program that performs a GC-heavy task (foldr'ing a long list of Ints) before and after allocating and then freeing a million StablePtrs. After the StablePtrs are freed the task takes more than twice as long. The reason for this is that `stable_ptr_table` in `Stable.c` is never resized, and is looped over for every GC pause. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 15:36:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 15:36:43 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.fd64b19b30cbc090b67bfb2a88f5ee29@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): To be clear: I'm marking this as patch to make sure Phab:D910 is not lost and properly merged to 7.10. (It'll be remilestoned afterwords). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 16:46:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 16:46:12 -0000 Subject: [GHC] #10460: Allow foreign prim to return Any In-Reply-To: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> References: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> Message-ID: <060.b7b376a204dfdafdef5ac6b101be5f43@haskell.org> #10460: Allow foreign prim to return Any -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"98b0b2e41f2bdc66bf815ff5f3825832b2b6d34d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="98b0b2e41f2bdc66bf815ff5f3825832b2b6d34d" Add information about allowed foreign prim args, see #10460. Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 16:56:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 16:56:15 -0000 Subject: [GHC] #10460: Allow foreign prim to return Any In-Reply-To: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> References: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> Message-ID: <060.6ebc8eb0665c94d4c07d2e5c85dd0314@haskell.org> #10460: Allow foreign prim to return Any -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Sorry I think I was mixed up. A `foreign prim` is always `unsafe`, isn't it. And you are only proposing to add `Any` as a possible result for `foreign prim` not for other `foreign` declarations, correct? So my third bullet is irrelevant. There's a missing close-paren in the (welcome) doc fix. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 17:06:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 17:06:16 -0000 Subject: [GHC] #10460: Allow foreign prim to return Any In-Reply-To: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> References: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> Message-ID: <060.779956506a16f5db51a6b36ef65e988f@haskell.org> #10460: Allow foreign prim to return Any -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by ezyang): > And you are only proposing to add Any as a possible result for foreign prim not for other foreign declarations, correct? Yep. > Who converts the argument to Any? The caller? With unsafeCoerce? Yes and yes. Another possibility is to accept arbitrary types for foreign prim ops (in the same way that GHC's primop mechanism works), but that's more work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 17:06:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 17:06:33 -0000 Subject: [GHC] #10460: Allow foreign prim to return Any In-Reply-To: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> References: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> Message-ID: <060.533966ed87679d56aa461d93aab8f64c@haskell.org> #10460: Allow foreign prim to return Any -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"e5be846ba929da54472c03a7c3b05fdd1e483c01/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e5be846ba929da54472c03a7c3b05fdd1e483c01" Typofix: missing period. (#10460) Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 17:20:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 17:20:37 -0000 Subject: [GHC] #10470: Allocating StablePtrs leads to GC slowdown even after they're freed In-Reply-To: <046.30cfca5d1594218e8487b9ef0746ec54@haskell.org> References: <046.30cfca5d1594218e8487b9ef0746ec54@haskell.org> Message-ID: <061.2543125ecbd0fa72be0d25da084d90f2@haskell.org> #10470: Allocating StablePtrs leads to GC slowdown even after they're freed -------------------------------------+------------------------------------- Reporter: bitonic | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): We can't fix this by trying to resize `stable_ptr_table`, however, because if we have a used stable pointer at location 0 and a used stable pointer at location n, we can't resize smaller than n. (We might be able to if we used a hash table, but that would hurt read performance.) So really we need to be more clever about how we traverse the static pointer table, maybe by linking live entries together or something more clever. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 17:57:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 17:57:33 -0000 Subject: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module In-Reply-To: <046.ebf20f155e05760df4b4c62188044473@haskell.org> References: <046.ebf20f155e05760df4b4c62188044473@haskell.org> Message-ID: <061.8fcaa1a64c824168f720908d6c520bf3@haskell.org> #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: valid program | Blocking: 10336 Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"a27fb46ff1ea46a45e0084c3db92a24475e3bab5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a27fb46ff1ea46a45e0084c3db92a24475e3bab5" Add (failing) test case for #7672. Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 17:58:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 17:58:53 -0000 Subject: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module In-Reply-To: <046.ebf20f155e05760df4b4c62188044473@haskell.org> References: <046.ebf20f155e05760df4b4c62188044473@haskell.org> Message-ID: <061.88bc0c3a59f46d489950f67c520f033f@haskell.org> #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: T7672 valid program | Blocking: 10336 Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by ezyang): * testcase: => T7672 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 18:23:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 18:23:48 -0000 Subject: [GHC] #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) In-Reply-To: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> References: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> Message-ID: <061.50087469e59f8231ae36bac976c15d8c@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) -------------------------------------+------------------------------------- Reporter: rleslie | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #1042 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by meteficha): * cc: felipe.lessa@?, core-libraries-committee@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 18:57:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 18:57:20 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.bd4fd6f109eb84e32bb12b536a054368@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dolio): Yeah, I'm not a big fan (at the moment) of having equality constraints and the like pick up fields that aren't syntactically identical. For instance: {{{ data Foo b a where MkFoo :: (T b ~ a) => a -> b -> Int -> Foo b a deriving Foldable }}} Now if `T b` reduces to `Int`, we fold over the first ''and'' third argument, but if it doesn't, we only fold over the first (because we can't do anything else)? I could probably agree with having it succeed and always fold over the first field, because it's syntactically an `a`. But I feel like that should be the default behavior, not trying to deduce things from the constraints. Also consider: {{{ class (b ~ Int) => Foo a b where ... class Foo a b => Bar a b where ... data Quux a b where MkQ :: Bar a b => Int -> a -> b -> Quux a b }}} Does this pick up the `Int` because if we trace back from `Bar a b` we get `b ~ Int`? What about more complicated examples? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 19:14:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 19:14:49 -0000 Subject: [GHC] #10470: Allocating StablePtrs leads to GC slowdown even after they're freed In-Reply-To: <046.30cfca5d1594218e8487b9ef0746ec54@haskell.org> References: <046.30cfca5d1594218e8487b9ef0746ec54@haskell.org> Message-ID: <061.ab87825d51df2bec90a2acd1d447950e@haskell.org> #10470: Allocating StablePtrs leads to GC slowdown even after they're freed -------------------------------------+------------------------------------- Reporter: bitonic | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bitonic): Yeah, I used "resize" in a fairly liberal way :). One quick improvement would be to at least free empty tails, which wouldn't require any trick to maintain the existing indexes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 19:39:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 19:39:58 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.748c2c071c7f6c330bb0689d21a82def@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D924 -------------------------------------+------------------------------------- Comment (by simonmar): Hmmm, so this is only a transparent change for Monads that have `<*> = ap`. Arguably since it is possible to write legal (though unconventional) Haskell that behaves differently, and it's not a bug fix, it should not go into 7.10.2. (arguing against my own best interests, because it being in 7.10.2 would be helpful for me, but I've been working around it for a while so I can continue to do so) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 20:00:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 20:00:46 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.8652545c1c301b69e01c427495497fd5@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D924 -------------------------------------+------------------------------------- Comment (by dolio): I'm not really attached to this, so if simonmar is okay with postponing to 7.12, it's fine with me. Anyone who uses `Monad`s with `(<*>) /= ap` (at least, in ways giving distinct answers) is going to have a bad time, though. The specification of `Monad` now says they need to be equivalent, and I think that gives library writers license to switch between them without making a major version change. And it's only going to get worse. When ApplicativeDo gets implemented, using that extension will silently switch between these things. For instance, if ApplicativeDo were on in the file with the custom `mapM`, it would already be the same as `traverse`, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 20:04:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 20:04:40 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.f1031373dc5bbb6daf714a1f0604704d@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D924 -------------------------------------+------------------------------------- Comment (by simonpj): I'm a bit lost. The only change seems to be this: {{{ instance Traversable [] where instance Traversable [] where traverse f = List.foldr cons_f (pure []) where cons_f x ys = (:) <$> f x <*> ys mapM = Monad.mapM -- <========= DELETE THIS LINE }}} That means using the default method, `traverse`, rather than `mapM`. Why is that a big deal? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 20:09:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 20:09:07 -0000 Subject: [GHC] #7170: Foreign.Concurrent finalizer called twice in some cases In-Reply-To: <048.7b99ed8be2aa8efa30d578d90781f5ff@haskell.org> References: <048.7b99ed8be2aa8efa30d578d90781f5ff@haskell.org> Message-ID: <063.8ca5844596885adbc74adca47971b73f@haskell.org> #7170: Foreign.Concurrent finalizer called twice in some cases -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 7.6.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | ffi/should_run/7170 | Blocking: | Differential Revisions: D921 -------------------------------------+------------------------------------- Changes (by niteria): * status: new => patch * differential: => D921 Comment: This turned out to be a race condition that happened when a finalizer of a last generation was called manually and no major gc before shutdown. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 20:23:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 20:23:55 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.6d4e49726131feaa3115cf341c06c035@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D924 -------------------------------------+------------------------------------- Comment (by dolio): If I understand correctly, simonmar has a `Monad` whose `Applicative` instance does batching of remote calls, because you can do that when you use `(<*>)` but not `(>>=)`. So: {{{ f <*> x }}} does one round trip to the server, while: {{{ f >>= \g -> x >>= \y -> return (g y) }}} does two. The custom `mapM` does n trips, where n is the length of the list, while `traverse` does one, because the latter is implemented using: {{{ cons_f x ys = (:) <$> f x <*> ys }}} whereas the custom one is: {{{ cons_f x ys = do { z <- f x ; zs <- ys ; return (z:zs) } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 20:26:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 20:26:02 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.0e8754f164270deebb56df7ee8dab640@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D924 -------------------------------------+------------------------------------- Comment (by simonmar): @simonpj You could in principle write an `Applicative` or `Monad` instance that would distinguish between `mapM` and `traverse`, although it wouldn't be a good idea. But strictly speaking this is therefore a semantic change. In my case it makes a (huge) difference to performance, because `traverse` is parallel for the Haxl monad, where as `mapM` is serial. There's no difference in semantics, provided you don't dig into the monad implementation and only use the external interface, and provided some other conditions are met. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 20:28:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 20:28:49 -0000 Subject: [GHC] #10313: ApiAnnotations : strings in warnings do not return SourceText In-Reply-To: <044.808d3812fac81928344a0fd1bb2faa89@haskell.org> References: <044.808d3812fac81928344a0fd1bb2faa89@haskell.org> Message-ID: <059.eaf64bddb001905b6090eabe3357662f@haskell.org> #10313: ApiAnnotations : strings in warnings do not return SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D907 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: 7.10.2 => 7.12.1 Comment: This one won't be part of `ghc-7.10`, in order to keep API clients happy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 20:33:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 20:33:58 -0000 Subject: [GHC] #7170: Foreign.Concurrent finalizer called twice in some cases In-Reply-To: <048.7b99ed8be2aa8efa30d578d90781f5ff@haskell.org> References: <048.7b99ed8be2aa8efa30d578d90781f5ff@haskell.org> Message-ID: <063.71713f8170af3fd34624823a22257634@haskell.org> #7170: Foreign.Concurrent finalizer called twice in some cases -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 7.6.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | ffi/should_run/7170 | Blocking: | Differential Revisions: D921 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"dfdc50d666498c5a1118557d67209fe067c61cc1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dfdc50d666498c5a1118557d67209fe067c61cc1" Don't call DEAD_WEAK finalizer again on shutdown (#7170) Summary: There's a race condition like this: # A foreign pointer gets promoted to the last generation # It has its finalizer called manually # We start shutting down the runtime in `hs_exit_` from the main thread # A minor GC starts running (`scheduleDoGC`) on one of the threads # The minor GC notices that we're in `SCHED_INTERRUPTING` state and advances to `SCHED_SHUTTING_DOWN` # The main thread tries to do major GC (with `scheduleDoGC`), but it exits early because we're in `SCHED_SHUTTING_DOWN` state # We end up with a `DEAD_WEAK` left on the list of weak pointers of the last generation, because it relied on major GC removing it from that list This change: * Ignores DEAD_WEAK finalizers when shutting down * Makes the major GC on shutdown more likely * Fixes a bogus assert Test Plan: before this diff https://ghc.haskell.org/trac/ghc/ticket/7170#comment:5 reproduced and after it doesn't Reviewers: ezyang, austin, simonmar Reviewed By: simonmar Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D921 GHC Trac Issues: #7170 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 21:49:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 21:49:10 -0000 Subject: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module In-Reply-To: <046.ebf20f155e05760df4b4c62188044473@haskell.org> References: <046.ebf20f155e05760df4b4c62188044473@haskell.org> Message-ID: <061.9b4c0d72560e9c1ee6f1cd77258d4be5@haskell.org> #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: T7672 valid program | Blocking: 10336 Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Edward: I have a fix for this in-flight. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 21:52:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 21:52:39 -0000 Subject: [GHC] #10472: SigOf tests fail following renamer tidy-up Message-ID: <046.570456994550cf3c5b76ea8401f51edf@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 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm about to commit a patch that fixes #7672. Sadly, though, it causes these failures {{{ driver/sigof02 sigof02dmt [bad stderr] (normal) driver/sigof02 sigof02dt [bad stderr] (normal) driver/sigof02 sigof02mt [bad exit code] (normal) driver/sigof02 sigof02t [bad exit code] (normal) }}} with errors like {{{ Main.hs:8:13: error: Can't find interface-file declaration for variable empty 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 second argument of ?($)?, namely ?empty? In the expression: insert 0 "foo" . delete 1 . insert 1 undefined . insert (6 :: Int) "foo" $ empty In an equation for ?x?: x = insert 0 "foo" . delete 1 . insert 1 undefined . insert (6 :: Int) "foo" $ empty Main.hs:10:12: error: Can't find interface-file declaration for variable toList 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 first argument of ?print?, namely ?(toList x)? In a stmt of a 'do' block: print (toList x) In the expression: do { let x = insert 0 "foo" . delete 1 . insert 1 undefined . insert (6 :: Int) "foo" $ empty; print (member 1 x); print (toList x); print x } }}} Clearly there is only one bug here, and it's in the signature-handling code, which I do not fully understand. Happily, it's Edward's territory, and he is also involved in #7672. So I plan to mark these tests as broken on this ticket, and hope that Edward can adapt the signature stuff (which in any case is in-flight) to the new code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 22:28:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 22:28:37 -0000 Subject: [GHC] #10471: Confusing parse error when forgetting "deriving" In-Reply-To: <056.982b2e32ded2af2b7b3154c77dfdc00e@haskell.org> References: <056.982b2e32ded2af2b7b3154c77dfdc00e@haskell.org> Message-ID: <071.4c715110559813f0df56fc13add38e3c@haskell.org> #10471: Confusing parse error when forgetting "deriving" -------------------------------------+------------------------------------- Reporter: | Owner: AlexanderThiemann | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: duplicate | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | Blocking: Blocked By: | Differential Revisions: Related Tickets: #8612 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #8612 Comment: With 7.8 or newer you'd get: {{{ test.hs:5:6: error: Record syntax is illegal here: {f_x :: Int, f_y :: Int} test.hs:5:8: error: Not in scope: ?f_x? test.hs:6:8: error: Not in scope: ?f_y? }}} This was reported before, in #8612, and then closed as "not ideal, but acceptable". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 23:19:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 23:19:43 -0000 Subject: [GHC] #10473: Haskell Platform generic linux installer creates incorrect symlinks for /usr/local/man/man1 (and probably /usr/local/share/doc) when directory does not already exist Message-ID: <044.e48ba9f6be5e08fb520971ce04a1e674@haskell.org> #10473: Haskell Platform generic linux installer creates incorrect symlinks for /usr/local/man/man1 (and probably /usr/local/share/doc) when directory does not already exist -------------------------------------+------------------------------------- Reporter: brson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Following instructions here https://www.haskell.org/platform/linux.html for 'generic linux binaries'. After running activate-hs my /usr/local/man/man1 was a symlink to ghc.1 when it should be a directory *containing* ghc.1. This happens when the directory /usr/local/man/man1 does not already exist. Running activate-hs with --verbose --dryrun shows why: ln -sf usr/local/haskell/ghc-7.8.3-x86_64/bin/HsColour usr/local/haskell/ghc-7.8.3-x86_64/bin/activate-hs usr/local/haskell/ghc-7.8.3-x86_64/bin/alex usr/local/haskell/ghc-7.8.3-x86_64/bin/cabal usr/local/hask ell/ghc-7.8.3-x86_64/bin/ghc usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-7.8.3 usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-pkg usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-pkg-7.8.3 usr/local/haskell/ghc-7.8.3-x86_64/ bin/ghci usr/local/haskell/ghc-7.8.3-x86_64/bin/ghci-7.8.3 usr/local/haskell/ghc-7.8.3-x86_64/bin/haddock usr/local/haskell/ghc-7.8.3-x86_64/bin/haddock-ghc-7.8.3 usr/local/haskell/ghc-7.8.3-x86_64/bin/happy usr/l ocal/haskell/ghc-7.8.3-x86_64/bin/hp2ps usr/local/haskell/ghc-7.8.3-x86_64/bin/hpc usr/local/haskell/ghc-7.8.3-x86_64/bin/hsc2hs usr/local/haskell/ghc-7.8.3-x86_64/bin/runghc usr/local/haskell/ghc-7.8.3-x86_64/bin /runghc-7.8.3 usr/local/haskell/ghc-7.8.3-x86_64/bin/runhaskell /usr/local/bin ln -sf usr/local/haskell/ghc-7.8.3-x86_64/share/man/man1/ghc.1 /usr/local/share/man/man1 ln -sf usr/local/haskell/ghc-7.8.3-x86_64/share/doc/ghc /usr/local/share/doc usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-pkg register --verbose=0 --force usr/local/haskell/ghc-7.8.3-x86_64/etc/registrations/GLURaw-1.4.0.1 usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-pkg register --verbose=0 --force usr/local/haskell/ghc-7.8.3-x86_64/etc/registrations/GLUT-2.5.1.1 The second and third ln commands are incorrect. When there are multiple sources it treats the dest as a directory, but in these two instances there are only a single source so ln just creates man1 as a symlink. FWIW when this happens a subsequent install of Rust fails: https://github.com/rust-lang/rust-installer/issues/36. Rust v. Haskell: fight! ``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 1 23:29:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Jun 2015 23:29:38 -0000 Subject: [GHC] #7170: Foreign.Concurrent finalizer called twice in some cases In-Reply-To: <048.7b99ed8be2aa8efa30d578d90781f5ff@haskell.org> References: <048.7b99ed8be2aa8efa30d578d90781f5ff@haskell.org> Message-ID: <063.1cea407b89fc994ddee63421b016d17c@haskell.org> #7170: Foreign.Concurrent finalizer called twice in some cases -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: niteria Type: bug | Status: closed Priority: high | Milestone: 7.6.1 Component: Core Libraries | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | ffi/should_run/7170 | Blocking: | Differential Revisions: D921 -------------------------------------+------------------------------------- Changes (by niteria): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 00:07:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 00:07:49 -0000 Subject: [GHC] #10474: Suggested options for "Use a bigger heap!" seem wrong Message-ID: <045.09a46a04422baa9dc44e9fd381e8cf9d@haskell.org> #10474: Suggested options for "Use a bigger heap!" seem wrong -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/faster.html we have guidance for how to use a bigger heap, which can speed up programs when they are spending too long in GC: > If your program's GC stats (-S RTS option) indicate that it's doing lots of garbage-collection (say, more than 20% of execution time), more memory might help?with the -M or -A RTS options (see Section 4.17.3, ?RTS options to control the garbage collector?). The suggested `-M` seems bad: `-M` won't make GHC use more memory; in fact, you'd expect it to have no/bad effect on programs. Here's one particular example benchmarked on 7.10: ezyang at sabre:~/Dev/serum$ dist/build/serum/serum 15 gen-binaryE +RTS -s -M128m benchmarking gen-binaryE time 53.34 ms (51.51 ms .. 54.90 ms) 0.997 R? (0.992 R? .. 0.999 R?) mean 52.58 ms (51.82 ms .. 54.08 ms) std dev 1.864 ms (1.158 ms .. 2.769 ms) 3,715,656,736 bytes allocated in the heap 1,863,677,408 bytes copied during GC 2,070,152 bytes maximum residency (846 sample(s)) 102,968 bytes maximum slop 6 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 6235 colls, 0 par 2.508s 2.693s 0.0004s 0.0033s Gen 1 846 colls, 0 par 1.628s 1.618s 0.0019s 0.0070s INIT time 0.000s ( 0.000s elapsed) MUT time 2.252s ( 2.702s elapsed) GC time 4.136s ( 4.312s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 6.388s ( 7.014s elapsed) %GC time 64.7% (61.5% elapsed) Alloc rate 1,649,936,383 bytes per MUT second Productivity 35.3% of total user, 32.1% of total elapsed ezyang at sabre:~/Dev/serum$ dist/build/serum/serum 15 gen-binaryE +RTS -s -H128m benchmarking gen-binaryE time 25.02 ms (23.80 ms .. 26.15 ms) 0.988 R? (0.973 R? .. 0.997 R?) mean 28.79 ms (27.61 ms .. 30.55 ms) std dev 3.059 ms (1.871 ms .. 4.412 ms) variance introduced by outliers: 43% (moderately inflated) 6,571,453,840 bytes allocated in the heap 137,492,888 bytes copied during GC 117,280 bytes maximum residency (3 sample(s)) 35,624 bytes maximum slop 132 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 132 colls, 0 par 0.464s 0.475s 0.0036s 0.0115s Gen 1 3 colls, 0 par 0.004s 0.002s 0.0008s 0.0016s INIT time 0.000s ( 0.000s elapsed) MUT time 5.556s ( 6.254s elapsed) GC time 0.468s ( 0.477s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 6.024s ( 6.732s elapsed) %GC time 7.8% (7.1% elapsed) Alloc rate 1,182,767,069 bytes per MUT second Productivity 92.2% of total user, 82.5% of total elapsed }}} It seems to me the writer really meant to suggest `-H`. I'll volunteer to write the patch if someone confirms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 00:08:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 00:08:05 -0000 Subject: [GHC] #10474: Suggested options for "Use a bigger heap!" seem wrong In-Reply-To: <045.09a46a04422baa9dc44e9fd381e8cf9d@haskell.org> References: <045.09a46a04422baa9dc44e9fd381e8cf9d@haskell.org> Message-ID: <060.a2c96585e37776969c0dcbeb2f74ad5f@haskell.org> #10474: Suggested options for "Use a bigger heap!" seem wrong -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > In > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/faster.html > we have guidance for how to use a bigger heap, which can speed up > programs when they are spending too long in GC: > > > If your program's GC stats (-S RTS option) indicate that it's doing > lots of garbage-collection (say, more than 20% of execution time), more > memory might help?with the -M or -A RTS options (see Section > 4.17.3, ?RTS options to control the garbage collector?). > > The suggested `-M` seems bad: `-M` won't make GHC use more memory; in > fact, you'd expect it to have no/bad effect on programs. Here's one > particular example benchmarked on 7.10: > > ezyang at sabre:~/Dev/serum$ dist/build/serum/serum 15 gen-binaryE +RTS -s > -M128m > benchmarking gen-binaryE > time 53.34 ms (51.51 ms .. 54.90 ms) > 0.997 R? (0.992 R? .. 0.999 R?) > mean 52.58 ms (51.82 ms .. 54.08 ms) > std dev 1.864 ms (1.158 ms .. 2.769 ms) > 3,715,656,736 bytes allocated in the heap > 1,863,677,408 bytes copied during GC > 2,070,152 bytes maximum residency (846 sample(s)) > 102,968 bytes maximum slop > 6 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 6235 colls, 0 par 2.508s 2.693s 0.0004s > 0.0033s > Gen 1 846 colls, 0 par 1.628s 1.618s 0.0019s > 0.0070s > > INIT time 0.000s ( 0.000s elapsed) > MUT time 2.252s ( 2.702s elapsed) > GC time 4.136s ( 4.312s elapsed) > EXIT time 0.000s ( 0.000s elapsed) > Total time 6.388s ( 7.014s elapsed) > > %GC time 64.7% (61.5% elapsed) > > Alloc rate 1,649,936,383 bytes per MUT second > > Productivity 35.3% of total user, 32.1% of total elapsed > > ezyang at sabre:~/Dev/serum$ dist/build/serum/serum 15 gen-binaryE +RTS -s > -H128m > benchmarking gen-binaryE > time 25.02 ms (23.80 ms .. 26.15 ms) > 0.988 R? (0.973 R? .. 0.997 R?) > mean 28.79 ms (27.61 ms .. 30.55 ms) > std dev 3.059 ms (1.871 ms .. 4.412 ms) > variance introduced by outliers: 43% (moderately inflated) > > 6,571,453,840 bytes allocated in the heap > 137,492,888 bytes copied during GC > 117,280 bytes maximum residency (3 sample(s)) > 35,624 bytes maximum slop > 132 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 132 colls, 0 par 0.464s 0.475s 0.0036s > 0.0115s > Gen 1 3 colls, 0 par 0.004s 0.002s 0.0008s > 0.0016s > > INIT time 0.000s ( 0.000s elapsed) > MUT time 5.556s ( 6.254s elapsed) > GC time 0.468s ( 0.477s elapsed) > EXIT time 0.000s ( 0.000s elapsed) > Total time 6.024s ( 6.732s elapsed) > > %GC time 7.8% (7.1% elapsed) > > Alloc rate 1,182,767,069 bytes per MUT second > > Productivity 92.2% of total user, 82.5% of total elapsed > }}} > > It seems to me the writer really meant to suggest `-H`. > > I'll volunteer to write the patch if someone confirms. New description: In https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/faster.html we have guidance for how to use a bigger heap, which can speed up programs when they are spending too long in GC: > If your program's GC stats (-S RTS option) indicate that it's doing lots of garbage-collection (say, more than 20% of execution time), more memory might help?with the -M or -A RTS options (see Section 4.17.3, ?RTS options to control the garbage collector?). The suggested `-M` seems bad: `-M` won't make GHC use more memory; in fact, you'd expect it to have no/bad effect on programs. Here's one particular example benchmarked on 7.10: {{{ ezyang at sabre:~/Dev/serum$ dist/build/serum/serum 15 gen-binaryE +RTS -s -M128m benchmarking gen-binaryE time 53.34 ms (51.51 ms .. 54.90 ms) 0.997 R? (0.992 R? .. 0.999 R?) mean 52.58 ms (51.82 ms .. 54.08 ms) std dev 1.864 ms (1.158 ms .. 2.769 ms) 3,715,656,736 bytes allocated in the heap 1,863,677,408 bytes copied during GC 2,070,152 bytes maximum residency (846 sample(s)) 102,968 bytes maximum slop 6 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 6235 colls, 0 par 2.508s 2.693s 0.0004s 0.0033s Gen 1 846 colls, 0 par 1.628s 1.618s 0.0019s 0.0070s INIT time 0.000s ( 0.000s elapsed) MUT time 2.252s ( 2.702s elapsed) GC time 4.136s ( 4.312s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 6.388s ( 7.014s elapsed) %GC time 64.7% (61.5% elapsed) Alloc rate 1,649,936,383 bytes per MUT second Productivity 35.3% of total user, 32.1% of total elapsed ezyang at sabre:~/Dev/serum$ dist/build/serum/serum 15 gen-binaryE +RTS -s -H128m benchmarking gen-binaryE time 25.02 ms (23.80 ms .. 26.15 ms) 0.988 R? (0.973 R? .. 0.997 R?) mean 28.79 ms (27.61 ms .. 30.55 ms) std dev 3.059 ms (1.871 ms .. 4.412 ms) variance introduced by outliers: 43% (moderately inflated) 6,571,453,840 bytes allocated in the heap 137,492,888 bytes copied during GC 117,280 bytes maximum residency (3 sample(s)) 35,624 bytes maximum slop 132 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 132 colls, 0 par 0.464s 0.475s 0.0036s 0.0115s Gen 1 3 colls, 0 par 0.004s 0.002s 0.0008s 0.0016s INIT time 0.000s ( 0.000s elapsed) MUT time 5.556s ( 6.254s elapsed) GC time 0.468s ( 0.477s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 6.024s ( 6.732s elapsed) %GC time 7.8% (7.1% elapsed) Alloc rate 1,182,767,069 bytes per MUT second Productivity 92.2% of total user, 82.5% of total elapsed }}} It seems to me the writer really meant to suggest `-H`. I'll volunteer to write the patch if someone confirms. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 03:05:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 03:05:10 -0000 Subject: [GHC] #960: Lexical call site string In-Reply-To: <057.da5a7918d3a237f53bbf07bfe2771af6@haskell.org> References: <057.da5a7918d3a237f53bbf07bfe2771af6@haskell.org> Message-ID: <072.11649b7522036f990e9a7882a469bbb6@haskell.org> #960: Lexical call site string -------------------------------------+------------------------------------- Reporter: paul@? | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: N/A Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gridaphobe): Can we consider this issue fixed by the implicit call-stacks introduced in https://phabricator.haskell.org/D578? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 03:08:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 03:08:53 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.1d7c4dbbfe5cfe9c026df48002b20aeb@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, it seems like the most controversial part of this is folding over types that aren't syntactically equivalent to the return type. I'm certainly open to the idea of not folding over types if it's not immediately clear that they're equal, but I'm not sure how many levels of indirection would be considered acceptable. In this data type: I'm open to the idea of only folding over fields that are syntactically identical to the type variable, but I'm not exactly sure where the line would be drawn. If I understand the discussion, then if you had this data type: {{{#!hs class (a ~ Int) => Foo a data A a where A1 :: Ord a => a -> T a A2 :: Int -> T Int A3 :: b ~ Int => b -> T Int A4 :: a ~ Int => Int -> T a A5 :: a ~ Int => a -> T a A6 :: (a ~ b, b ~ Int) => Int -> b -> T a A7 :: Foo a => Int -> a -> T a }}} How we would we define "syntactic equality" here? It seems like {{{A1}}} and {{{A5}}} are pretty uncontroversial here, but the other constructors require (at least) one type substitution to infer that their fields could be folded over. Which of these constructors would you all consider to be acceptable for folding over? I'd need to get an idea of this before responding to dolio's questions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 04:48:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 04:48:16 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.a0ad3d2dd708f777db6c8268f2233d4f@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): For the record, I strongly prefer that _if anything_, we only bump the limit, and '''not''' decrease it. There's just no reason to. It's true that 62 is pretty arbitrary, but that's what it already was - lowering it to 8 is going to break some existing programs for presumably zero user-facing benefit, which basically amounts to breaking programs gratuitously. We should really not do this. The fact at least two people run into this seems to be enough support for me! If anything, we should just increase it. Why not just bump it up to 64, or hell, given Anthony said it's already annoying at the current limit, 128? If there's no technical reason otherwise, of course. That's at least a net benefit for one user. If this is inconsistent with other deriving mechanisms for tuples like `Eq`, we should fix that, or at least document it clearly. And if ''that'' is hard, well, we may want to fix it if possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 06:00:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 06:00:11 -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.a83e77b5230b70089259d0eb35b496c8@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: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): It is a bit odd that only the typechecking tests are failing. In any case, I'm not inclined to fix this until we push the new plan for signatures, which will essentially rewrite all of the code these tests touch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 06:47:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 06:47:16 -0000 Subject: [GHC] #960: Lexical call site string In-Reply-To: <057.da5a7918d3a237f53bbf07bfe2771af6@haskell.org> References: <057.da5a7918d3a237f53bbf07bfe2771af6@haskell.org> Message-ID: <072.efeb3ae1084f4bf1830338e1cb89315a@haskell.org> #960: Lexical call site string -------------------------------------+------------------------------------- Reporter: paul@? | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: N/A Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by PaulJohnson): Replying to [comment:17 gridaphobe]: > Can we consider this issue fixed by the implicit call-stacks introduced in https://phabricator.haskell.org/D578? Yes, I believe you can. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 07:20:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 07:20:36 -0000 Subject: [GHC] #10473: Haskell Platform generic linux installer creates incorrect symlinks for /usr/local/man/man1 (and probably /usr/local/share/doc) when directory does not already exist In-Reply-To: <044.e48ba9f6be5e08fb520971ce04a1e674@haskell.org> References: <044.e48ba9f6be5e08fb520971ce04a1e674@haskell.org> Message-ID: <059.5a51701e5895d05f0425d5f086699ab4@haskell.org> #10473: Haskell Platform generic linux installer creates incorrect symlinks for /usr/local/man/man1 (and probably /usr/local/share/doc) when directory does not already exist -------------------------------------+------------------------------------- Reporter: brson | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: You are absolutely right. I submitted a pull request to the haskell- platform github repo a while ago: https://github.com/haskell/haskell- platform/pull/137 If you could, please give that patch a review, and comment. Hopefully it gets merged then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 09:34:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 09:34:05 -0000 Subject: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module In-Reply-To: <046.ebf20f155e05760df4b4c62188044473@haskell.org> References: <046.ebf20f155e05760df4b4c62188044473@haskell.org> Message-ID: <061.d3b842b9ffe47a8d0b3d6593f04f5840@haskell.org> #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: T7672 valid program | Blocking: 10336 Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9b73cb16485f331d9dc1f37826c6d503e24a5b0b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9b73cb16485f331d9dc1f37826c6d503e24a5b0b" Refactor the GlobalRdrEnv, fixing #7672 This patch started innocently enough, by deleting a single call from rnImportDecl, namely let gbl_env = mkGlobalRdrEnv (filterOut from_this_mod gres) The 'filterOut' makes no sense, and was the cause of #7672. But that little loose end led to into a twisty maze of little passages, all alike, which has taken me an unreasonably long time to straighten out. Happily, I think the result is really much better. In particular: * INVARIANT 1 of the GlobalRdrEnv type was simply not true: we had multiple GlobalRdrElts in a list with the same gre_name field. This kludgily implmented one form of shadowing. * Meanwhile, extendGlobalRdrEnvRn implemented a second form of shadowing, by deleting stuff from the GlobalRdrEnv. * In turn, much of this shadowing stuff depended on the Names of the Ids bound in the GHCi InteractiveContext being Internal names, even though the TyCons and suchlike all had External Names. Very confusing. So I have made the following changes * I re-established INVARIANT 1 of GlobalRdrEnv. As a result some strange code in RdrName.pickGREs goes away. * RnNames.extendGlobalRdrEnvRn now makes one call to deal with shadowing, where necessary, and another to extend the environment. It deals separately with duplicate bindings. The very complicated RdrName.extendGlobalRdrEnv becomes much simpler; we need to export the shadowing function, now called RdrName.shadowNames; and we can nuke RdrName.findLocalDupsRdrEnv altogether. RdrName Note [GlobalRdrEnv shadowing] summarises the shadowing story * The Names of the Ids bound in the GHCi interactive context are now all External. See Note [Interactively-bound Ids in GHCi] in HscTypes. * Names for Ids created by the debugger are now made by IfaceEnv.newInteractiveBinder. This fixes a lurking bug which was that the debugger was using mkNewUniqueSupply 'I' to make uniques, which does NOT guarantee a fresh supply of uniques on successive calls. * Note [Template Haskell ambiguity] in RnEnv shows that one TH-related error is reported lazily (on occurrences) when it might be better reported when extending the environment. In some (but not all) cases this was done before; but now it's uniformly at occurrences. In some ways it'd be better to report when extending the environment, but it's a tiresome test and the error is rare, so I'm leaving it at the lookup site for now, with the above Note. * A small thing: RnNames.greAvail becomes RdrName.availFromGRE, where it joins the dual RdrName.gresFromAvail. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 09:34:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 09:34:05 -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.468aa0dd45c6a2c16cf15d90f63eb849@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: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"90fde5220c80bf02d7c6e1d6b4cfe631f068aa0b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="90fde5220c80bf02d7c6e1d6b4cfe631f068aa0b" Mark sigof02 tests as expect_broken Consequence of the GlobalRdrEnv refactoring; see Trac #10472 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 09:34:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 09:34:05 -0000 Subject: [GHC] #10423: Can't infer Monad n from (Monad m, m ~ n) In-Reply-To: <048.3e83406c51a5eb88b203e755f864fc07@haskell.org> References: <048.3e83406c51a5eb88b203e755f864fc07@haskell.org> Message-ID: <063.183950fd2dd6ab91a13698c78489f3cc@haskell.org> #10423: Can't infer Monad n from (Monad m, m ~ n) -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1189196ce7f064af408c9d16874a4c0b78f3a006/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1189196ce7f064af408c9d16874a4c0b78f3a006" Re-do superclass solving (again); fixes #10423 TcInstDcls.tcSuperClasses was getting increasingly baroque as a succession of tickets (#10423 being the latest) pointed out that my cunning plan was not so cunning. The big issue is how to restrict the evidence that we generate for superclass constraints in an instance declaration to avoid superclass loops. See Note [Recursive superclasses] in TcInstDcls which explains the plan. The question is how to implement the plan. The new implementation is much neater, and is described in Note [Solving superclass constraints] in TcInstDcls. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 09:34:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 09:34:05 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.d90440cb7fab028067af2fc922c5f6f1@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b095c97d6e8e5841c28464eb5db67d3c1ca055b8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b095c97d6e8e5841c28464eb5db67d3c1ca055b8" Improve constraint tuples (Trac #10451) * Increase max constraint tuple size to 16 * Produce a civilised error message if the max size is exceeded }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 10:38:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 10:38:39 -0000 Subject: [GHC] #10423: Can't infer Monad n from (Monad m, m ~ n) In-Reply-To: <048.3e83406c51a5eb88b203e755f864fc07@haskell.org> References: <048.3e83406c51a5eb88b203e755f864fc07@haskell.org> Message-ID: <063.87db579e77fb21b1e7cb7e3f88e1276e@haskell.org> #10423: Can't infer Monad n from (Monad m, m ~ n) -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b1b2b44a86a34dae9eadd27af507c8b2c847ae2d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b1b2b44a86a34dae9eadd27af507c8b2c847ae2d" Test Trac #10423 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 10:40:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 10:40:23 -0000 Subject: [GHC] #10423: Can't infer Monad n from (Monad m, m ~ n) In-Reply-To: <048.3e83406c51a5eb88b203e755f864fc07@haskell.org> References: <048.3e83406c51a5eb88b203e755f864fc07@haskell.org> Message-ID: <063.beb3f75605de858747d85d09e9ad2c99@haskell.org> #10423: Can't infer Monad n from (Monad m, m ~ n) -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | typecheck/should_compile/T10423 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_compile/T10423 * resolution: => fixed Comment: Fixed, thank you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 10:44:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 10:44:03 -0000 Subject: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module In-Reply-To: <046.ebf20f155e05760df4b4c62188044473@haskell.org> References: <046.ebf20f155e05760df4b4c62188044473@haskell.org> Message-ID: <061.8679a341b9ac87234f89f39c68a63109@haskell.org> #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T7672 Blocked By: | Blocking: 10336 Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: T7672 => rename/should_compile/T7672 Comment: Despite all this clean up, the test for #7672 ''still'' does not work. Reason: in module A (comment:3), the data type `T` is in scope with two different provenances: * As `LocalDef` "T" * As `Imported` "B.T" But annoyingly, `Provenance` can't represent both; currently it's an either/or. Fixing this really means changing the `Provenance` data type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 10:59:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 10:59:27 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.4649d6b2cc3233f7e859b98fe4799606@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8a3834833d2636134f2e0617e6d85a68e92de551/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8a3834833d2636134f2e0617e6d85a68e92de551" Test Trac #10451 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 11:01:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 11:01:01 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.132e4a84877348cf1fe747355a3a39a3@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm ok with increasing the limit further. If anyone wants to do that * Add extra declarations in `ghc-prim:GHC.Classes` * Increase `mAX_CTUPLE_SIZE` in `compiler/main/Constants.hs` to match Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 11:02:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 11:02:34 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.ae0f4f887e44a0860af5478bd716fcc7@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I vote for, well, syntactic equality. That means `A1`, `A5`, and `A7`, but none of the others. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 11:37:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 11:37:30 -0000 Subject: [GHC] #10466: Bogus multiple-declaration error in GHCi + Template Haskell In-Reply-To: <046.d8399315d1063d9ff461c2d68cee54f0@haskell.org> References: <046.d8399315d1063d9ff461c2d68cee54f0@haskell.org> Message-ID: <061.f8ac02358863bb35010f1141f6def7e0@haskell.org> #10466: Bogus multiple-declaration error in GHCi + Template Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8e5f8cf4892971f9e1cf143672801eaad7138098/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8e5f8cf4892971f9e1cf143672801eaad7138098" Test Trac #10466 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 11:39:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 11:39:29 -0000 Subject: [GHC] #10466: Bogus multiple-declaration error in GHCi + Template Haskell In-Reply-To: <046.d8399315d1063d9ff461c2d68cee54f0@haskell.org> References: <046.d8399315d1063d9ff461c2d68cee54f0@haskell.org> Message-ID: <061.a16323b889fb9ab36067571f72916131@haskell.org> #10466: Bogus multiple-declaration error in GHCi + Template Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | ghci/scripts/T10466 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => ghci/scripts/T10466 * resolution: => fixed Comment: Fixed by [changeset:"9b73cb16485f331d9dc1f37826c6d503e24a5b0b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9b73cb16485f331d9dc1f37826c6d503e24a5b0b" Refactor the GlobalRdrEnv, fixing #7672 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 11:43:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 11:43:33 -0000 Subject: [GHC] #10438: GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings In-Reply-To: <049.41b7d0833f2869d11544c1b4baf6f0c5@haskell.org> References: <049.41b7d0833f2869d11544c1b4baf6f0c5@haskell.org> Message-ID: <064.d77a8054f8d654a81b90973852358b73@haskell.org> #10438: GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings -------------------------------------+------------------------------------- Reporter: rpglover64 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b2b69b2a31e5d41210e851687887377072afd020/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b2b69b2a31e5d41210e851687887377072afd020" Test Trac #10438 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 11:46:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 11:46:00 -0000 Subject: [GHC] #10438: GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings In-Reply-To: <049.41b7d0833f2869d11544c1b4baf6f0c5@haskell.org> References: <049.41b7d0833f2869d11544c1b4baf6f0c5@haskell.org> Message-ID: <064.555927d2e11281bf409904ea6781dbc3@haskell.org> #10438: GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings -------------------------------------+------------------------------------- Reporter: rpglover64 | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: partial- Blocked By: | sigs/should_compile/T10438 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => partial-sigs/should_compile/T10438 * milestone: => 7.10.2 Comment: Thanks. I've added a test to make sure it stays good. I'll re-milestone the ticket for the 7.10 branch, but I don't have time to fix this on the 7.10 branch. I'll leave the ticket open in case anyone else does. (Finding which patch on HEAD fixed it would be a good start.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 13:32:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 13:32:05 -0000 Subject: [GHC] #10052: Panic (something to do with floatExpr?) In-Reply-To: <044.712619dfc86074dec5613c292886ee1f@haskell.org> References: <044.712619dfc86074dec5613c292886ee1f@haskell.org> Message-ID: <059.62db39bf15d02ac5a3cf25cdc6c910eb@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"091944e3aec736b440a9c1204f152004e382c967/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="091944e3aec736b440a9c1204f152004e382c967" compiler: make sure we reject -O + HscInterpreted When using GHCi, we explicitly reject optimization, because the compilers optimization passes can introduce unboxed tuples, which the interpreter is not able to handle. But this goes the other way too: using GHCi on optimized code may cause the optimizer to float out breakpoints that the interpreter introduces. This manifests itself in weird ways, particularly if you as an API client use custom DynFlags to introduce optimization in combination with HscInterpreted. It turns out we weren't checking for consistent DynFlag settings when doing `setSessionDynFlags`, as #10052 showed. While the main driver handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this elsewhere. This does a little refactoring to split out some of the common code, and immunizes the various `DynFlags` utilities in the `GHC` module from this particular bug. We should probably be checking other general invariants too. This fixes #10052, and adds some notes about the behavior in `GHC` and `FloatOut` As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it didn't exist (somehow). Signed-off-by: Austin Seipp Reviewed By: edsko Differential Revision: https://phabricator.haskell.org/D727 GHC Trac Issues: #10052 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 13:40:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 13:40:49 -0000 Subject: [GHC] #10468: debug test case fails on Windows In-Reply-To: <045.b19678979c06629a2acceac03a72cd6b@haskell.org> References: <045.b19678979c06629a2acceac03a72cd6b@haskell.org> Message-ID: <060.b5b48c01dde3ac7a97089840c7172047@haskell.org> #10468: debug test case fails on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: scpmw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Debugging) | Keywords: Resolution: | Architecture: Operating System: Windows | Unknown/Multiple Type of failure: None/Unknown | Test Case: debug Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by scpmw): Never got around to testing Windows... Fortunately less work than I had feared. The attached patch makes things work to the point where we can compile everything with `-g` and use gdb on the product. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 13:52:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 13:52:55 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.0664dc796b539bbfd90eadff75916dee@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): That seems to make sense to me as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 13:55:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 13:55:36 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.2595a3ac5fcd430ba0bd5982e27a5491@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): Speculation: perhaps there's a difference in the ABI for C++ exceptions between the MS C Compiler and the gcc that we ship with GHC 7.8 and later? Did you try creating the DLL using gcc? Possibly related: 5200bdeb26c5ec98739b14b10fc8907296bceeb9 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 14:00:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 14:00:50 -0000 Subject: [GHC] #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) In-Reply-To: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> References: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> Message-ID: <061.8268ccffc4ae336d014bfdba9cfdccc7@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) -------------------------------------+------------------------------------- Reporter: rleslie | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #1042 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * status: infoneeded => closed * resolution: => wontfix Comment: I polled the core libraries committee about this back in August. We wound up fairly split on the issue, but decided to let the status quo stand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 14:12:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 14:12:24 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.be9ee5fe9c610a5146f6ccab44c11d70@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK, I can live with that. That way, I can derive {{{Foldable}}} for any GADT and still fold over all the terms that have types equal to the last type parameter (up to rewriting {{{Con :: PlainTy -> PlainTy -> ... -> GADT PlainTy}}} as {{{Con :: a ~ PlainTy => a -> a -> ... -> GADT a}}}). I'm not the original author of the {{{DeriveFunctor/Foldable/Traversable}}} extensions, but I'd be willing to help write a wiki article on how they currently work (and how {{{DeriveFoldable}}} will eventually work). Is there a good template article from which I could adapt? All I know about the {{{deriving}}} algorithms is what I gleaned from [http://git.haskell.org/ghc.git/blob/9f968e97a0de9c2509da00f6337b612dd72a0389:/compiler/typecheck/TcDeriv.hs#l1331 comments] in [http://git.haskell.org/ghc.git/blob/9f968e97a0de9c2509da00f6337b612dd72a0389:/compiler/typecheck/TcDeriv.hs#l1425 TcDeriv.hs], [http://git.haskell.org/ghc.git/blob/9f968e97a0de9c2509da00f6337b612dd72a0389:/compiler/typecheck/TcGenDeriv.hs#l1476 as] well [http://git.haskell.org/ghc.git/blob/9f968e97a0de9c2509da00f6337b612dd72a0389:/compiler/typecheck/TcGenDeriv.hs#l1725 as] from [http://git.haskell.org/ghc.git/blob/9f968e97a0de9c2509da00f6337b612dd72a0389:/compiler/typecheck/TcGenDeriv.hs#l1800 TcGenDeriv.hs], but they may be too formal for wiki purposes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 16:37:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 16:37:22 -0000 Subject: [GHC] #10461: Suggest UnliftedFFITypes when applicable In-Reply-To: <045.902aa16bd3530734a7de01d015325c99@haskell.org> References: <045.902aa16bd3530734a7de01d015325c99@haskell.org> Message-ID: <060.052e0eed47e9bffa8c19f16e9155844a@haskell.org> #10461: Suggest UnliftedFFITypes when applicable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"3758050f02c1de6af41c50ed122b3df012d400ff/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3758050f02c1de6af41c50ed122b3df012d400ff" Improve FFI error reporting I refactored TcType FFI functions to return Validity rather than Bool, which turned out to be an easy way to solve Trac #10461. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 16:38:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 16:38:14 -0000 Subject: [GHC] #10461: Suggest UnliftedFFITypes when applicable In-Reply-To: <045.902aa16bd3530734a7de01d015325c99@haskell.org> References: <045.902aa16bd3530734a7de01d015325c99@haskell.org> Message-ID: <060.6e6a061e1158cbd2b914e58cda88620d@haskell.org> #10461: Suggest UnliftedFFITypes when applicable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | ffi/should_fail/T10461 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => ffi/should_fail/T10461 * resolution: => fixed Comment: Good idea and easily done. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 17:37:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 17:37:32 -0000 Subject: [GHC] #9349: excessive inlining due to state hack In-Reply-To: <047.59a8e661fb91965de593a33a83b24298@haskell.org> References: <047.59a8e661fb91965de593a33a83b24298@haskell.org> Message-ID: <062.54b884f59efc8f0a012d06102b216779@haskell.org> #9349: excessive inlining due to state hack -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): http://stackoverflow.com/questions/29404065/why-does-this-haskell-code- run-slower-with-o is another somewhat real-live example of this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 17:58:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 17:58:25 -0000 Subject: [GHC] #10474: Suggested options for "Use a bigger heap!" seem wrong In-Reply-To: <045.09a46a04422baa9dc44e9fd381e8cf9d@haskell.org> References: <045.09a46a04422baa9dc44e9fd381e8cf9d@haskell.org> Message-ID: <060.b9b9da225dda60295efe925e00a6689a@haskell.org> #10474: Suggested options for "Use a bigger heap!" seem wrong -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Agreed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 18:04:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 18:04:43 -0000 Subject: [GHC] #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type In-Reply-To: <047.60fe47838743a4cb466668b7b2d86836@haskell.org> References: <047.60fe47838743a4cb466668b7b2d86836@haskell.org> Message-ID: <062.1e6922f9446456be956deaa6f7ffbce8@haskell.org> #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type ---------------------------------------+--------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+--------------------------------- Comment (by rwbarton): Does your generated `includes/ghcautoconf.h` set `arm_HOST_ARCH_PRE_ARMv6` and/or `arm_HOST_ARCH_PRE_ARMv7`? (I see your board has an ARMv7 processor, but maybe the Debian toolchain is set up to target an earlier architecture by default.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 18:39:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 18:39:20 -0000 Subject: [GHC] #9499: Add -prelude-is flag In-Reply-To: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> References: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> Message-ID: <064.7d9c3f3898a6aa8b497d5aef94271c0d@haskell.org> #9499: Add -prelude-is flag -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: flag Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9590 | Blocking: | Differential Revisions: Phab:D171 -------------------------------------+------------------------------------- Comment (by rwbarton): Agree with hvr's comments. An quick-and-dirty hack that also works (I don't entirely understand why it works, but it does) is just to add a file `Prelude.hs` to your project consisting of {{{ module Prelude (module My.Fancy.Prelude) where import My.Fancy.Prelude }}} Apparently this overrides the Prelude module from base for the scope of your project, even for the implicit Prelude import in modules that don't have an explicit one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 18:45:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 18:45:32 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize In-Reply-To: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> References: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> Message-ID: <057.ba6df84f46db101f2c750762a82e65e6@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I have a vague recollection (from the time that the default stack size limit was effectively removed) that GHC 7.6.3 was lying and would display the stack size limit as the current stack size in that error message regardless of the actual current stack size. I don't understand though why you are seeing a stack size that is so much larger than the limit though; and I also notice that even when increasing the stack size limit to much more than the reported stack size (like `-K1M`) the reported stack size does not change (and then the error message becomes rather confusing). So it does seem likely there is some sort of bug here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 18:47:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 18:47:25 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.5f2ac926faa896c379c7222ef3be6461@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D852 -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:10 trommler]: > Replying to [comment:4 George]: > > Not sure but the -flat_namespace option might be what you are looking for. > How bad as in breaking assumptions made by MacOS would it be to use `-flat_namespace`? I don't know, but I found this cryptic comment in `compiler/main/SysTools.hs`: -- This feature requires Mac OS X 10.3 or later; there is -- a similar feature, -flat_namespace -undefined suppress, -- which works on earlier versions, but it has other -- disadvantages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 18:52:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 18:52:41 -0000 Subject: [GHC] #10442: Loading of shared libraries is problematic in ghc 7.10.1 In-Reply-To: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> References: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> Message-ID: <068.77ede35910e86653baed73904207fca8@haskell.org> #10442: Loading of shared libraries is problematic in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Isn't this another consequence of the fix for #8935 (opening shared libraries with RTLD_LOCAL)? So should we also link temporary object files against any libraries specified on the ghc(i) command line with `-lfoo`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 18:52:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 18:52:52 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.e932f923054bdc08030eafe8946109e8@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+----------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by rwbarton): I think this is the same as #10442, and that there's currently no way to get `.o` files being loaded into ghci (like your `cbits/crypt.o`) to see symbols from dynamic C libraries (except the ones like libgmp that ghci is already linked against). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 19:04:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 19:04:38 -0000 Subject: [GHC] #10444: Tex.Read.Lex.lex broken In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.73a46bf2d6e60259593f045959cfa4b8@haskell.org> #10444: Tex.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: hvr (added) Comment: Hi, I agree that this is a deviation from the Report-specified behavior of lex, since ? is a Unicode symbol character; and thanks for the patch. However, we generally try fairly hard not to introduce new boot files in base. ccing hvr, who is most likely to know off-hand: can this import cycle be worked around easily (probably by moving `isPunctuation` and `isSymbol` into `GHC.Unicode`)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 19:25:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 19:25:29 -0000 Subject: [GHC] #10052: Panic (something to do with floatExpr?) In-Reply-To: <044.712619dfc86074dec5613c292886ee1f@haskell.org> References: <044.712619dfc86074dec5613c292886ee1f@haskell.org> Message-ID: <059.243173d77279d513f42a3950ecc58bc4@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 19:25:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 19:25:44 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.5c2160ca7b84f19752962a37a2d693af@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 19:43:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 19:43:23 -0000 Subject: [GHC] #10474: Suggested options for "Use a bigger heap!" seem wrong In-Reply-To: <045.09a46a04422baa9dc44e9fd381e8cf9d@haskell.org> References: <045.09a46a04422baa9dc44e9fd381e8cf9d@haskell.org> Message-ID: <060.1d771e6650c3165e419acfe0e53e2d0a@haskell.org> #10474: Suggested options for "Use a bigger heap!" seem wrong -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Yeah, this is way better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 19:51:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 19:51:28 -0000 Subject: [GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.1e1074848ada4d0e545197af69d7700d@haskell.org> #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: Resolution: | Architecture: x86 Operating System: Unknown/Multiple | Test Case: Type of failure: Incorrect | Blocking: warning at compile-time | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: infoneeded => new Comment: (How) is this supposed to work at all? I mean, if you want to be able to run a TH splice, you need to at some point generate code for the values used in the splice, right? Is the TH runner supposed to recompile the necessary module(s) with the bytecode generator? A minimal reproducer is simply {{{ -- A.hs {-# LANGUAGE TemplateHaskell #-} module A where a = [|3|] -- B.hs {-# LANGUAGE TemplateHaskell #-} module B where import A x = $(a) -- command: ghc -fno-code B }}} It might be possible to diagnose the situation and produce a better error message, but making this actually work seems solidly in feature request territory to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 19:56:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 19:56:25 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.cbee582605b7303d1670c742af3442c5@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by malcolmw): There is a possibility that this is a conjunction of some weirdness in the particular version of the MS VC++ runtime, together with a weirdness in the ghc initialisation. Unfortunately, we have not been able to check a different version of the MSVCRT on that machine. Also, sadly, it is not a possibility for us to build our C++ DLLs with gcc on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 20:01:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 20:01:47 -0000 Subject: [GHC] #10425: User's guide PDF version: Example with wrong indentation in Section 13.1.1.2 In-Reply-To: <042.88dde6c88a2451f4e68effb85ca57c32@haskell.org> References: <042.88dde6c88a2451f4e68effb85ca57c32@haskell.org> Message-ID: <057.813134ccdf847d17bc9c15a1720dff41@haskell.org> #10425: User's guide PDF version: Example with wrong indentation in Section 13.1.1.2 -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"5688053a5c0a188c8bc94cd2c41d178b5c716535/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5688053a5c0a188c8bc94cd2c41d178b5c716535" Detabify a programlisting in the User's Guide (#10425) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 20:02:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 20:02:58 -0000 Subject: [GHC] #10425: User's guide PDF version: Example with wrong indentation in Section 13.1.1.2 In-Reply-To: <042.88dde6c88a2451f4e68effb85ca57c32@haskell.org> References: <042.88dde6c88a2451f4e68effb85ca57c32@haskell.org> Message-ID: <057.708da3d8f61ca3bd301f6c5004da44a9@haskell.org> #10425: User's guide PDF version: Example with wrong indentation in Section 13.1.1.2 -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: Thanks. There was a tab character in that example code which I'm going to assume was responsible for the wrong indentation in the PDF file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 20:09:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 20:09:10 -0000 Subject: [GHC] #10444: Tex.Read.Lex.lex broken In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.064e918dc93167602fe3fea79ceb0525@haskell.org> #10444: Tex.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mfdyck.google): isPunctuation and isSymbol are defined in terms of GeneralCategory, which derives Read, and GHC.Read imports Text.Read.Lex. We could move GeneralCategory and generalCategory to GHC.Unicode and standalone derive Read instance in GHC.Read or Data.Char; acceptable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 20:10:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 20:10:55 -0000 Subject: [GHC] #10400: Run time increases by 40% in fractal plotter core loop In-Reply-To: <046.142ae12f95bb9de430d91e08ef848a7a@haskell.org> References: <046.142ae12f95bb9de430d91e08ef848a7a@haskell.org> Message-ID: <061.731bca8a9e15486497b91bf4f8bddfd7@haskell.org> #10400: Run time increases by 40% in fractal plotter core loop -------------------------------------+------------------------------------- Reporter: saffroy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): That said, we do very much appreciate bug reports like this one, even if in the end we are unable to do much about them! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 20:13:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 20:13:05 -0000 Subject: [GHC] #10444: Tex.Read.Lex.lex broken In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.f29a389994b59667173ae81ccba81a20@haskell.org> #10444: Tex.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:6 mfdyck.google]: > isPunctuation and isSymbol are defined in terms of GeneralCategory, which derives Read, and GHC.Read imports Text.Read.Lex. Ah, gotcha. > We could move GeneralCategory and generalCategory to GHC.Unicode and standalone derive Read instance in GHC.Read or Data.Char; acceptable? Probably more acceptable than the boot file; I'll defer to hvr on this subject though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 20:25:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 20:25:45 -0000 Subject: [GHC] #10475: detabify User's Guide Message-ID: <047.1e4a60602b92fd833c83e920802a19a6@haskell.org> #10475: detabify User's Guide -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: task | Status: new Priority: low | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The User's Guide .xml files use a fairly random-looking mix of tabs and spaces for indentation. Let's get rid of the tabs and then enforce their absence with git hooks. Why do this? See #10425; apparently tabs within programlisting elements are rendered as some number of spaces other than 8 in the PDF version (only!) I briefly tried to find other instances of the same issue, but there are thousands of tab characters in the User's Guide and I'm too lazy to try to find only the ones within programlisting elements. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 20:31:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 20:31:23 -0000 Subject: [GHC] #10474: Suggested options for "Use a bigger heap!" seem wrong In-Reply-To: <045.09a46a04422baa9dc44e9fd381e8cf9d@haskell.org> References: <045.09a46a04422baa9dc44e9fd381e8cf9d@haskell.org> Message-ID: <060.f4315fa3ab3bf405347804f87d7bae82@haskell.org> #10474: Suggested options for "Use a bigger heap!" seem wrong -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D937 -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D937 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 20:44:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 20:44:14 -0000 Subject: [GHC] #10476: Wrong ar during cross-compilation Message-ID: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> #10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: cross- | Type of failure: Building GHC compiling | failed Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It appears that during cross-compilation, while building stage 1 ghc, the build system uses ar for target architecture instead of ar for build/host architecture. It will cause linking errors on systems where ar for target architecture is incompatible with ar for build/host architecture (sample output attached below). {{{ (...) "rm" -f libraries/Cabal/Cabal/dist- boot/build/libHSCabal-1.22.3.0-3tdTeip89ooLNDDdwdA54s.a.contents "rm" -f libraries/bin-package-db/dist-boot/build/libHSbin-package- db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a libraries/bin-package-db/dist- boot/build/libHSbin-package-db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a.contents echo libraries/bin-package-db/dist-boot/build/GHC/PackageDb.o >> libraries/bin-package-db/dist-boot/build/libHSbin-package- db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a.contents "/Users/jakub/src/haskell/PNaCl/gsoc/wrappers/i686-unknown-nacl-ar" q libraries/bin-package-db/dist-boot/build/libHSbin-package- db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a @libraries/bin-package-db/dist- boot/build/libHSbin-package-db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a.contents /Users/jakub/src/nacl_sdk/pepper_canary/toolchain/mac_x86_newlib/bin/i686 -nacl-ar: creating libraries/bin-package-db/dist-boot/build/libHSbin- package-db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a "rm" -f libraries/bin-package-db/dist-boot/build/libHSbin-package- db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a.contents (...) ld: archive has no table of contents file '/Users/jakub/src/haskell/PNaCl /ghc-pnacl/libraries/terminfo/dist- boot/build/libHSterminfo-0.4.0.1-7qZwBlx3clR8sTBilJl253.a' for architecture x86_64 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 20:50:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 20:50:15 -0000 Subject: [GHC] #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) In-Reply-To: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> References: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> Message-ID: <061.15e2b0ceacb3807cac119ed0e4a2004e@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) -------------------------------------+------------------------------------- Reporter: rleslie | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #1042 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rleslie): Sorry to hear that. Can we correct the documentation then, to acknowledge this exception to the claim that ?All arithmetic is performed modulo 2!^n? if that?s not going to be the case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 21:00:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 21:00:55 -0000 Subject: [GHC] #9938: GHC's link step needs to be told which packages to link In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.48c2f8c338cdcad34ad5e14f4820e0f4@haskell.org> #9938: GHC's link step needs to be told which packages to link -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): T9938 is acting up (unexpectedly passing) again, presumably due to some optimizer change. I don't really see the value in a test that verifies the absence of a feature that we know GHC does not have (tracking dependencies of `.o` files that were produced by GHC), though I suppose it means we have already done the work of creating the test if the feature gets added (but that doesn't look too likely to happen in the near future). But if we want to keep the test, can we find a dependency that we can count on not getting inlined away? Something that involves a global variable would be a good bet, but the only ones I can think of are in base (always linked in anyways) and random (not necessarily always built?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 21:05:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 21:05:32 -0000 Subject: [GHC] #10452: ApiAnnotations : rationalise tests In-Reply-To: <044.92365aad7d7f8e3dca664006b00e42b6@haskell.org> References: <044.92365aad7d7f8e3dca664006b00e42b6@haskell.org> Message-ID: <059.4213be1d46278a0d19b43718f0218f39@haskell.org> #10452: ApiAnnotations : rationalise tests -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: In `HEAD`, and also merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 21:09:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 21:09:13 -0000 Subject: [GHC] #9938: GHC's link step needs to be told which packages to link In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.6d79f8d1f63fb3490531d2f48386d6a2@haskell.org> #9938: GHC's link step needs to be told which packages to link -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): We can actually make the test contain a package and use that with whatever hacks we need, can't we? There are several Cabal based tests in the build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 21:11:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 21:11:06 -0000 Subject: [GHC] #9938: GHC's link step needs to be told which packages to link In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.27590e7e95d766f20514f8acc81c2938@haskell.org> #9938: GHC's link step needs to be told which packages to link -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Right, we definitely could do that too, just a bit more heavyweight, but if nothing simpler suggests itself then perhaps best. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 21:15:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 21:15:27 -0000 Subject: [GHC] #9938: GHC's link step needs to be told which packages to link In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.25ffa77d424d7e066670a05546dbe5ab@haskell.org> #9938: GHC's link step needs to be told which packages to link -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"942a074ccb441320daae74fadf37b44e636dc102/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="942a074ccb441320daae74fadf37b44e636dc102" testsuite: mark test T9938 (#9938) as passing again Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 21:15:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 21:15:27 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.b6525dbcbb5b91a0a1bcb2a7d389ef27@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"7a82b77691fb90c4af6863673f10e454a449739e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7a82b77691fb90c4af6863673f10e454a449739e" newTempName: Do not include pid in basename The filename of temporary files, especially the basename of C files, can end up in the output in some form, e.g. as part of linker debug information. In the interest of bit-wise exactly reproducible compilation (#4012), the basename of the temporary file no longer contains random information (it used to ontain the process id). This is ok, as the temporary directory used contains the pid (see getTempDir). This patch has been applied to the Debian package (version 7.10.1-5) and allowed a fully bit-wise reproducible build: https://reproducible.debian.net/rb-pkg/experimental/amd64/ghc.html Reviewed By: austin, rwbarton Differential Revision: https://phabricator.haskell.org/D910 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 21:18:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 21:18:59 -0000 Subject: [GHC] #9938: GHC's link step needs to be told which packages to link In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.54388981760cd9ee249c0d56e3b461f4@haskell.org> #9938: GHC's link step needs to be told which packages to link -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): As I said to Reid on IRC: I'm fine with either doing the cabal test thing, or just deleting this test outright. I see Reid marked it as feature request, and the history is in the ticket references. So I don't think we'll lose much here if we just remove it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 21:22:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 21:22:06 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.ccfea665bc298eeb34918eb2a3ae01ad@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: Fuuzetsu => * status: patch => new * milestone: 7.10.2 => 7.12.1 Comment: Okay, moving back to 7.12.1 for future work. 7a82b77691fb90 is in `ghc-7.10` now (as 1ff03e466c). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 21:54:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 21:54:21 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.0e9372946dc397fb942c95e8e9a033b4@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by jeltsch): I have an issue with GHC?7.10.1, which is probably rooted in the same bug. The following code is accepted by GHC?7.8.3, but not 7.10.1: {{{ {-# LANGUAGE TypeFamilies #-} type family F a :: * type family G b :: * x :: G (F a) ~ a => F a x = undefined }}} GHC?7.10.1 gives the following error message: {{{ Could not deduce (F a0 ~ F a) from the context (G (F a) ~ a) bound by the type signature for x :: (G (F a) ~ a) => F a at Test.hs:7:6-23 NB: ?F? is a type function, and may not be injective The type variable ?a0? is ambiguous In the ambiguity check for the type signature for ?x?: x :: forall a. (G (F a) ~ a) => F a To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ?x?: x :: G (F a) ~ a => F a }}} Is this code accepted by GHC HEAD? I came across this problem when trying to recompile the `incremental- computing` package with GHC?7.10.1. Since this issue breaks `incremental- computing` in a nontrivial way, I would be ''extremely'' happy if the fix of this bug would make it into GHC?7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 21:55:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 21:55:25 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.772423f1ff7c79c7293a35ca2bb0677e@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Changes (by jeltsch): * cc: jeltsch (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 22:20:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 22:20:52 -0000 Subject: [GHC] #10474: Suggested options for "Use a bigger heap!" seem wrong In-Reply-To: <045.09a46a04422baa9dc44e9fd381e8cf9d@haskell.org> References: <045.09a46a04422baa9dc44e9fd381e8cf9d@haskell.org> Message-ID: <060.c0892562890f107b5a3668393668f83d@haskell.org> #10474: Suggested options for "Use a bigger heap!" seem wrong -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D937 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"6adfb88a4eb1988d5c674513545280fc66bf1627/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6adfb88a4eb1988d5c674513545280fc66bf1627" Suggest -H to improve GC productivity, fixes #10474. Signed-off-by: Edward Z. Yang Test Plan: none Reviewers: rwbarton, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D937 GHC Trac Issues: #10474 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 22:21:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 22:21:18 -0000 Subject: [GHC] #10474: Suggested options for "Use a bigger heap!" seem wrong In-Reply-To: <045.09a46a04422baa9dc44e9fd381e8cf9d@haskell.org> References: <045.09a46a04422baa9dc44e9fd381e8cf9d@haskell.org> Message-ID: <060.f9767fa0d2d935d471e0db6df37fe0c9@haskell.org> #10474: Suggested options for "Use a bigger heap!" seem wrong -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D937 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 22:39:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 22:39:28 -0000 Subject: [GHC] #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) In-Reply-To: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> References: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> Message-ID: <061.e41821942dbfedae5fdd0d27855dc7c5@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) -------------------------------------+------------------------------------- Reporter: rleslie | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #1042 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): I have no objection to more clearly documenting the fact that an error occurs in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 22:54:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 22:54:41 -0000 Subject: [GHC] #8435: Do not copy stack after stack overflow In-Reply-To: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> References: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> Message-ID: <060.72c209a5171ceb47d130c1942747f3af@haskell.org> #8435: Do not copy stack after stack overflow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by archblob): * owner: simonmar => * status: closed => new * resolution: fixed => * milestone: => 7.10.2 Comment: This change was reverted in d70b19bfb5ed79b22c2ac31e22f46782fc47a117 and is the reason for the difference between 7.10.1 and 7.8.4 outpus in #10445. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 23:12:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 23:12:40 -0000 Subject: [GHC] #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) In-Reply-To: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> References: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> Message-ID: <061.3c270ee82525a61718284173a805f254@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) -------------------------------------+------------------------------------- Reporter: rleslie | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #1042 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I believe the correct statements would be * The Bounded, Enum, Integral, Ord, Real and Show type class methods treat Int as a subset of Integer. * The Num and Read type class methods treat Int as a quotient of Integer ("mod 2^n^"), except that signum treats Int as a subset of Integer, and abs is in a funny in-between state. Basically it is only the ring operations (addition, subtraction, multiplication, and hence conversion from Integer) that are performed using modular arithmetic. * (For Eq, it doesn't matter whether you consider Int to be a subset or a quotient of Integer.) Not sure where to put all this, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 23:18:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 23:18:28 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.32dc1e331c83d84ae0e4b0c0d3a9f732@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:29 jeltsch]: > Is this code accepted by GHC HEAD? Yes, though it also gives a warning about a redundant constraint `G (F a) ~ a`... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 23:21:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 23:21:15 -0000 Subject: [GHC] #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) In-Reply-To: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> References: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> Message-ID: <061.a59a18ab592e8bf3695b4c2d0fe4fb63@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) -------------------------------------+------------------------------------- Reporter: rleslie | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #1042 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): But yes, it would certainly be good to explicitly call attention to the case of {{{minBound `div` (-1)}}} somewhere, as even if the behavior is expected once you think of it, it's not at all obvious that this special case exists if you haven't encountered it before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 2 23:37:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Jun 2015 23:37:34 -0000 Subject: [GHC] #10476: Wrong ar during cross-compilation In-Reply-To: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> References: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> Message-ID: <061.1805d0cdd955d6ad875f8c2e1d662bb3@haskell.org> #10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: cross- Operating System: Unknown/Multiple | compiling Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Strange, this time it really seems that there is the correct plumbing in place to distinguish the AR commands to be used by different stages, and the variables are substituted correctly in the `mk/config.mk` of my cross- compiled ghc. Will rerun the build and look for this command in the output later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 00:30:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 00:30:49 -0000 Subject: [GHC] #10476: Wrong ar during cross-compilation In-Reply-To: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> References: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> Message-ID: <061.59ad9683f4f7cda2c38b308575b33f75@haskell.org> #10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: cross- Operating System: Unknown/Multiple | compiling Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => infoneeded Comment: I confirmed that my cross-compilation uses `/usr/bin/ar` at this point, so I was unable to reproduce the problem. What does your bootstrap compiler output for `ghc --info` under `("ar command",___)`? That command should end up as the value of `AR_STAGE0` in `mk/config.mk`, and then get run for `ar` here since `bin-package-db` is a stage 0 package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 00:36:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 00:36:36 -0000 Subject: [GHC] #10475: detabify User's Guide In-Reply-To: <047.1e4a60602b92fd833c83e920802a19a6@haskell.org> References: <047.1e4a60602b92fd833c83e920802a19a6@haskell.org> Message-ID: <062.6cf0ce0c8155225d3aeeb1045e17ada0@haskell.org> #10475: detabify User's Guide -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: task | thoughtpolice Priority: low | Status: new Component: Documentation | Milestone: Resolution: | Version: 7.10.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 00:51:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 00:51:58 -0000 Subject: [GHC] #10477: Tab-completing in a directory with Unicode heiroglyph crashes ghci Message-ID: <048.439ace31a3f068f577dd280d2e502f1d@haskell.org> #10477: Tab-completing in a directory with Unicode heiroglyph crashes ghci -------------------------------------------+------------------------------- Reporter: acfoltzer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- With a file called ?.hs in `C:\Users\acfoltzer`, the following in `cmd.exe`: {{{ C:\Users\acfoltzer>chcp 65001 Active code page: 65001 C:\Users\acfoltzer>ghci GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :l C:\cygwin\home\acfoltzer\ ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.1 for i386-unknown-mingw32): Enum.toEnum{Word16}: tag (78166) is outside of bounds (0,65535) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Here, I'm setting the code page first according to the various bits of folk wisdom on the Internet about getting Unicode to properly display in `cmd.exe`. I don't get this crash with a Cygwin terminal, but rather see `??.hs`. I came across this because I was getting the same exception in the Cryptol REPL, so I suspect it's not unique to GHCi, but is rather something fishy in base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 01:03:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 01:03:31 -0000 Subject: [GHC] #10478: Shorter import syntax Message-ID: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It would be helpful to support a short syntax for importing unqualified identifiers while establishing a short qualified name. An example of the proposed syntax is, {{{#!hs import Data.Map (Map) as M }}} The desired semantics are that `Map` be imported unqualified, and `M` be defined as an alias for `Data.Map`. This replaces the existing convention of writing, {{{#!hs import Data.Map (Map) import qualified Data.Map as M }}} The proposed syntax is currently an error, I think, so adding support for it should not break anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 01:09:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 01:09:07 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.3c87d50e8855392a11f528aca24e0823@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by acowley): I had forgotten about the existing `import Data.Map as M` syntax. So this request, as it stands, is not backwards compatible. Nonetheless, a way of collapsing the two import lines into one would be appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 01:18:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 01:18:53 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.51809228a527a1dd10a5bf31495d3922@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.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 Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): The `xchg` issue above was fixed in git commit f6ca6959e54ede0b28735ab7e011c16b3cb172db. Running `inplace/bin/ghc-stage2 +RTS -Da` under GDB now results in: {{{ ..... stg_ap_pppv_ret... FUN/4(0x7fb46fcc28) stg_ap_0_ret... FUN/4(0x7fb46fcc28) stg_ap_pppv_ret... FUN/4(0x7fb46fcc28) stg_ap_0_ret... FUN/4(0x7fb46fcc28) stg_ap_pppv_ret... FUN/4(0x7fb46fcc28) stg_ap_0_ret... FUN/4(0x7fb46fcc28) stg_ap_pppv_ret... FUN/4(0x7fb46fcc28) stg_ap_0_ret... FUN/4(0x7fb46fcc28) stg_ap_pppv_ret... FUN/4(0x7fb46fcc28) stg_ap_0_ret... FUN/4(0x7fb46fcc28) stg_ap_pppv_ret... FUN/4(0x7fb46fcc28) [New Thread 0x7fb39ff1f0 (LWP 25080)] stg_ap_v_ret... FUN/1(0x7fb47b8c78, 0x7fb3a041b9, 0x7fb3a05448, 0x7fb3a084c8 , 0x7fb3a084d8, 0x7fb3e96861, 0x7fb3a08558, (nil)d#, (nil)d#, 0x1fd#, 0x4d# , 0x5d#, 0x6d#) stg_ap_0_ret... base:GHC.Event.Manager.Created() Program received signal SIGSEGV, Segmentation fault. 0x0000007fb3dac244 in stg_ap_p_fast$def () from /home/erikd/ghc- upstream/rts/ dist/build/libHSrts_thr_debug-ghc7.11.20150602.so (gdb) bt #0 0x0000007fb3dac244 in stg_ap_p_fast$def () from /home/erikd/ghc- upstream/ rts/dist/build/libHSrts_thr_debug-ghc7.11.20150602.so Backtrace stopped: previous frame identical to this frame (corrupt stack?) }}} By hacking on `utils/genapply/GenApply.hs` I was able to add some more debug to the generated file `rts/dist/build/AutoApply.cmm` so that the generaed code for `stg_ap_pv_fast` looks like: {{{ stg_ap_pv_fast { W_ info; W_ arity; W_ xxxx; if (GETTAG(R1)==2) { Sp_adj(0); jump %GET_ENTRY(R1-2) [R1,R2]; } #ifdef PROFILING if (Sp - WDS(3) < SpLim) { Sp_adj(-2); W_[Sp+WDS(1)] = R2; Sp(0) = stg_ap_pv_info; jump __stg_gc_enter_1 [R1]; } #else if (Sp - WDS(2) < SpLim) { Sp_adj(-2); W_[Sp+WDS(1)] = R2; Sp(0) = stg_ap_pv_info; jump __stg_gc_enter_1 [R1]; } #endif R1 = UNTAG(R1); info = %GET_STD_INFO(R1); IF_DEBUG(apply,foreign "C" debugBelch("genApplyFast before\n");); xxxx = TO_W_(%INFO_TYPE(info)); IF_DEBUG(apply,foreign "C" debugBelch("genApplyFast after\n");); switch [INVALID_OBJECT .. N_CLOSURE_TYPES] (xxxx) { .... }}} With thjis debug the backtrace in GDB now looks like: {{{ stg_ap_0_ret... FUN/4(0x7fb46fcc28) stg_ap_pppv_ret... FUN/4(0x7fb46fcc28) [New Thread 0x7fb39ff1f0 (LWP 25080)] stg_ap_v_ret... FUN/1(0x7fb47b8c78, 0x7fb3a041b9, 0x7fb3a05448, 0x7fb3a084c8 , 0x7fb3a084d8, 0x7fb3e96861, 0x7fb3a08558, (nil)d#, (nil)d#, 0x1fd#, 0x4d# , 0x5d#, 0x6d#) stg_ap_0_ret... base:GHC.Event.Manager.Created() genApplyFast before genApplyFast after genApplyFast before Program received signal SIGSEGV, Segmentation fault. 0x0000007fb3dac244 in stg_ap_p_fast$def () from /home/erikd/ghc- upstream/rts/ dist/build/libHSrts_thr_debug-ghc7.11.20150602.so }}} suggesting it is segfaulting on the line: {{{ xxxx = TO_W_(%INFO_TYPE(info)); }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 01:32:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 01:32:26 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.13e52811ec8636e4e89ee6496f758f86@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #1241, #2247, | Blocking: #8356, #9103, #9227 | Differential Revisions: Phab:D69 -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:59 atnnn]: > What is the status of this feature? > > I ran into another case where it might be useful: > > {{{#!hs > {-# LANGUAGE FunctionalDependencies, FlexibleInstances, > UndecidableInstances, ConstraintKinds, GADTs #-} > > class F a | -> a > instance (eq ~ (a ~ ()), eq) => F a > }}} I guess this is a reduction of some more non-trivial instance declaration? Otherwise one could just write `instance (a ~ ()) => F a`, and this is accepted by GHC. > GHC considers this illegal, but in practice it satisfies the functional dependency. In principle it looks to be a bug that GHC does not accept your program already, and it would continue to be a bug even if `DysfunctionalDependencies` was added; but in practice obscure fundep- related bugs are not always fixed quickly. Still, I think you should probably file this as a separate ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 01:49:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 01:49:08 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.360f8940a367c9927336bc051b4d0fbf@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #1241, #2247, | Blocking: #8356, #9103, #9227 | Differential Revisions: Phab:D69 -------------------------------------+------------------------------------- Comment (by rwbarton): Some thoughts upon returning to this ticket after a long time. * Is there a wiki page or similar describing the meaning of functional dependencies under `DysfunctionalDependencies`? I think I understand the meaning in the case of `class C a b | a -> b`: I think the condition is that for any type `a0`, there is at most one ''instance declaration'' `instance C a[vs] b[vs]` for which `a[vs]` unifies with `a0`, but this unification may not fully determine `b[vs]`. But I don't know what it means to write a dysfunctional dependency like `class C a b c | a -> b`. How does that differ from the dependency `a c -> b`? * Would adding `DysfunctionalDependencies` get in the way of some day desugaring functional dependencies into type families, and removing the fundep solver code? (Is this likely to ever happen anyways?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 02:21:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 02:21:44 -0000 Subject: [GHC] #10476: Wrong ar during cross-compilation In-Reply-To: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> References: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> Message-ID: <061.a577653601e687e89bf5fd2ede6ac45f@haskell.org> #10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: cross- Operating System: MacOS X | compiling Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * os: Unknown/Multiple => MacOS X Comment: Aaaaaa never mind... from `configure.ac`: {{{ if test "x$OS_STAGE0" != "xOSDarwin"; then BOOTSTRAPPING_GHC_INFO_FIELD([AR_STAGE0],[ar command]) BOOTSTRAPPING_GHC_INFO_FIELD([AR_OPTS_STAGE0],[ar flags]) BOOTSTRAPPING_GHC_INFO_FIELD([ArSupportsAtFile_STAGE0],[ar supports at file]) else AR_STAGE0='$(AR)' AR_OPTS_STAGE0='$(AR_OPTS)' ArSupportsAtFile_STAGE0='$(ArSupportsAtFile)' fi }}} This certainly explains your problem (since you are on Darwin)... git blame points to 24746fe78024a1edab843bc710c79c55998ab134. I wonder if it is okay to remove this hack by now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 02:22:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 02:22:02 -0000 Subject: [GHC] #10476: Wrong ar during cross-compilation In-Reply-To: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> References: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> Message-ID: <061.5044d9d33a623b2230c3e78e85d2a109@haskell.org> #10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: cross- Operating System: MacOS X | compiling Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 03:03:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 03:03:09 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.611b86504e9e4b96ad9c56a23058de6d@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #1241, #2247, | Blocking: #8356, #9103, #9227 | Differential Revisions: Phab:D69 -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:62 rwbarton]: > * Is there a wiki page or similar describing the meaning of functional dependencies under `DysfunctionalDependencies`? I think I understand the meaning in the case of `class C a b | a -> b`: I think the condition is that for any type `a0`, there is at most one ''instance declaration'' `instance C a[vs] b[vs]` for which `a[vs]` unifies with `a0`, but this unification may not fully determine `b[vs]`. But I don't know what it means to write a dysfunctional dependency like `class C a b c | a -> b`. How does that differ from the dependency `a c -> b`? My understanding of `DysfunctionalDependencies` is much, much simpler: just omit the check that takes place at instance declarations. For example, the following would be accepted: {{{ class Terrible a b | a -> b instance Terrible Int Bool instance Terrible Int Char }}} Now, suppose we have {{{ foo :: Terrible a b => a -> b foo = undefined }}} and we call `show (foo (5 :: Int))`. GHC has to figure out what type the argument to `show` has so it can supply the right `Show` instance. In this case, the type inferred for `foo (5 :: Int)` will either be `Bool` or `Char`, depending on the whims of GHC at the moment. They're called dysfunctional for a reason! Nevertheless, they can be useful if the user is careful to construct a set of instances that isn't terrible, but still doesn't meet the liberal coverage condition. Much like with `IncoherentInstances`, it's up to the user not to shoot themselves in the foot. > > * Would adding `DysfunctionalDependencies` get in the way of some day desugaring functional dependencies into type families, and removing the fundep solver code? (Is this likely to ever happen anyways?) This is a good point. The only reason I'm not against `DysfunctionalDependencies` is that I know functional dependencies don't make it into Core, and so you can't use this feature to write `unsafeCoerce`. But if we did desugar functional dependencies into something that does exist in Core, `DysfunctionalDependencies` would be in deep water. Is this a reason to avoid writing the feature? Perhaps. It certainly gives me pause when thinking about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 04:28:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 04:28:14 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.50d6c336f72aa7863259580cb6515a85@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.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 Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): With the help of @rwbarton got the disassembly around the crash site: {{{ (gdb) disass 0x0000007fb3dac244 Dump of assembler code for function stg_ap_p_fast$def: 0x0000007fb3dac1d8 <+0>: mov x24, x20 0x0000007fb3dac1dc <+4>: and x8, x22, #0x7 0x0000007fb3dac1e0 <+8>: cmp x8, #0x1 0x0000007fb3dac1e4 <+12>: b.ne 0x7fb3dac1f8 0x0000007fb3dac1e8 <+16>: ldr x8, [x22,#-1] 0x0000007fb3dac1ec <+20>: mov x20, x24 0x0000007fb3dac1f0 <+24>: blr x8 0x0000007fb3dac1f4 <+28>: ret 0x0000007fb3dac1f8 <+32>: sub x20, x24, #0x10 0x0000007fb3dac1fc <+36>: cmp x20, x28 0x0000007fb3dac200 <+40>: b.cs 0x7fb3dac220 0x0000007fb3dac204 <+44>: str x23, [x24,#-8] 0x0000007fb3dac208 <+48>: adrp x8, 0x7fb3dc0000 0x0000007fb3dac20c <+52>: ldr x8, [x8,#424] 0x0000007fb3dac210 <+56>: str x8, [x24,#-16]! 0x0000007fb3dac214 <+60>: mov x20, x24 0x0000007fb3dac218 <+64>: bl 0x7fb3da32a8 <__stg_gc_enter_1$def> 0x0000007fb3dac21c <+68>: ret 0x0000007fb3dac220 <+72>: and x22, x22, #0xfffffffffffffff8 0x0000007fb3dac224 <+76>: adrp x25, 0x7fb3dbf000 0x0000007fb3dac228 <+80>: ldr x25, [x25,#1584] 0x0000007fb3dac22c <+84>: ldr x26, [x22] 0x0000007fb3dac230 <+88>: ldr w8, [x25,#224] 0x0000007fb3dac234 <+92>: cbz w8, 0x7fb3dac244 0x0000007fb3dac238 <+96>: adrp x0, 0x7fb3dbe000 0x0000007fb3dac23c <+100>: add x0, x0, #0x20 0x0000007fb3dac240 <+104>: bl 0x7fb3d7439c => 0x0000007fb3dac244 <+108>: ldrsw x26, [x26,#-8] 0x0000007fb3dac248 <+112>: ldr w8, [x25,#224] }}} which shows the crash on the instruction `ldrsw x26, [x26,#-8]`: {{{ (gdb) info registers x0 0x0 0 x1 0x0 0 x2 0x1 1 x3 0x0 0 x4 0x0 0 x5 0x0 0 x6 0xffffffbb 4294967227 x7 0x0 0 x8 0x40 64 x9 0x0 0 x10 0xffffffff 4294967295 x11 0x1 1 x12 0x7fb4591428 548486583336 x13 0x12 18 x14 0x7fb3a09fff 548474494975 x15 0x2 2 x16 0x7fb3dc0250 548478386768 x17 0x7fb3c329f4 548476758516 x18 0x7fffffa790 549755791248 x19 0x7fb3dc4998 548478405016 x20 0x7fb3a051c8 548474474952 x21 0x7fb3a092b0 548474491568 x22 0x7fb3dc4998 548478405016 x23 0x7fb3a09291 548474491537 x24 0x7fb3a051d8 548474474968 x25 0x7fb3dc4578 548478403960 x26 0x0 0 x27 0x0 0 x28 0x7fb3a050c0 548474474688 x29 0x7fffffead0 549755808464 x30 0x7fb3dac244 548478304836 sp 0x7fffffaa30 0x7fffffaa30 pc 0x7fb3dac244 0x7fb3dac244 cpsr 0x60000000 1610612736 fpsr 0x0 0 fpcr 0x0 0 }}} and register `x26` is `0x0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 05:26:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 05:26:54 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.77633f8f597e556f83788f7d96f01730@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by puffnfresh): I'm going to try and start submitting data when I hit this bug. Here is a diff of the Data.ByteString.Interal interface which I had built locally vs the one in Nix's cached GHC: https://gist.github.com/puffnfresh/fe3c86baf416114ef644#file-local-vs- cached-diff There seems to be some slightly different strictness and unfolding. The full files are included in that gist, in case they help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 05:52:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 05:52:16 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize In-Reply-To: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> References: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> Message-ID: <057.c5f9635f633fc48dad5838a72d0de4b3@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by archblob): * cc: simonmar (added) Comment: I think you are right about GHC 7.6.3 I can't see from the code how this worked then. I have a patch that validates but I'm not sure if it's the best approach, here it goes: In https://github.com/ghc/ghc/blob/master/rts/Threads.c#L589, it seems that when we allocate a new chunk, the `chunk_size` is always `RtsFlags.GcFlags.stkChunkSize` at a minimum even though alone or together with the old stack size this will be above the limit set by -K, so the fix is that if that limit is set we don't, because we know the max that we are allowed to allocate. Now what I don't know is if we should always allocate a minimum of `stkChunkSize` and why? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 06:06:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 06:06:21 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize In-Reply-To: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> References: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> Message-ID: <057.1f08a6f5c8c17eec3da8fa9a170f09c4@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D938 -------------------------------------+------------------------------------- Changes (by archblob): * differential: => Phab:D938 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 06:43:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 06:43:01 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize In-Reply-To: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> References: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> Message-ID: <057.06c956ce2e5ab74b2caac0f4530c676d@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by archblob): * differential: Phab:D938 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 06:43:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 06:43:42 -0000 Subject: [GHC] #8435: Do not copy stack after stack overflow In-Reply-To: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> References: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> Message-ID: <060.7e5bf45922224eb1d16f77b0d3daf8ac@haskell.org> #8435: Do not copy stack after stack overflow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D938 -------------------------------------+------------------------------------- Changes (by archblob): * differential: => Phab:D938 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 07:25:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 07:25:09 -0000 Subject: [GHC] #10479: Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh Message-ID: <045.1ef1ca690686af7d2265216e3878b27c@haskell.org> #10479: Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Package | Version: 7.10.1 system | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D922 | -------------------------------------+------------------------------------- The GHC version of https://github.com/haskell/cabal/issues/2437 ; we need to adapt ghc-cabal to use the correct install paths. I have an in-flight patch, see the Phabricator. However, applying the change to HEAD is blocked by https://github.com/haskell/cabal/issues/2638 since there are some Cabal changes, which necessitate updating to Cabal head. Cabal maintainers have expressed interest in this being merged into 7.10. To do this, we first have to merge the Cabal change into the 7.10 branch of Cabal, and apply the differential to GHC 7.10. (We shouldn't be blocked by the Cabal HEAD changes as those are not on the 7.10 branch.) If 7.10 release managers agree to let this patch in I volunteer to coordinate the changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 07:28:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 07:28:58 -0000 Subject: [GHC] #10480: Ship Cabal with Windows filepath fix Message-ID: <045.437e09638d10b0a54f88e3ea0078e353@haskell.org> #10480: Ship Cabal with Windows filepath fix -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries | Version: 7.10.1 (other) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It would be good to ship a version of Cabal which has this bug fixed: https://github.com/haskell/cabal/issues/2502 Milestoning so we don't forget. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 08:20:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 08:20:18 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.f64cc147bef82aa5348b3f2396907a79@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fuuzetsu): Austin, is there a reason why we're punting to 7.12? Joachim's patch doesn't affect the main complaint I had with 7.10 which was the pure/return specialisation stuff. I even said above >But I also don't want to hold up any other fixes. I wish only to not end up in a situation where the final 7.10.x is released and to get much else in we have to wait for 7.12. As long as it's fixed in 7.10 somewhere, I'm happy. To us (nix), it's really not acceptable that we have to daily tell users to delete their packages and just try again praying that this time around something more consistent comes up. puffnfresh, yes, great, very useful, big part of this ticket as a whole is to even find out what breaks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 08:42:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 08:42:41 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.163253997c0c7fa0f13646688f2bff01@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #1241, #2247, | Blocking: #8356, #9103, #9227 | Differential Revisions: Phab:D69 -------------------------------------+------------------------------------- Comment (by simonpj): > Is there a wiki page or similar describing the meaning of functional dependencies under `DysfunctionalDependencies`? See the end of comment:14. This stuff needs to end up in the user manual though. It's a simple, easily-specified change. I don't think we should hold it up because of a vague aspiration to implement fundeps in terms of type families; I'm sure there will be lots of ''other'' wrinkles to that. I would much prefer it done as a '''per-instance''' pragma, since we now have the technology to do that, rather than as a module-wide pragma. All it needs is for someone to do it. I'm happy to advise. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 08:50:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 08:50:15 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.2e36330ab2c5d747af5f30e4d85b320b@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Fuuzetsu: see comment:83. It's just lack of a volunteer to actually dig into this and fix it. We can just hold up 7.10.2 until a volunteer appears, or until I get free enough to do it. Or we can push 7.10.2 out regardless (current plan). Open source projects are like this: they rely heavily on volunteers. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 08:55:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 08:55:06 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.124749c2d404b1633871fcc889ada375@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: high => highest * status: new => merge Comment: Let's see if Austin can merge that big patch in comment:22 to 7.10.2, if that does actually fix the problems you are having. That said, I'm not finished with this ticket. I had to park it for a while, but I know that the solution is incomplete and am working on making it better. Still, I think the above patch is a big improvement. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 08:56:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 08:56:23 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.928c0bf0595986925dd56b953119fe0d@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.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 Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): At @rwbarton's suggestion, compiled this program {{{ main = print $ foldl (+) 0 [1..10000000] }}} with `ghc-stage1 -O0` (to thrash the GC) and the resulting program ran correctly. The problem does not seem to be GC related. Can also compile this program with {{{ inplace/bin/ghc-stage1 -O0 -dynamic hello.hs -o hello }}} and that too runs fine so this is unlikely to be dynamic library loading. Running `inplace/bin/ghc-stage2 +RTS -Ds` results in: {{{ 7fb3bc9000: created capset 0 of type 2 7fb3bc9000: created capset 1 of type 3 7fb3bc9000: cap 0: initialised 7fb3bc9000: assigned cap 0 to capset 0 7fb3bc9000: assigned cap 0 to capset 1 7fb3bc9000: allocated 1 more capabilities 7fb3bc9000: new task (taskCount: 1) 7fb3bc9000: returning; I want capability 0 7fb3bc9000: resuming capability 0 7fb3bc9000: cap 0: created thread 1 7fb3bc9000: new bound thread (1) 7fb3bc9000: cap 0: schedule() 7fb3bc9000: cap 0: running thread 1 (ThreadRunGHC) 7fb3bc9000: cap 0: created thread 2 7fb3bc9000: cap 0: thread 1 stopped (yielding) 7fb3bc9000: giving up capability 0 7fb3bc9000: starting new worker on capability 0 7fb3bc9000: new worker task (taskCount: 2) 7fb39ff1f0: cap 0: schedule() 7fb39ff1f0: cap 0: running thread 2 (ThreadRunGHC) 7fb39ff1f0: cap 0: thread 2 stopped (yielding) 7fb39ff1f0: giving up capability 0 7fb39ff1f0: passing capability 0 to bound task 0x7fb3bc9000 7fb3bc9000: woken up on capability 0 7fb3bc9000: resuming capability 0 7fb3bc9000: cap 0: running thread 1 (ThreadRunGHC) Segmentation fault (core dumped) }}} so the crash happens right after it switches threads. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 09:09:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 09:09:11 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.907b8c0843b053ac90b5e01c07fd39e6@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.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 Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): Had a further (at least 3rd or 4th) look at the Aarch64 version of the `StgRun` function in `rts/StgCRun.c`. I noticed that some some of the registers that are pushed and popped on/off the stack were not listed in the "clobbered registers" part of the `__asm__` definition. Came up with this patch: {{{ commit 5f75cbcea67cbb587a7d640f6241469744ab026f Author: Erik de Castro Lopo Date: Wed Jun 3 05:54:23 2015 +0000 rts: Fix clobbered registers list in aarch64 StgRun diff --git a/rts/StgCRun.c b/rts/StgCRun.c index 02ec532..46d7f11 100644 --- a/rts/StgCRun.c +++ b/rts/StgCRun.c @@ -820,8 +820,14 @@ StgRun(StgFunPtr f, StgRegTable *basereg) { : "=r" (r) : "r" (f), "r" (basereg), "i" (RESERVED_C_STACK_BYTES) - : "%x19", "%x20", "%x21", "%x22", "%x23", "%x24", "%x25", "%x26", "%x27", "%x28", - "%x16", "%x17", "%x30" + + : "%x16", "%x17", /* Exclude %r18 (platform/temporary register) */ + "%x19", "%x20", "%x21", "%x22", "%x23", "%x24", "%x25", + "%x26", "%x27", "%x28", /* Exclude %x29 (frame pointer) */ + "%x30", + "%d8", "%d9", "%d10", "%d11", "%d12", "%d13", "%d14" + + ); return r; } }}} The stage2 compiler still segfaults, but comparing the `inplace/bin/ghc- stage2 +RTS -Da` output showed that with the above patch the program got a lot further before segfaulting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 09:47:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 09:47:19 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.d709cf7ce161173aa5ba77abf9b3ec85@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.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 Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): With the above patch to `StgRun`, the new backtrace in GDB looks like: {{{ ghc-stage2: internal error: invalid closure, info=(nil) (GHC version 7.11.20150602 for aarch64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. 0x0000007fb3c009b8 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/ linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x0000007fb3c009b8 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/ sysv/linux/raise.c:56 #1 0x0000007fb3c01cc0 in __GI_abort () at abort.c:89 #2 0x0000007fb3d74628 in rtsFatalInternalErrorFn (s=0x7fb3dbb820 "invalid closure, info=%p", ap=...) at rts/RtsMessages.c:170 #3 0x0000007fb3d74140 in barf (s=0x7fb3dbb820 "invalid closure, info=%p") at rts/RtsMessages.c:42 #4 0x0000007fb3d92740 in evacuate1 (p=0x7fb3aad560) at rts/sm/Evac.c:384 #5 0x0000007fb3d8392c in scavenge_block1 (bd=0x7fb3a02b40) at rts/sm/Scav.c:464 #6 0x0000007fb3d85df4 in scavenge_find_work () at rts/sm/Scav.c:2009 #7 0x0000007fb3d85f98 in scavenge_loop1 () at rts/sm/Scav.c:2085 #8 0x0000007fb3d8d980 in scavenge_until_all_done () at rts/sm/GC.c:977 #9 0x0000007fb3d8c334 in GarbageCollect (collect_gen=0, do_heap_census=rtsFalse, gc_type=2, cap=0x7fb3dc4980 ) at rts/sm/GC.c:396 #10 0x0000007fb3d608bc in scheduleDoGC (pcap=0x7fffffec88, task=0x5151c0, force_major=rtsFalse) at rts/Schedule.c:1674 #11 0x0000007fb3d5ed8c in schedule (initialCapability=0x7fb3dc4980 , task=0x5151c0) at rts/Schedule.c:557 #12 0x0000007fb3d61ab4 in scheduleWaitThread (tso=0x7fb3a0b388, ret=0x0, pcap=0x7fffffee00) at rts/Schedule.c:2383 #13 0x0000007fb3d6349c in rts_evalLazyIO (cap=0x7fffffee00, p=0x4c36a0 , ret=0x0) at rts/RtsAPI.c:500 #14 0x0000007fb3d7b348 in hs_main (argc=2, argv=0x7ffffff018, main_closure=0x4c36a0 , rts_config=...) at rts/RtsMain.c:64 #15 0x00000000004bca48 in main () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 09:59:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 09:59:51 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.6e3ce97244086cd39beabbc3e0cf4bae@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Yuras): Note that currently the next is allowed: {{{#!haskell import Data.Map as M (Map) }}} Different semantics based on order of parens and `as` is too ambiguous and hard to remember IMO. Also, the existing convention to import data type unqualified and the rest qualified is some kind of a hack working around lack of nested namespaces. In the ideal world `Data.Map` should export functions qualified. Like the next: {{{#!haskell module Data.Map (Map, namespace Map) where data Map = ... namespace Map where length :: Map -> Int length ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 10:46:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 10:46:12 -0000 Subject: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module In-Reply-To: <046.ebf20f155e05760df4b4c62188044473@haskell.org> References: <046.ebf20f155e05760df4b4c62188044473@haskell.org> Message-ID: <061.c95c8d4ed80fb9dfb7893ec21898d8a7@haskell.org> #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T7672 Blocked By: | Blocking: 10336 Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7ea156ae3e1c66e59935f0eb877ea1a3f3bfd5b9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7ea156ae3e1c66e59935f0eb877ea1a3f3bfd5b9" Refactor RdrName.Provenance, to fix #7672 Trac #7672 has a data type T in module A that is in scope *both* locally-bound *and* imported (with a qualified) name. The Provenance of a GlobalRdrElt simply couldn't express that before. Now you can. In doing so, I flattened out Provenance into GlobalRdrElt, so quite a lot of modules are touched in a not-very-interesting way. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 11:21:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 11:21:33 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.0a48543570a05e035e43004b48c2a38b@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): It wasn't really clear to me that we were still aiming to fix that for 7.10.2. If you think it should be fixed here, then sure, we can just remilestone it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 11:51:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 11:51:07 -0000 Subject: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module In-Reply-To: <046.ebf20f155e05760df4b4c62188044473@haskell.org> References: <046.ebf20f155e05760df4b4c62188044473@haskell.org> Message-ID: <061.5701a9d7db2ab4587dda484fdd72a613@haskell.org> #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T7672 Blocked By: | Blocking: 10336 Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I've finally nailed this one. I thought it was going to be easy and just got sucked in. But I did lots of good clean-up along the way. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 12:00:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 12:00:59 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.e97c58067b86e90f0388164aab809a9a@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Also, just a random tidbit: the (excellent!) test in comment:76 can in fact be solved by simply compiling with `-fno-cse` - the nondeterministic ordering of bindings is the culprit in that case, and CSE chooses `return` or `pure` based on what shirt you're wearing. If determinism here is hurting NixOS, it may be preferrable to simply switch off CSE by default or always default to `-fno-cse` for every compilation. That sucks, but in the mean time it may help while we work towards a real fix (having a deterministic ordering for Uniques). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 13:13:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 13:13:27 -0000 Subject: [GHC] #10439: Opt_ImplicitImportQualified doesn't work for constructor field name In-Reply-To: <046.7eeda0ab82b2b7fc80cf5d3190f2c3b2@haskell.org> References: <046.7eeda0ab82b2b7fc80cf5d3190f2c3b2@haskell.org> Message-ID: <061.1ab198f41aac36ea83630f221cf5d897@haskell.org> #10439: Opt_ImplicitImportQualified doesn't work for constructor field name -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: patch Priority: highest | Milestone: 7.12.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Phab:D900 Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest * status: new => patch * milestone: => 7.12.1 Comment: I'm happy with the patch - thank you. Austin please land it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 13:48:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 13:48:46 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.5bb65d239262ea7737ab05df1f0428a1@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by malcolmw): Do you know if the commitdiff you referenced has made it into a ghc distro that I could play with? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 15:18:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 15:18:12 -0000 Subject: [GHC] #10480: Ship Cabal with Windows filepath fix In-Reply-To: <045.437e09638d10b0a54f88e3ea0078e353@haskell.org> References: <045.437e09638d10b0a54f88e3ea0078e353@haskell.org> Message-ID: <060.614bddeb6ab403f68540369157134070@haskell.org> #10480: Ship Cabal with Windows filepath fix -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries | Version: 7.10.1 (other) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): hackage:Cabal-1.22.3.0 good enough? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 15:38:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 15:38:38 -0000 Subject: [GHC] #10480: Ship Cabal with Windows filepath fix In-Reply-To: <045.437e09638d10b0a54f88e3ea0078e353@haskell.org> References: <045.437e09638d10b0a54f88e3ea0078e353@haskell.org> Message-ID: <060.3ebb86ca7d59d370d6c343e4b6ea1300@haskell.org> #10480: Ship Cabal with Windows filepath fix -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries | Version: 7.10.1 (other) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): No, the bug isn't even fixed in HEAD yet, sorry! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 15:51:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 15:51:11 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.2880a81bff4b1241b1854241f66212f9@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: lstrano Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by lstrano): * owner: => lstrano -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 16:03:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 16:03:22 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.13c0e53e3db011a01c97a58be67af952@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * milestone: => 7.10.2 Comment: The partial fix is a simple patch and we should consider putting it in 7.10.2. (re-milestoned) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 16:19:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 16:19:12 -0000 Subject: [GHC] #10311: package name returned from tyConPackage is garbled In-Reply-To: <049.befe981d27d5c4c24d07557f283ecb8b@haskell.org> References: <049.befe981d27d5c4c24d07557f283ecb8b@haskell.org> Message-ID: <064.9f75321ece5e87120db527163dd54af1@haskell.org> #10311: package name returned from tyConPackage is garbled -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 16:56:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 16:56:28 -0000 Subject: [GHC] #10460: Allow foreign prim to return Any In-Reply-To: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> References: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> Message-ID: <060.878d58b264f9c61218f315f380e281af@haskell.org> #10460: Allow foreign prim to return Any -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"cd9c5c6678e206ffcda955f66c26c7a4d89519c9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cd9c5c6678e206ffcda955f66c26c7a4d89519c9" Allow Any return in foreign prim, fixes #10460. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, goldfire, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D935 GHC Trac Issues: #10460 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 16:58:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 16:58:35 -0000 Subject: [GHC] #10460: Allow foreign prim to return Any In-Reply-To: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> References: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> Message-ID: <060.0e1272f4073d296e58fb8aae1f1a64ec@haskell.org> #10460: Allow foreign prim to return Any -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 17:41:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 17:41:07 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.9db8799aaeef2db6e3f9dd0b224894dc@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I'm in favor of abbreviating the syntax in this common scenario, but I don't like your choice of syntax, I'm afraid. It would give {{{ import Data.Map (Map) as M -- (1) }}} a very different meaning from {{{ import Data.Map as M (Map) -- (2) }}} (1) imports all of `Data.Map`, qualified with the alias `M`, and imports the name `Map` unqualified. (2) imports only the name `Map` (unqualified) while also aliasing `Data.Map`. Having these two coexist seems like we're asking users to be confused. What about {{{ import Data.Map (Map) qualified as M * }}} ? The general schema, which replaces the current syntax. This schema does not permit some current syntax, but it would be easy to extend it to be backward-compatible. I've chosen not to for this presentation to avoid clutter. {{{ import_statement ::= 'import' module_name maybe_name_list import_specifiers module_name ::= ... maybe_name_list ::= name_list | name_list ::= '(' names ')' | '*' import_specifiers ::= | import_specifier import_specifiers import_specifier ::= 'hiding' name_list | qualified_spec name_list qualified_spec ::= 'qualified' | 'qualified' 'as' name }}} The top-level `maybe_name_list` would list all unqualified imports. If it is omitted, and there are no `qualified_spec`s, then all names would be imported unqualified. If it is omitted and there are one or more `qualified_spec`s, then no names would be imported unqualified. Each `import_specifier` either adds qualified names (perhaps under a module synonym) or removes names. Removing names with `hiding` removes those names from the `qualified_spec` (or top-level `maybe_name_list`) immediately preceding the `hiding`. The special `name_list` `*` (note that it is ''not'' in parentheses, to avoid ambiguity) means "all names". This schema allows one import statement to import a mix of qualified and unqualified names, and even allows using different module synonyms for different sets of qualified names. The legacy `import` syntax could desugar to this form, which seems strictly more expressive. For example: {{{ import qualified Foo --> import Foo qualified * import qualified Bar as B --> import Bar qualified as B * import Baz hiding (wurble) --> import Baz hiding (wurble) }}} Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 17:55:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 17:55:23 -0000 Subject: [GHC] #9507: ghc-pkg mode to query by package-key In-Reply-To: <045.94e3570469ccb8429301ef11591de043@haskell.org> References: <045.94e3570469ccb8429301ef11591de043@haskell.org> Message-ID: <060.d18392fa4487dfa09f250444a00fe8d4@haskell.org> #9507: ghc-pkg mode to query by package-key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 18:18:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 18:18:46 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.95a149927bc72b1c113a74a9183d0d07@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 19:08:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 19:08:15 -0000 Subject: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module In-Reply-To: <046.ebf20f155e05760df4b4c62188044473@haskell.org> References: <046.ebf20f155e05760df4b4c62188044473@haskell.org> Message-ID: <061.b1b1ca5ec6c29a6d682d5fe1d3d475a1@haskell.org> #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: fixed | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T7672 Blocked By: | Blocking: 10336 Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: Thank you Simon! Marking as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 19:08:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 19:08:46 -0000 Subject: [GHC] #7746: Support loading/unloading profiled objects from a profiled executable In-Reply-To: <045.ca53cc09f11562f645334cf2f2e456a1@haskell.org> References: <045.ca53cc09f11562f645334cf2f2e456a1@haskell.org> Message-ID: <060.c73cb9e575f5fede8df48bb701a94e18@haskell.org> #7746: Support loading/unloading profiled objects from a profiled executable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: low | Milestone: ? Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 5435, 8039 | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * priority: normal => low * milestone: 7.12.1 => ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 19:09:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 19:09:44 -0000 Subject: [GHC] #9252: Generalize hs-boot files to be more like module signatures In-Reply-To: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> References: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> Message-ID: <060.5b0a919b09571ce5f303ed6c1f2c1680@haskell.org> #9252: Generalize hs-boot files to be more like module signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D130 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 19:10:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 19:10:13 -0000 Subject: [GHC] #9252: Generalize hs-boot files to be more like module signatures In-Reply-To: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> References: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> Message-ID: <060.7a4955c74da4cb0f60362b18726fae73@haskell.org> #9252: Generalize hs-boot files to be more like module signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D130 -------------------------------------+------------------------------------- Changes (by ezyang): * owner: ezyang => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 19:10:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 19:10:43 -0000 Subject: [GHC] #9252: Generalize hs-boot files to be more like module signatures In-Reply-To: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> References: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> Message-ID: <060.68870c0821cc46691e2368ce33749d32@haskell.org> #9252: Generalize hs-boot files to be more like module signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D130 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => invalid Comment: This part of the Backpack design is still in flux, so I'm going to mark this as invalid for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 19:11:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 19:11:55 -0000 Subject: [GHC] #9506: Name libraries (dll/so) separately from linker symbols In-Reply-To: <045.be873a58d95f2254770e54725ac4fac9@haskell.org> References: <045.be873a58d95f2254770e54725ac4fac9@haskell.org> Message-ID: <060.08c975daf9aff2e851f458d52f3d4b82@haskell.org> #9506: Name libraries (dll/so) separately from linker symbols -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: duplicate | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 10479 | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate * blockedby: => 10479 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 19:12:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 19:12:42 -0000 Subject: [GHC] #10266: Split base for Backpack In-Reply-To: <045.81e58b6e2b97dd039d014c76c016ea80@haskell.org> References: <045.81e58b6e2b97dd039d014c76c016ea80@haskell.org> Message-ID: <060.e74d1ed5deb6de80b45fdcb7b5f1d2d9@haskell.org> #10266: Split base for Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 19:43:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 19:43:30 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.ba682573f16b6248c404a32adea1b7b4@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): That commit isn't on the 7.10 branch. You could patch it into a local GHC build and see if it helps. > If, instead of having the main function in Haskell, we write a wrapper main function in C++, that calls the Haskell from a DLL (and the Haskell then calls back into C++), the bug does not happen. Hence, we surmise there is some ghc RTS initialisation that is specific to Windows, that deals with exception handling, and that is incorrect for certain versions of Windows. The only difference between these two setups is the `main()` function, which is pretty small (start with `hs_main`): https://phabricator.haskell.org/diffusion/GHC/browse/master/rts/RtsMain.c Really the only thing in there that looks remotely suspicious is the SEH stuff that was touched by 5200bdeb26c5ec98739b14b10fc8907296bceeb9, so that looks like the most likely suspect. It only does a setjmp/longjump, but perhaps that interacts badly with that particular version of MSVCRT. Or something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 19:58:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 19:58:10 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.bf7d9ac903737ea6cce0f7d9c89d9be7@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): @thoughtpolice: did you check that `-fno-cse` works around it? I thought it might be due to shortcutting rather than actual CSE. @Fuuzetsu we don't think there's a new regression in 7.10, but we think it is possibly more likely to happen due to the Applicative/Monad changes, because we often see `pure = return`. This triggers the condition in the second bullet point in the description. I'm actively trying to convince people to work on this, because it's important. (I might end up working on it myself if I can find time). But beyond temporary workarounds, it's very unlikely that anything will happen on the 7.10 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 20:02:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 20:02:56 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.da4ba06d097460718811d7fb61064221@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by puffnfresh): My gist also seems to suggest CSE is involved, right? I can reproduce comment:76 with 7.10 but with master I can not. I'd like to look into this more but I can't find anything easily reproducible with master. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 20:13:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 20:13:25 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.db4890c3230c8c3e520c22470e20a801@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Yes. I removed `shortOutIndirections` in `SimplCore`: {{{ diff --git a/compiler/simplCore/SimplCore.hs b/compiler/simplCore/SimplCore.hs index 0a2f8e4..95c5cce 100644 --- a/compiler/simplCore/SimplCore.hs +++ b/compiler/simplCore/SimplCore.hs @@ -667,7 +667,7 @@ simplifyPgmIO pass@(CoreDoSimplify max_iterations mode) -- -- ToDo: alas, this means that indirection-shorting does not happen at all -- if the simplifier does nothing (not common, I know, but unsavoury) - let { binds2 = {-# SCC "ZapInd" #-} shortOutIndirections binds1 } ; + let { binds2 = {-# SCC "ZapInd" #-} if True then binds1 else shortOutIndirections binds1 } ; -- Dump the result of this iteration dump_end_iteration dflags print_unqual iteration_no counts1 binds2 rules1 ; }}} Then I compiled the test in comment:76 with `-fno-cse` and observed the ABI difference went away. So killing CSE may get us a long way for NixOS I admit I tested this on GHC 7.10, and not the HEAD branch. Brian, you couldn't reproduce this on HEAD at all? I can double check this, but that somewhat surprises (and worries!) me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 20:28:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 20:28:05 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.894e59aa18e423091274baa59f677d9b@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by puffnfresh): Correct, I tried reproducing with HEAD about 3 weeks ago, then again yesterday but it's always consistent. I can still reproduce with 7.10.1, so yeah, it's a little worrying and would be awesome if you could check. My results are published here: https://gist.github.com/puffnfresh/5a841633f0dde81fe7d1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 20:39:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 20:39:14 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize In-Reply-To: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> References: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> Message-ID: <057.a8c2f82e0893fdf44010edb710af90b6@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D938 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch * differential: => Phab:D938 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 20:49:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 20:49:35 -0000 Subject: [GHC] #10476: Wrong ar during cross-compilation In-Reply-To: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> References: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> Message-ID: <061.8254c7a6d06c11c8fe0ab92ddf5c7369@haskell.org> #10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: cross- Operating System: MacOS X | compiling Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jakzale): Removing this hack seems to work for me (`ghc-stage1` gets compiled successfully). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 21:06:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 21:06:03 -0000 Subject: [GHC] #10270: inconsistent semantics of type class instance visibility outside recursive modules In-Reply-To: <046.f680b68172950f0c3de20daf82432978@haskell.org> References: <046.f680b68172950f0c3de20daf82432978@haskell.org> Message-ID: <061.a59757ad6b428579c4e5d3d3f8a9cd89@haskell.org> #10270: inconsistent semantics of type class instance visibility outside recursive modules -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9562 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 21:10:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 21:10:17 -0000 Subject: [GHC] #10294: Missing instances if compiling with -fplugin In-Reply-To: <046.47fd486c7f73b488b5247db11cbe3c48@haskell.org> References: <046.47fd486c7f73b488b5247db11cbe3c48@haskell.org> Message-ID: <061.121554caca9db962a30da75fd2bbe1c9@haskell.org> #10294: Missing instances if compiling with -fplugin -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: duplicate | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: 10420 | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate * blockedby: => 10420 Comment: Pretty sure this is a duplicate of #10420, which was reported later but has a proper diagnosis of the problem. But maybe we should put this test example into the test suite in any case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 21:46:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 21:46:15 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.3d1dfc46fe5865abd2ed022194df3288@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | ConstraintKinds, newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: ConstraintKinds => ConstraintKinds, newcomer Comment: For newcomer: see comment:10. Scroll to the bottom of the file `libraries /ghc-prim/GHC/Classes.hs`, and work your editor magic. Also update `testsuite/tests/polykinds/T10451.hs` and `testsuite/tests/polykinds/T10451.stderr`, and submit a patch to [wiki:Phabricator]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 3 23:00:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Jun 2015 23:00:22 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.afeeb69a2aacca4fedbc709a586ac9a7@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.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 Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): If I load this up in GDB and break at line 383 of file `rts/sm/Evac.c` when `q->header.info == 0x0` I see: {{{ (gdb) print q->header $8 = {info = 0x0} (gdb) print &(q->header.info) $9 = (const StgInfoTable **) 0x7fb3dc4618 }}} which suggests that the address of `q->header.info` is within the `MainCapability` struct which is just completely wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 01:15:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 01:15:37 -0000 Subject: [GHC] #10420: "Care with plugin imports" is wrong / orphan RULE visibility In-Reply-To: <045.0008d7bf15a6c184529405e4260be834@haskell.org> References: <045.0008d7bf15a6c184529405e4260be834@haskell.org> Message-ID: <060.2ef9dca2efb48083376cbd0227a92a7f@haskell.org> #10420: "Care with plugin imports" is wrong / orphan RULE visibility -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: plugins07 Blocked By: | Blocking: 10294 Related Tickets: | Differential Revisions: Phab:D950 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D950 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 01:39:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 01:39:14 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.c767367be2433e812cb21d35433c37e8@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Have checked that `arm_HOST_ARCH_PRE_ARMv7` is undefined on this ARMv7 machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 02:27:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 02:27:04 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.7a69e015dd3fa8196b48ac328ad4046d@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Rufflewind): Why not use `(..)` instead of `*`? It seems more consistent with Haskell's current syntax. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 02:41:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 02:41:34 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.fa6573636545cf9645bdecebf0e1cb79@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:5 Rufflewind]: > Why not use `(..)` instead of `*`? It seems more consistent with Haskell's current syntax. Sold. I like this much more than `*`. It was also suggested that `(..)` could be omitted if it were going to be the last item on the line. I'm happy with that suggestion, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 02:51:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 02:51:46 -0000 Subject: [GHC] #10481: raise# should have an open kind in its return type Message-ID: <049.c95a2960ea81fc257ca0a55576d368d7@haskell.org> #10481: raise# should have an open kind in its return type -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I noticed this while working on https://phabricator.haskell.org/D861. `error` has a wired-in type {{{#!hs error :: forall (a :: OpenKind). String -> a }}} and an implementation {{{#!hs error :: String -> a error s = raise# (errorCallException s) }}} But GHC will actually reject the definition of `error` if you check it against the wired-in type as `raise#` has a lifted kind. The only reason we can compile `base` is that open kinds cannot be expressed in Haskell source, so when GHC compiles `GHC.Err` it thinks `error` has a lifted kind, but for every other module it uses the wired-in type with an open kind. I'm marking this as low priority because I don't see how it could affect anyone outside of GHC developers, since open kinds aren't expressible in the source language. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 04:59:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 04:59:05 -0000 Subject: [GHC] #9507: ghc-pkg mode to query by package-key In-Reply-To: <045.94e3570469ccb8429301ef11591de043@haskell.org> References: <045.94e3570469ccb8429301ef11591de043@haskell.org> Message-ID: <060.d9905ed652ab5de96df355e41938d58b@haskell.org> #9507: ghc-pkg mode to query by package-key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D946 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D946 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 05:10:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 05:10:13 -0000 Subject: [GHC] #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode In-Reply-To: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> References: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> Message-ID: <059.2638138f76cff854dc6babb60524130c@haskell.org> #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #7867 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): The patches are pretty short; I think the real reason this ticket is stalled is because simonpj never signed off on errge's suggested implementation strategy; and in the meantime, it seems this bug has been routed around. Perhaps we should just apply simonpj's original suggestion (remove `[InstanceDec]` from `ClassI` and `FamilyI`) and call this bug fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 06:53:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 06:53:44 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.5e3ef4e1b3d326727c01cb23e18ed474@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rpaladugu1): You can remove the following message by opening the command prompt as administrator and doing the "ghc-pkg recache" in the C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib folder. It worked for me and the message was gone. WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:18:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:18:31 -0000 Subject: [GHC] #5316: Orphan instances strike again: ghc rejects a program at first but will accept it if you repeat the same compilation command In-Reply-To: <049.ebd3a457ade5e57cf3d04c19365ba1de@haskell.org> References: <049.ebd3a457ade5e57cf3d04c19365ba1de@haskell.org> Message-ID: <064.2c238ecb3096244e25c37fe6cb0f4df0@haskell.org> #5316: Orphan instances strike again: ghc rejects a program at first but will accept it if you repeat the same compilation command -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: closed Priority: low | Milestone: ? Component: Compiler | Version: 7.0.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 2182 | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate * blockedby: => 2182 Comment: I was reviewing orphan instance tickets, and I think this one was fixed by #2182; Simon's analysis is essentially the same. I can't actually test it on the test-case given because `System.Event.Manager` has changed since then. The one thing that you might find puzzling is the situation with optimization: but actually it is simple to explain: optimization simply means we might tug on more `ModIface`s because we have to process unfoldings, etc. With the fix for #2182, the orphan instances that are pulled in from this process are unaffected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:24:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:24:21 -0000 Subject: [GHC] #10385: Annotation restriction is not respected while generating Annotation via TH In-Reply-To: <046.a42873b06c4b8b607d6d3487710fdc0c@haskell.org> References: <046.a42873b06c4b8b607d6d3487710fdc0c@haskell.org> Message-ID: <061.b0f6836ced1f5118634cd4007f19fc35@haskell.org> #10385: Annotation restriction is not respected while generating Annotation via TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => alanz Comment: Alan, could you take a look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:24:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:24:35 -0000 Subject: [GHC] #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode In-Reply-To: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> References: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> Message-ID: <059.980fa80524aa306f62bcc71086e6e347@haskell.org> #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #7867 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by errge): Replying to [comment:10 ezyang]: > The patches are pretty short; I think the real reason this ticket is stalled is because simonpj never signed off on errge's suggested implementation strategy; and in the meantime, it seems this bug has been routed around. Perhaps we should just apply simonpj's original suggestion (remove `[InstanceDec]` from `ClassI` and `FamilyI`) and call this bug fixed. No, I would like to strongly ask you not to do that. As I mentioned before in the bug report, I depend on the functionality to look up instance declarations for classes. If this info were to be removed, then there would be no way for me to continue to support the HFlags library after 7.12. As can be seen in the history of the ticket in comment 5 I have a patch which keeps the functionality in a very careful way (doesn't cause any accidental slowness for people who don't want to use it). It's also easy to understand from the user's point of view: looking up instances is expensive so you have to call it explicitly if you ever want it. I'm prepared to rebase that patch and fix up the test suite, if I get some agreement from a maintainer with actual commit rights that the idea is acceptable. Of course, this is not a blank cheque, I would still have to provide quality code, but not willing to work a lot again on this just so that you guys drop this without ever replying or discussing with me for 14 months. I remember prioritizing this work over my other commitments exactly so it doesn't stall and keeps moving, but no one cared. Sorry for the harsh words, I can of course totally understand that for everyone else the contribution time is already thin and very valuable; this is why what I'm looking for is an agreement on goals and designs before anyone (you or me) has to invest serious time and effort on either side. I'm also open to other implementation ideas, but I seriously depend on this feature so would like to ask you guys to keep it on in some form. Thanks and sorry for the long comment! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:29:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:29:01 -0000 Subject: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections In-Reply-To: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> References: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> Message-ID: <060.d49ac5f774658c4e721274d0eac866b9@haskell.org> #7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * cc: simonmar (added) * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:30:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:30:02 -0000 Subject: [GHC] #10385: Annotation restriction is not respected while generating Annotation via TH In-Reply-To: <046.a42873b06c4b8b607d6d3487710fdc0c@haskell.org> References: <046.a42873b06c4b8b607d6d3487710fdc0c@haskell.org> Message-ID: <061.e522f958b3a2f3d77ec614495b759059@haskell.org> #10385: Annotation restriction is not respected while generating Annotation via TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by alanz): I could look, but it is outside my area of expertise. There are two different kinds of Annotations in GHC, the API Annotations which I brought in, and these ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:32:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:32:08 -0000 Subject: [GHC] #10468: debug test case fails on Windows In-Reply-To: <045.b19678979c06629a2acceac03a72cd6b@haskell.org> References: <045.b19678979c06629a2acceac03a72cd6b@haskell.org> Message-ID: <060.a75e94251a2eabe2ad109ad9d9292866@haskell.org> #10468: debug test case fails on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: scpmw Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Debugging) | Keywords: Resolution: | Architecture: Operating System: Windows | Unknown/Multiple Type of failure: None/Unknown | Test Case: debug Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch Comment: Not qualified to review the patch, but looks reasonable to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:35:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:35:00 -0000 Subject: [GHC] #10467: user's guide description of "foreign export" is out of date In-Reply-To: <047.ce62d536f877089b14fe11348144e797@haskell.org> References: <047.ce62d536f877089b14fe11348144e797@haskell.org> Message-ID: <062.216286bf520d214902af074292a7fdae@haskell.org> #10467: user's guide description of "foreign export" is out of date -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Relevant commit: {{{ commit 7b0ff1792d699ff02a604163c9ccf4a98a1ca3eb Author: Simon Marlow Date: Mon Jan 31 10:32:24 2011 +0000 Merge _stub.o files into the main .o file (Fixes #3687 and #706) Now GHC still generates the _stub.c files, but the object file is automatically merged into the main .o file for a module. This means that build systems (including GHC's own) no longer need to worry about looking for _stub.o files and including them when linking. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:38:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:38:51 -0000 Subject: [GHC] #10467: user's guide description of "foreign export" is out of date In-Reply-To: <047.ce62d536f877089b14fe11348144e797@haskell.org> References: <047.ce62d536f877089b14fe11348144e797@haskell.org> Message-ID: <062.da29d14614f44b43a38ea48976fc5358@haskell.org> #10467: user's guide description of "foreign export" is out of date -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D951 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D951 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:40:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:40:53 -0000 Subject: [GHC] #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports In-Reply-To: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> References: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> Message-ID: <060.03198dabaa0c611b07ecab4ec9fe4c34@haskell.org> #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | 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: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:44:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:44:32 -0000 Subject: [GHC] #10420: "Care with plugin imports" is wrong / orphan RULE visibility In-Reply-To: <045.0008d7bf15a6c184529405e4260be834@haskell.org> References: <045.0008d7bf15a6c184529405e4260be834@haskell.org> Message-ID: <060.4f7e0c3e13623199fa044537f66dba51@haskell.org> #10420: "Care with plugin imports" is wrong / orphan RULE visibility -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: plugins07 Blocked By: | Blocking: 10294 Related Tickets: | Differential Revisions: Phab:D950 -------------------------------------+------------------------------------- Changes (by ezyang): * priority: low => normal Comment: Marking higher since this can affect non-orphan instances too, see #10294 for an example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:46:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:46:10 -0000 Subject: [GHC] #10441: msys native python testsuite support doesn't work in some situations In-Reply-To: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> References: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> Message-ID: <060.0e91be0c5f377a51788ebf483bbded0a@haskell.org> #10441: msys native python testsuite support doesn't work in some situations -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): If old msys is doing some terrible quoting, but new msys does not, can we just error if someone tries to use an old msys? I looked at the changelog for msys but didn't see anything that indicated that the heuristic changed. I see no documentation anywhere on the net about the heuristic. This makes me very grumpy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:47:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:47:39 -0000 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images In-Reply-To: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> References: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> Message-ID: <059.a9fde3b037d01392795da564894dbf76@haskell.org> #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Documentation | Milestone: 7.10.2 Resolution: | Version: 7.10.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:49:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:49:56 -0000 Subject: [GHC] #10408: The behavior of -ignore-dot-ghci and -ghci-script are weird In-Reply-To: <046.9a385a1c8826dd0a905fd10c48159e27@haskell.org> References: <046.9a385a1c8826dd0a905fd10c48159e27@haskell.org> Message-ID: <061.ab4da92792878373ab88fbf8c637c765@haskell.org> #10408: The behavior of -ignore-dot-ghci and -ghci-script are weird -------------------------------------+------------------------------------- Reporter: watashi | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Phab:D887 Related Tickets: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: No, it was fixed in {{{ commit 3ef7fcedfa1ad47968ca5fa107d51a6ab7051ed7 Author: Zejun Wu Date: Thu May 14 10:56:51 2015 -0500 Do not check dir perms when .ghci doesn't exist }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:54:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:54:36 -0000 Subject: [GHC] #10386: Documentation for -Wall is wrong In-Reply-To: <045.232d0261c427e0e77548f09249f01d5e@haskell.org> References: <045.232d0261c427e0e77548f09249f01d5e@haskell.org> Message-ID: <060.0fa9e302a4e2fd15cf6e061cc4705594@haskell.org> #10386: Documentation for -Wall is wrong -------------------------------------+------------------------------------- Reporter: AlexET | Owner: AlexET Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D889 -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:54:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:54:51 -0000 Subject: [GHC] #10386: Documentation for -Wall is wrong In-Reply-To: <045.232d0261c427e0e77548f09249f01d5e@haskell.org> References: <045.232d0261c427e0e77548f09249f01d5e@haskell.org> Message-ID: <060.360820a5b95f65a223ede844c3fb5b9f@haskell.org> #10386: Documentation for -Wall is wrong -------------------------------------+------------------------------------- Reporter: AlexET | Owner: AlexET Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D889 -------------------------------------+------------------------------------- Changes (by ezyang): * status: closed => merge * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 07:56:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 07:56:46 -0000 Subject: [GHC] #10330: Better Template Haskell error message locations In-Reply-To: <046.b93f0aedf54fe46703caa64d72521f0f@haskell.org> References: <046.b93f0aedf54fe46703caa64d72521f0f@haskell.org> Message-ID: <061.1cbe8d04025bbe1aab77393051dfdc80@haskell.org> #10330: Better Template Haskell error message locations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * cc: ezyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 08:06:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 08:06:08 -0000 Subject: [GHC] #9977: Nicer imports In-Reply-To: <045.95372b208ceb242d2c3dcf27f2958596@haskell.org> References: <045.95372b208ceb242d2c3dcf27f2958596@haskell.org> Message-ID: <060.cf1b68d22e73a28d2474fbbf381c369f@haskell.org> #9977: Nicer imports -------------------------------------+------------------------------------- Reporter: tolysz | Owner: Type: feature request | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 7.11 (Parser) | Keywords: imports Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * milestone: => ? Comment: Unfortunately, this proposal is completely incompatible with how layout rule works in Haskell today, which is that is triggered on a few special keywords. There is nothing of the sort here, so you would have to enforce layout through an alternate mechanism. I think it's unlikely that we'd accept this proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 08:07:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 08:07:30 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.ef7020dd76be8a53e9f26c4561398f7a@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D606 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 09:07:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 09:07:45 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.8c2f5e7f88af9cad9cf42b5c89cae8c8@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D606 -------------------------------------+------------------------------------- Comment (by simonpj): Could we have a perf test-case? T9872d is only a 7% swing and I'm sure we could make a more extreme version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 09:16:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 09:16:41 -0000 Subject: [GHC] #10481: raise# should have an open kind in its return type In-Reply-To: <049.c95a2960ea81fc257ca0a55576d368d7@haskell.org> References: <049.c95a2960ea81fc257ca0a55576d368d7@haskell.org> Message-ID: <064.da09b3edce06f37d4876309e6d2fe29b@haskell.org> #10481: raise# should have an open kind in its return type -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * priority: low => normal * milestone: => 7.12.1 Comment: No, it can affect anyone: {{{ {-# LANGUAGE MagicHash #-} module Foo where import GHC.Prim f :: Int -> Int# f x = raise# x }}} This wrongly yields {{{ Kind incompatibility when matching types: b0 :: * Int# :: # In the expression: raise# x In an equation for ?f?: f x = raise# x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 09:26:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 09:26:38 -0000 Subject: [GHC] #10482: Not enough unboxing happens on data-family function argument Message-ID: <043.b6b30783c65ab27e97e75d03aac8ab21@haskell.org> #10482: Not enough unboxing happens on data-family function argument -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In the following code, `foo` and `foo'` have isomorphic types, but the worker-wrapper pass does less unboxing for `foo`: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE TypeFamilies #-} module Foo where data family Foo a data instance Foo (a, b) = FooPair !(Foo a) !(Foo b) newtype instance Foo Int = Foo Int foo :: Foo ((Int, Int), Int) -> Int -> Int foo !f k = if k == 0 then 0 else if even k then foo f (k-1) else case f of FooPair (FooPair (Foo n) _) _ -> n data Foo0 a b c = Foo0 !(Foo1 a b) !c data Foo1 a b = Foo1 !a !b foo' :: Foo0 Int Int Int -> Int -> Int foo' !f k = if k == 0 then 0 else if even k then foo' f (k-1) else case f of Foo0 (Foo1 n _) _ -> n }}} The core generated by `ghc -ddump-simpl -O2 ww.hs` contains the following functions: {{{ Foo.foo_$s$wfoo [Occ=LoopBreaker] :: Foo Int -> Foo Int -> Foo.R:Foo(,) Int Int ~R# Foo (Int, Int) -> Foo Int -> GHC.Prim.Int# -> Int Foo.$wfoo [InlPrag=[0]] :: Foo (Int, Int) -> Foo Int -> GHC.Prim.Int# -> Int Foo.$wfoo' [InlPrag=[0], Occ=LoopBreaker] :: GHC.Prim.Int# -> Int -> Int -> GHC.Prim.Int# -> Int }}} The first argument of `Foo.foo_$s$wfoo` could be `Int#`, but it takes a boxed value. In practice this happens with unboxed vectors from the `vector` package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 09:44:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 09:44:54 -0000 Subject: [GHC] #10441: msys native python testsuite support doesn't work in some situations In-Reply-To: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> References: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> Message-ID: <060.8f0ba48a4da55ba7dee6efd5711f8629@haskell.org> #10441: msys native python testsuite support doesn't work in some situations -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D952 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D952 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 10:08:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 10:08:12 -0000 Subject: [GHC] #10483: Refactor HsForAllTy Message-ID: <046.9d853f4d4b58831f7571afd11de45120@haskell.org> #10483: Refactor HsForAllTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I got sucked into refactoring `HsForAllTy`, like this: {{{ data HsType name = HsForAllTy (HsForAll name) (LHsType name) | ... data HsForAll name -- The quantifiers of a HsForAllTy = HSF { hsf_flag :: HsExplicitFlag , hsf_extra :: Maybe SrcSpan , hsf_qtvs :: LHsTyVarBndrs name , hsf_ctxt :: LHsContext name } }}} This makes a number of functions neater, as well as naming the fields of a troublesomely-high-arity data constructor. This ticket is here to track progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 10:15:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 10:15:56 -0000 Subject: [GHC] #10483: Refactor HsForAllTy In-Reply-To: <046.9d853f4d4b58831f7571afd11de45120@haskell.org> References: <046.9d853f4d4b58831f7571afd11de45120@haskell.org> Message-ID: <061.9b8655729ac56cdfe82a252712f6ce10@haskell.org> #10483: Refactor HsForAllTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D953 -------------------------------------+------------------------------------- Changes (by simonpj): * differential: => Phab:D953 Comment: Current failures {{{ Unexpected failures: ghc-api/annotations T10268 [bad stdout] (normal) ghc-api/annotations T10278 [bad stderr] (normal) ghc-api/annotations T10354 [bad stdout] (normal) ghc-api/annotations T10396 [bad stdout] (normal) ghc-api/annotations listcomps [bad stdout] (normal) ghc-api/landmines landmines [bad stdout] (normal) rename/should_fail T5951 [stderr mismatch] (normal) }}} Alan Z: could you possibly look at the annotations ones? I tried not to change anything, so I supsect that there is one bug causing all of them. Thank you! I will deal with T5951. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 10:33:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 10:33:02 -0000 Subject: [GHC] #10442: Loading of shared libraries is problematic in ghc 7.10.1 In-Reply-To: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> References: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> Message-ID: <068.dfab3f3a6960c8858a7f84c3452cb256@haskell.org> #10442: Loading of shared libraries is problematic in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 11:55:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 11:55:43 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.392cf47e4eccb1fa0178a3bfbd58f777@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T10047 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): This has broken the name resolution behavior for quasiquoters. Previously, this was valid (assuming "wow" is a quasiquoter producing a declaration): {{{ {-# LANGUAGE QuasiQuotes #-} thing = okay [wow|stuff|] okay = 3 }}} but now it produces an error: {{{ /tmp/runghcXXXX1804289383846930886.hs:3:9: error: Not in scope: ?okay? }}} because after this change, quasiquoters share the declaration order restrictions of splices. I have code that depends on the previous behavior, and I'm sure there's a lot more code out there that does as well, as this was one of the main advantages of using quasiquoters over regular splices. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 12:33:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 12:33:26 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.b0a021f869d19808a732488ac9c33986@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): @thoughtpolice, so you disabled `shortOutIndirections` *and* CSE? In that case we don't know which is the cause of the difference, right? If you disable CSE by itself, do you still see the difference? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 13:02:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 13:02:23 -0000 Subject: [GHC] #10484: hPutBuf crashes when trying to write a large string to stdout (resource exhausted) Message-ID: <046.8764c6246b23f1309a5c029d47994521@haskell.org> #10484: hPutBuf crashes when trying to write a large string to stdout (resource exhausted) -------------------------------------+------------------------------------- Reporter: bayloff | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Operating System: Windows Keywords: | Type of failure: Runtime crash Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following program crashes when I try to write a byte string larger than 61kb to stdout: {{{#!hs import qualified Data.ByteString.Char8 as BS main = BS.putStrLn $ BS.replicate (62 * 1024) 'x' }}} When I run the above, I get the following runtime error: {{{ : hPutBuf: resource exhausted (Not enough space) }}} GHC versions tested: 7.6.3 and 7.8.3 (both 32 and 64 bit) OS: Windows 7 and Windows Server 20008R2 The issue is not reproducible with the Linux version of GHC. It is also not reproducible if I use the Lazy variant of the byte strings. Note: The Linux version of the program was tested with GHC 7.6.3 because this is the one I have on my Ubuntu machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 13:18:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 13:18:25 -0000 Subject: [GHC] #8723: sdist should not have to build everything In-Reply-To: <046.92216f47e2ba2986f6ec19c3e526b45f@haskell.org> References: <046.92216f47e2ba2986f6ec19c3e526b45f@haskell.org> Message-ID: <061.823da705d72c75196dfbb509b6eeae1b@haskell.org> #8723: sdist should not have to build everything -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: patch Priority: low | Milestone: 7.12.1 Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D917 -------------------------------------+------------------------------------- Comment (by thomie): How about adding `happy` and `alex` to the build requirements for building from source tarballs? Then generating a source tarball becomes easier. As suggested by SPJ in ticket:1693#comment:25. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 14:00:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 14:00:58 -0000 Subject: [GHC] #10485: Remove __MINGW32__ from all source files Message-ID: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> #10485: Remove __MINGW32__ from all source files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: newcomer | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See ticket:9945#comment:15. Prepare a patch that removes all occurrences of `__MINGW32__` from all source files, and send it to [wiki:Phabricator]. Easy! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 14:04:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 14:04:24 -0000 Subject: [GHC] #10442: Loading of shared libraries is problematic in ghc 7.10.1 In-Reply-To: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> References: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> Message-ID: <068.e8d8ce15f4bd891274afd7f7bc23a97b@haskell.org> #10442: Loading of shared libraries is problematic in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:3 rwbarton]: > Isn't this another consequence of the fix for #8935 (opening shared libraries with RTLD_LOCAL)? Yes it is. > So should we also link temporary object files against any libraries specified on the ghc(i) command line with `-lfoo`? Building libtest.so like so {{{ gcc -shared -o libMy.so mylib.o -L. -l test -Wl,-rpath=. }}} should fix the problem with `cabal repl`. I tried it with openSUSE's ghc 7.8.4 that has the fix for #8935 included. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 14:11:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 14:11:08 -0000 Subject: [GHC] #8403: Pretty-printing of long types In-Reply-To: <047.792ac96369079bc46b579fe906221406@haskell.org> References: <047.792ac96369079bc46b579fe906221406@haskell.org> Message-ID: <062.c50167a18b0f7e9bffe3caf579ab8c05@haskell.org> #8403: Pretty-printing of long types -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9428 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => Comment: Yeah, maybe just leave it the way it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 14:14:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 14:14:39 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.0b9ef8b46fa97204656e8815e2c0fb1d@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type | Version: None checker) | Keywords: newcomer Resolution: None | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: simonpj => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 14:17:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 14:17:14 -0000 Subject: [GHC] #10145: :info (->) should list its fixity In-Reply-To: <045.b793bfebd21acea22cc8b71109f4ac0d@haskell.org> References: <045.b793bfebd21acea22cc8b71109f4ac0d@haskell.org> Message-ID: <060.e48b309a23de6e074d5074c3e7c87749@haskell.org> #10145: :info (->) should list its fixity -------------------------------------+------------------------------------- Reporter: oerjan | Owner: phadej Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: GHCi | Version: 7.8.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | ghci/should_run/T10145 Related Tickets: | Blocking: | Differential Revisions: Phab:D741 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 14:19:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 14:19:03 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.53f3750406397f1457d2b2675c98d4fa@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type | Version: None checker) | Keywords: newcomer Resolution: None | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rodlogic): Could this cause a bit of confusion when we have Backpack signatures? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 14:19:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 14:19:18 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.bfa79fc247832cd30ae39ac38a231b70@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: monoidal => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 14:26:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 14:26:19 -0000 Subject: [GHC] #9259: GHCi should list its available command line options In-Reply-To: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> References: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> Message-ID: <063.e9f2cb97b24cd35c4ae910eb0ea434a0@haskell.org> #9259: GHCi should list its available command line options -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: kolmodin Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Driver | Version: Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D337 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 7.12.1 Comment: I think all work is done here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 14:31:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 14:31:00 -0000 Subject: [GHC] #10283: Make it possible to suppress warnings produced by -fdefer-type-errors In-Reply-To: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> References: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> Message-ID: <064.d2840ee63bb0fe5a83d715d70d55124d@haskell.org> #10283: Make it possible to suppress warnings produced by -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: newcomer Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D864 -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 7.12.1 Comment: This work is done, just waiting for a release notes update by thoughtpolice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 14:35:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 14:35:06 -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.1f505aadc5f5eec41d84c3e69de471d7@haskell.org> #4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | VictorDenisov Priority: normal | Status: new Component: Compiler | Milestone: 7.12.1 Resolution: | Version: 6.10.4 Operating System: Unknown/Multiple | Keywords: newcomer Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #2258 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: low => normal Comment: VictorDenisov: did you make any progress on this ticket or #2258? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 15:18:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 15:18:33 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.d4fe6a37feef1ec38ef1f80c46846efe@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T10047 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by spinda): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 15:42:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 15:42:11 -0000 Subject: [GHC] #10486: Allow addTopDecls to create annotations Message-ID: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> #10486: Allow addTopDecls to create annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently addTopDecls is [https://github.com/ghc/ghc/blob/228ddb95ee137e7cef02dcfe2521233892dd61e0/compiler/typecheck/TcSplice.hs#L811 restricted] to creating function, value, and foreign import declarations. Lifting this restriction allows one to create annotations without any issues, as far as I can tell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 15:59:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 15:59:32 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.936821dcf90a907c9fe0ba7bfb4d782f@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): I actually tested both, sorry. Just checked: yes, if I disable short-outs and CSE, it goes away. If I only disable CSE, it goes away. This is still all on GHC 7.10. I'll test on HEAD and STABLE again when I get a chance and post the 4-way results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 15:59:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 15:59:51 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.c501c5fd77e563a8d0165daa2d48d080@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): I actually tested both, sorry. Just checked: yes, if I disable short-outs and CSE, it goes away. If I only disable CSE, it goes away. This is still all on GHC 7.10. I'll test on HEAD and STABLE again when I get a chance and post the 4-way results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 16:13:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 16:13:08 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.f5284bca352924dee7ee52cef55ee263@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T10047 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): spinda: indeed, your example hints at a simpler manifestation of the bug; when `wow` runs in your program, `thing` is not accessible to `reify` (not in scope), whereas if you'd written a splice with `$(...)`, it would be in scope. Sorry to hear that your programs were broken by this fix, but can't you just move the quasiquotations upward in your file so that they aren't in the middle of any recursive definition groups (e.g., to the top of the file)? I'm pretty sure the main advantage of quasiquoters was supposed to be the succinct syntax, not an undocumented difference in scoping rules. If there's a real use case for a type of splice with different scoping, it doesn't particularly make language design sense to tie that difference to quasiquotes vs. traditional splices. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 16:22:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 16:22:45 -0000 Subject: [GHC] #10477: Tab-completing in a directory with Unicode heiroglyph crashes ghci In-Reply-To: <048.439ace31a3f068f577dd280d2e502f1d@haskell.org> References: <048.439ace31a3f068f577dd280d2e502f1d@haskell.org> Message-ID: <063.7cdebd9515884e5854644c1a61e444fb@haskell.org> #10477: Tab-completing in a directory with Unicode heiroglyph crashes ghci -------------------------------+------------------------------------------- Reporter: acfoltzer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------------- Comment (by AlexET): This specific problem comes from haskeline. It uses `map (toEnum . fromEnum)` to convert a `String` to a list of `Word16` before printing the string. This fails in this case of wider characters which need to be encoded with a surrogate pair. There is a six year old ticket here http://trac.haskell.org/haskeline/ticket/63. The bad news is that printing using the functions in the prelude has even worse unicode support on windows. It seems to print garbage (this includes for the unicode quotes in compiler error messages). If we are in the standard code page we just get errors (as expected). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 16:34:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 16:34:30 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.6cb824ce173988ef22283ed27b25840d@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T10047 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Reid is, as usual, spot on. The big deal about quasiquotes is that they save you writing `$(wow "blah")`. It's interesting that the (entirely accidental) change in scoping is "one of the main advantages of using quasi-quoters". Can you say why it's so important? Quasi-quoters may use anti-quotation: {{{ xs = blah [wow| funny language `(reverse xs)` blah |] }}} Here `wow` might use back-quotes to trigger anti-quotation, and then use `reify` to look up `reverse` and `xs`. So we'd need them to be in scope. It's not ridiculous to propose the scoping you want for declaration splices; it could be something like * bring all the binders into scope (`thing` and `okay` in your example) * run the quasi-quote * splice it in But someone would need to work out the details. Eg if there were two quasiquotes, what would each see in its reification environment. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 16:54:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 16:54:51 -0000 Subject: [GHC] #10486: Allow addTopDecls to create annotations In-Reply-To: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> References: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> Message-ID: <060.8870ab3ab86ad75cf01e784d9629fe92@haskell.org> #10486: Allow addTopDecls to create annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gridaphobe): * cc: gridaphobe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 18:03:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 18:03:05 -0000 Subject: [GHC] #10487: Unhelpful error from instance Generic Message-ID: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> #10487: Unhelpful error from instance Generic -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- That's the error you like too see, or rather not. ;( {{{ [180 of 289] Compiling Agda.TypeChecking.Serialise ( src/full/Agda/TypeChecking/Serialise.hs, dist-2.4.2.4/build/Agda/TypeChecking/Serialise.o ) src/full/Agda/TypeChecking/Serialise.hs:1:1: Duplicate instance declarations: instance GHC.Generics.Datatype Agda.TypeChecking.Serialise.D1Name -- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1 instance GHC.Generics.Datatype Agda.TypeChecking.Serialise.D1Name -- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1 src/full/Agda/TypeChecking/Serialise.hs:1:1: Duplicate instance declarations: instance GHC.Generics.Constructor Agda.TypeChecking.Serialise.C1_0Name -- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1 instance GHC.Generics.Constructor Agda.TypeChecking.Serialise.C1_0Name -- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1 }}} Problems: * no position in file * system generated names D1Name, C1_0Name * obvious bogus (same instance cannot be defined twice at same location) * leads me to suspect bug in Generics rather than in my code Reproduce: * git clone agda/agda from github, * checkout this commit https://github.com/agda/agda/commit/46823536559276807639488eae151a0e855fdb95 * and try to compile with {{{ make install-bin }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 18:22:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 18:22:04 -0000 Subject: [GHC] #10487: Unhelpful error from instance Generic In-Reply-To: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> References: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> Message-ID: <066.bfca765ca234a108034cccaca7147187@haskell.org> #10487: Unhelpful error from instance Generic -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by andreas.abel): It is also a proper bug. {{{#!hs module M where data Name = Name }}} {{{#!hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE StandaloneDeriving #-} module N where import GHC.Generics import qualified M data Name = Name deriving instance Generic M.Name deriving instance Generic Name }}} Error: {{{ [1 of 2] Compiling M ( M.hs, interpreted ) [2 of 2] Compiling N ( /home/abel/play/haskell/bugs/Generics/N.hs, interpreted ) /home/abel/play/haskell/bugs/Generics/N.hs:1:1: Duplicate instance declarations: instance Datatype N.D1Name -- Defined at /home/abel/play/haskell/bugs/Generics/N.hs:1:1 instance Datatype N.D1Name -- Defined at /home/abel/play/haskell/bugs/Generics/N.hs:1:1 /home/abel/play/haskell/bugs/Generics/N.hs:1:1: Duplicate instance declarations: instance Constructor N.C1_0Name -- Defined at /home/abel/play/haskell/bugs/Generics/N.hs:1:1 instance Constructor N.C1_0Name -- Defined at /home/abel/play/haskell/bugs/Generics/N.hs:1:1 Failed, modules loaded: M. }}} Qualified names are not handled properly by DeriveGeneric. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 18:33:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 18:33:44 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.01e45ab0e420415eac36e4344ec3e547@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by s9gf4ult): Why not? > import qualified Data.Map (Map) as M While it is qualified import it should have keyword "qualified" to specify that explicitly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 18:52:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 18:52:46 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.4f51e0e5a30021cac740f85466a2a9f6@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Rufflewind): Replying to [comment:7 s9gf4ult]: > Why not? > > > import qualified Data.Map (Map) as M > > > While it is qualified import it should have keyword "qualified" to specify that explicitly. The `qualified` applies to `M` but not to `(Map)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 19:08:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 19:08:52 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.73c8f79c60fba4fb2d0009030bf7d506@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by s9gf4ult): > The `qualified` applies to `M` but not to `(Map)`. Yes, but this syntax still looks more logical than without "qaulified". It is not obvious to see something like > import Data.Map (Map) as M And have module Data.Map imported qualified as M. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 19:35:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 19:35:29 -0000 Subject: [GHC] #10386: Documentation for -Wall is wrong In-Reply-To: <045.232d0261c427e0e77548f09249f01d5e@haskell.org> References: <045.232d0261c427e0e77548f09249f01d5e@haskell.org> Message-ID: <060.433a542fad6721b02f98783da5916a0b@haskell.org> #10386: Documentation for -Wall is wrong -------------------------------------+------------------------------------- Reporter: AlexET | Owner: AlexET Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D889 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: This was merged in 6d5387f6f1f86c5a622df0de76f0b909ce1c1a7d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 19:39:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 19:39:09 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.2e562db3066ebf0fded3be4cbc978a80@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T10047 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): Firstly, at least as far as I've seen, the scoping restriction is one of the most common complaints about Template Haskell splices, as using them at all suddenly causes order of declaration to matter where it didn't before. This contributes to the stigma and avoidance of Template Haskell usage. It would be a shame to see quasiquoters get shackled with this issue as well. Then, I think it's important to consider the role of quasiquoters as enabling extensions to the language without requiring compiler plugins, external preprocessors, or what have you, while keeping them contained from the rest of the Haskell source around them. As a specific example, I'll pull from my current GSoC project, which is impacted by this change (and, to be honest, is the reason I ran into this). I have an {{{lq}}} quasiquoter which allows for LiquidHaskell type signatures and specifications to be attached to variables and types. In the declaration context, it parses a subset of Haskell with LiquidHaskell extensions and emits declarations and annotations. Take some vanilla Haskell code: {{{ module Test () where type Nat = Int add :: Nat -> Nat -> Nat add x y = id' $ x + y id' :: a -> a id' x = x }}} A little contrived, but not too far from what you'd run into in sufficiently complex real-world projects. Under the current (or, previous) quasiquoter implementation, extending this existing code with custom annotations is a fairly straightforward translation: {{{ {-# LANGUAGE QuasiQuotes #-} module Test () where import LiquidHaskell [lq| type Nat = { v:Int | 0 <= v } |] [lq| add :: Nat -> Nat -> Nat |] add x y = id' $ x + y [lq| id' :: x:a -> { v:a | v == a } |] id' x = x }}} But after this change, introducing these annotations suddenly makes order of declaration matter. What were lightweight inline extensions to the language now require restructuring of code, either reordering the functions themselves or moving all signatures and specifications to the top of every file. Needless to say, this makes the whole thing much less attractive. And, frankly, this is what quasiquoters are all about: lightweight, inline language extensions that don't interfere with the rest of the code. This intent is reflected in the original paper. With this restriction imposed, anything using quasiquoters suddenly brings in a lot more baggage than it used to, discouraging use. It's not just a matter of modifying some existing code to fit, it's that this hampers a whole set of use-cases for which quasiquoters (a) used to fit quite nicely and (b) are the only real solution at present. Quietly breaking this behavior of 12 years now in a tangentially related bugfix strikes me as, well, wrong, especially when there isn't an alternative available. Excuse me if I seem rather passionate about this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 19:41:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 19:41:58 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.046339b4244dbc25cf20641740aea718@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T10047 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): Sorry, I should add that I'm not opposed to change here, as long as a viable alternative that preserves these use cases makes it in at the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 19:43:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 19:43:05 -0000 Subject: [GHC] #10480: Ship Cabal with Windows filepath fix In-Reply-To: <045.437e09638d10b0a54f88e3ea0078e353@haskell.org> References: <045.437e09638d10b0a54f88e3ea0078e353@haskell.org> Message-ID: <060.2654ba090b40b67cbf7c10c91fa8b400@haskell.org> #10480: Ship Cabal with Windows filepath fix -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: libraries | Version: 7.10.1 (other) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: normal => high Comment: Bumping to make severity clear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 19:43:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 19:43:50 -0000 Subject: [GHC] #10479: Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh In-Reply-To: <045.1ef1ca690686af7d2265216e3878b27c@haskell.org> References: <045.1ef1ca690686af7d2265216e3878b27c@haskell.org> Message-ID: <060.9beb5a054dbebd5617492698282bdb7e@haskell.org> #10479: Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Package system | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: 9506 | Differential Revisions: Phab:D922 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: normal => high Comment: Bumping (similar to #10480, which requires an update, too). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 19:45:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 19:45:50 -0000 Subject: [GHC] #9507: ghc-pkg mode to query by package-key In-Reply-To: <045.94e3570469ccb8429301ef11591de043@haskell.org> References: <045.94e3570469ccb8429301ef11591de043@haskell.org> Message-ID: <060.9003f985752235dc6b8d93de0e6631ec@haskell.org> #9507: ghc-pkg mode to query by package-key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D946 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"c69b69d2cda890e6f3f6aa1fd4092421e6053b89/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c69b69d2cda890e6f3f6aa1fd4092421e6053b89" ghc-pkg support query by package-key, fixes #9507 Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D946 GHC Trac Issues: #9507 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 19:46:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 19:46:20 -0000 Subject: [GHC] #9507: ghc-pkg mode to query by package-key In-Reply-To: <045.94e3570469ccb8429301ef11591de043@haskell.org> References: <045.94e3570469ccb8429301ef11591de043@haskell.org> Message-ID: <060.6c1aad9359201744d1a2e03dad50f55b@haskell.org> #9507: ghc-pkg mode to query by package-key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: merge Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D946 -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 19:46:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 19:46:56 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.540d83bffc1fc591f5b706dd7359ee6b@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T10047 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): >Quasi-quoters may use anti-quotation: > >{{{ >xs = blah >[wow| funny language `(reverse xs)` blah |] >}}} Is this a new feature? It doesn't seem to be present as of 7.10.1. (Apologies for the multiple consecutive replies.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 19:55:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 19:55:33 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.aaeb6e38d02b72d1ffe2521c0d4c38ac@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Merged to 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 19:56:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 19:56:07 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.45dbe04f4dbd125298c7bd729b21e472@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: ezyang => * status: closed => new * resolution: fixed => Comment: Whoops, my bad! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 20:00:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 20:00:31 -0000 Subject: [GHC] #9507: ghc-pkg mode to query by package-key In-Reply-To: <045.94e3570469ccb8429301ef11591de043@haskell.org> References: <045.94e3570469ccb8429301ef11591de043@haskell.org> Message-ID: <060.b23008b42bf5a2235adfada47a51d844@haskell.org> #9507: ghc-pkg mode to query by package-key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.9 Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D946 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 20:03:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 20:03:33 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.4186b9cb291aea5106cf0f9e13d15944@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Yes, to be clear, was this with the binary distribution, MinGW, Haskell Platform, etc? We shouldn't ever need administrative privileges in the regular binary distribution for anything, so this may not be our bug if that fixes it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 20:03:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 20:03:41 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.927c5b9d78d76cde3c859164afeb277c@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 20:10:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 20:10:08 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.8d35c53ed0eb582a6d572b3fe311a021@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by acowley): I don't think a desire to keep the `qualified` word is more logical or obvious than any other option. I can't think of another programming language that uses the `qualified` keyword. Agda uses `import M as N` to create a qualified alias. Python imports qualified by default. But this is Haskell, so we should consider how Haskell is used. If you grep over the source of all packages in the Stackage package set, you will find that `import` statements that use the `as` keyword are `qualified` 10x more than unqualified. If you focus on the specific syntax, `import Foo as F(bar)`, it is used in less than 0.3% of all import statements. So we are loading by far the more common usage with extra syntax. I suggest a way of reading import statements as "import ModuleName (unqualifiedImports)" If you want to use qualified names, all of that information is given by appending a suffix to the import statement beginning with the `as` keyword. This is certainly ''new'' syntax, but I have yet to see any quantifiable argument that it is less logical or undesired (see the support for the proposal linked from the haskell-cafe thread). Also note that the proposal will not break ''anything'': if you find `qualified` easier to read, then you can continue to use it. If nobody uses the new syntax because it is hard to understand, then nobody will suffer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 20:49:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 20:49:15 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.d81a8da5921b53edc44dde43155395f9@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hgolden): Replying to [comment:5 thoughtpolice]: > Yes, to be clear, was this with the binary distribution, MinGW, Haskell Platform, etc? We shouldn't ever need administrative privileges in the regular binary distribution for anything, so this may not be our bug if that fixes it? In my original report, there are two separate sets of messages: One is for the global directory and the other is for my personal directory. As a non- administrator user, I don't have write access to the global directory, since it is a subdirectory of C:\Program Files (under Windows 7 or later). However, I do have access to my own directory. I am getting the out-of- date messages for both files. As I recall, when I ran into this situation, I had administrative privileges on my PC. In my company's wisdom, I no longer have administrative privileges, so I can't test the proposed fix in comment #4, but I believe I already did that in the original report. Storing the global cache (or any other part of GHC) in a subdirectory of C:\Program Files will not work if the user doesn't have administrative privileges, at least under Windows 7 or later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 20:51:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 20:51:12 -0000 Subject: [GHC] #10442: Loading of shared libraries is problematic in ghc 7.10.1 In-Reply-To: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> References: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> Message-ID: <068.0c09a4fd46c1c71efac1f28496904689@haskell.org> #10442: Loading of shared libraries is problematic in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by artella.coding): Hi your solution works in ghc 7.10.1. Thanks a lot & I will close the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 21:03:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 21:03:29 -0000 Subject: [GHC] #10488: Inconsistent reduction of type family Message-ID: <047.9df2f686bfc501a9f62f05407ae7e752@haskell.org> #10488: Inconsistent reduction of type family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider this module: {{{ {-# LANGUAGE TemplateHaskell, TypeFamilies, GADTs, PolyKinds, DataKinds, ScopedTypeVariables, TypeOperators, UndecidableInstances #-} module SingBug where import Data.Singletons.TH $(promote [d| data Nat = Zero | Succ Nat deriving (Eq, Ord) |]) foo :: Proxy (Zero :< Succ Zero) foo = (Proxy :: Proxy True) }}} It fails to compile, with this: {{{ SingBug.hs:14:8: Couldn't match type ?'False? with ?'True? Expected type: Proxy ('Zero :< 'Succ 'Zero) Actual type: Proxy 'True In the expression: (Proxy :: Proxy True) In an equation for ?foo?: foo = (Proxy :: Proxy True) }}} However, if I remove the last two lines, it compiles fine. Witness this bizarre interaction: {{{ Prelude> :load "SingBug.hs" [1 of 1] Compiling SingBug ( SingBug.hs, interpreted ) Ok, modules loaded: SingBug. *SingBug> :kind! Zero :< Succ Zero Zero :< Succ Zero :: Bool = TrueSym0 *SingBug> :i TrueSym0 type TrueSym0 = 'True -- Defined in ?singletons-1.2:Data.Singletons.Prelude.Instances? *SingBug> :kind! (Proxy (Zero :< Succ Zero)) (Proxy (Zero :< Succ Zero)) :: * = Proxy TrueSym0 *SingBug> :t (Proxy :: Proxy (Zero :< Succ Zero)) (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy ('Zero :< 'Succ 'Zero) *SingBug> :t (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy True :1:2: Couldn't match type ?'False? with ?'True? Expected type: Proxy 'True Actual type: Proxy ('Zero :< 'Succ 'Zero) In the expression: (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy True *SingBug> :t (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy False (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy False :: Proxy 'False }}} It seems GHC can't decide if 0 is less than 1! When I ask it to use `:kind!`, it does the right thing. But if it's reducing a type during type-checking, it does very much the '''wrong''' thing. This is a regression compared to 7.8. I've been unable to minimize the test case or remove the `singletons` dependency, sadly. When I try to mimic the behavior of singletons without TH, it all works as expected. But I've found the problem. The apartness check for closed type families is very subtly broken, and I believe you can break the type system exploiting this bug. I can't quite tickle it directly though. Fix on the way in the next day. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 21:57:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 21:57:36 -0000 Subject: [GHC] #10488: Inconsistent reduction of type family In-Reply-To: <047.9df2f686bfc501a9f62f05407ae7e752@haskell.org> References: <047.9df2f686bfc501a9f62f05407ae7e752@haskell.org> Message-ID: <062.c0fb1a045a57149347eead8578ea8f93@haskell.org> #10488: Inconsistent reduction of type family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: Phab:D955 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch * related: => Phab:D955 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 22:00:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 22:00:53 -0000 Subject: [GHC] #8723: sdist should not have to build everything In-Reply-To: <046.92216f47e2ba2986f6ec19c3e526b45f@haskell.org> References: <046.92216f47e2ba2986f6ec19c3e526b45f@haskell.org> Message-ID: <061.366d8a20fc7a77690b33008a8e7fb946@haskell.org> #8723: sdist should not have to build everything -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: patch Priority: low | Milestone: 7.12.1 Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D917 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"092082e7583c8170ae41ef8d01a554db34f91bb3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="092082e7583c8170ae41ef8d01a554db34f91bb3" Build: ./boot && ./configure && make sdist (#8723) Make it possible to run `make sdist` right after configure, without completing a complete build first. Test Plan: I compared the contents of the created `.tar.bz2` files in the `sdistprep` directory, after running `make sdist` both before and after completing a full build, using `diff -r`. There weren't any differences (after applying the patches from D914). Note that the `.tar.bz2` files were not exactly the same size, but they aren't either when tarring and bzipping the same directory twice. It seems tarring and bzipping is not deterministic (on my system). Differential Revision: https://phabricator.haskell.org/D917 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 22:00:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 22:00:53 -0000 Subject: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!! In-Reply-To: <057.ee3a70497de9cc3d83abf1aab5293225@haskell.org> References: <057.ee3a70497de9cc3d83abf1aab5293225@haskell.org> Message-ID: <072.a4b972dd1fd2453f00b9bb212aa8fd6e@haskell.org> #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!! -------------------------+------------------------------------------------- Reporter: | Owner: igloo jvlask@? | Status: closed Type: | Milestone: 6.8.3 merge | Version: 6.6 Priority: | Keywords: ghci foreign ffi dll import normal | stdcall Component: GHCi | Architecture: x86 Resolution: | fixed | Operating System: | Windows | Test Case: | -------------------------+------------------------------------------------- Comment (by Thomas Miedema ): In [changeset:"07feab194aff4a2ae39514480736ce23a3b679b1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="07feab194aff4a2ae39514480736ce23a3b679b1" Testsuite: ignore `stdcall attribute ignored` (#1288) That warning is only shown on some platforms, and is I believe harmless. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 22:01:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 22:01:33 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.c4072462b9a7bf9c6f11877ea9c2a03e@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * milestone: 7.10.2 => 7.12.1 Comment: Great, the rest is for 7.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 22:14:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 22:14:55 -0000 Subject: [GHC] #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! In-Reply-To: <050.69a1127c662d09f1c26088e7d11c9d3b@haskell.org> References: <050.69a1127c662d09f1c26088e7d11c9d3b@haskell.org> Message-ID: <065.6f4a0cc6a699dc62027e21e6aaa64e88@haskell.org> #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D956 Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch * differential: => Phab:D956 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 22:38:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 22:38:31 -0000 Subject: [GHC] #10433: Fix load/store barriers in pre-ARMv7 builds In-Reply-To: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> References: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> Message-ID: <067.7641a867fc38534b6ac2f3d11347c75f@haskell.org> #10433: Fix load/store barriers in pre-ARMv7 builds -------------------------------------+--------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10244 | Differential Revisions: -------------------------------------+--------------------------------- Changes (by rwbarton): * owner: rwbarton => Comment: I won't be getting around to fixing this any time soon. The easy, conservative thing to do would be to set NOSMP if arm_HOST_ARCH_PRE_ARMv7 is defined. The fancy way would be to detect at runtime whether we are on a system that supports memory barriers and patch them in if so (like Linux's altinstructions). Probably too fancy... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 22:46:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 22:46:46 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.1aed93648003510f719c787584334361@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.2 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D924 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 23:43:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 23:43:03 -0000 Subject: [GHC] #10482: Not enough unboxing happens on data-family function argument In-Reply-To: <043.b6b30783c65ab27e97e75d03aac8ab21@haskell.org> References: <043.b6b30783c65ab27e97e75d03aac8ab21@haskell.org> Message-ID: <058.a2db42717ac82b1e17224147c6e70112@haskell.org> #10482: Not enough unboxing happens on data-family function argument -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 4 23:43:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Jun 2015 23:43:16 -0000 Subject: [GHC] #8723: sdist should not have to build everything In-Reply-To: <046.92216f47e2ba2986f6ec19c3e526b45f@haskell.org> References: <046.92216f47e2ba2986f6ec19c3e526b45f@haskell.org> Message-ID: <061.4a313e702c8fbedba3e6fa5f4f0671c2@haskell.org> #8723: sdist should not have to build everything -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: low | Milestone: 7.12.1 Component: Build System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D917 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 00:17:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 00:17:23 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.e3dc5f0bb1e7a73b22e41baa45347072@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: enum01.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D957 -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D957 Comment: This turned out to be more complicated than expected because clang's traditional mode ''also'' doesn't support stringification in any way as far as I can tell, so I replaced the use of CPP by a custom preprocessor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 01:40:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 01:40:27 -0000 Subject: [GHC] #10178: hs-boot/hsig ambiguity empty data declaration or type with no constructors In-Reply-To: <045.b8bd218346900e499cdb43f05ac39bda@haskell.org> References: <045.b8bd218346900e499cdb43f05ac39bda@haskell.org> Message-ID: <060.80631552082f0220c839a1ef974badb3@haskell.org> #10178: hs-boot/hsig ambiguity empty data declaration or type with no constructors -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Similarly, when I write: {{{ class C a }}} it is ambiguous whether or not it is a fully-specified empty type class, or an abstract type class. In fact, for this one we don't even distinguish the two cases in an hi file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 01:54:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 01:54:02 -0000 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images In-Reply-To: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> References: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> Message-ID: <059.2fb09686badabddd629643b2b79bd481@haskell.org> #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | thoughtpolice Priority: normal | Status: patch Component: Documentation | Milestone: 7.10.2 Resolution: | Version: 7.10.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D958 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch * differential: => Phab:D958 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 02:49:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 02:49:50 -0000 Subject: [GHC] #10489: Panic in TcEvidence due to wrong role Message-ID: <047.95d344fe6100d51b3187fc04a692030b@haskell.org> #10489: Panic in TcEvidence due to wrong role -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This single line tickles it: {{{ convert d = let d' = case d of '0' -> '!' in d' }}} produces {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.11.20150604 for x86_64-apple-darwin): ASSERT failed! file compiler/typecheck/TcEvidence.hs line 600 Sym cobox_af8M Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The failing assertion is about roles. Will look into this tomorrow. Labeling this "highest" because it's a very silly regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 04:47:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 04:47:56 -0000 Subject: [GHC] #10490: Missing binder type check in coercion equality test? Message-ID: <045.88a8f8016d64e4642295e135154caccb@haskell.org> #10490: Missing binder type check in coercion equality test? -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I was reading the equality testing code for coercions and I noticed this line: {{{ coreEqCoercion2 env (ForAllCo v1 co1) (ForAllCo v2 co2) = coreEqCoercion2 (rnBndr2 env v1 v2) co1 co2 }}} This doesn't test if the types of the binders are equal. Should it? (Or is the type always trivially the same?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 05:11:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 05:11:40 -0000 Subject: [GHC] #10491: Simplifier explosion with Accelerate Message-ID: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> #10491: Simplifier explosion with Accelerate -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In [https://github.com/AccelerateHS/accelerate Accelerate] we are encountering problems with the simplifier exploding the number of terms, which consequently cause huge compile times. This has only happened since the release of 7.10.1 and it appears to still be happening in the ghc-7.10 branch. In the attached Slice.hs you can see what is about the worst case example. Trying to compile this with `-O2` yields {{{ [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, Slice.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150602 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_s1FRp To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 1668604 }}} Bumping the tick factor to 150 stops this from happening, but at that point the simplifier blows up. See output.txt for the output of `ghc -v`. After half an hour we end up with ~4 million terms. At this point ghc takes up about 9GB of memory and I have to kill it. In order to reproduce this, you will need the `accelerate` package and all its various dependencies. The one on hackage works fine. I will try to come up with a test case that is not so heavy on dependencies, but I wanted to ensure this was raised before 7.10.2 is released. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 05:18:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 05:18:10 -0000 Subject: [GHC] #10491: Simplifier explosion with Accelerate In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.5a576bb2101473e50e8b666ee0d5ff9f@haskell.org> #10491: Simplifier explosion with Accelerate -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by robertce: Old description: > In [https://github.com/AccelerateHS/accelerate Accelerate] we are > encountering problems with the simplifier exploding the number of terms, > which consequently cause huge compile times. This has only happened since > the release of 7.10.1 and it appears to still be happening in the > ghc-7.10 branch. > > In the attached Slice.hs you can see what is about the worst case > example. Trying to compile this with `-O2` yields > > {{{ > [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, > Slice.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.1.20150602 for x86_64-apple-darwin): > Simplifier ticks exhausted > When trying UnfoldingDone $j_s1FRp > To increase the limit, use -fsimpl-tick-factor=N (default 100) > If you need to do this, let GHC HQ know, and what factor you needed > To see detailed counts use -ddump-simpl-stats > Total ticks: 1668604 > }}} > > Bumping the tick factor to 150 stops this from happening, but at that > point the simplifier blows up. See output.txt for the output of `ghc -v`. > After half an hour we end up with ~4 million terms. At this point ghc > takes up about 9GB of memory and I have to kill it. > > In order to reproduce this, you will need the `accelerate` package and > all its various dependencies. The one on hackage works fine. I will try > to come up with a test case that is not so heavy on dependencies, but I > wanted to ensure this was raised before 7.10.2 is released. New description: In [https://github.com/AccelerateHS/accelerate Accelerate] we are encountering problems with the simplifier exploding the number of terms, which consequently cause huge compile times. This has only happened since the release of 7.10.1 and it appears to still be happening in the ghc-7.10 branch. In the attached Slice.hs you can see what is about the worst case example. Trying to compile this with `-O2` yields {{{ [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, Slice.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150602 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_s1FRp To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 1668604 }}} Bumping the tick factor to 150 stops this from happening, but at that point the simplifier blows up. See output.txt for the output of `ghc -v`. After half an hour we end up with ~4 million terms. At this point ghc takes up about 9GB of memory and I have to kill it. In order to reproduce this, you will need the `accelerate` package and all its various dependencies. It doesn't have to be the latest from github. The version on hackage also works with the example I have given. I will try to come up with a test case that is not so heavy on dependencies, but I wanted to ensure this was raised before 7.10.2 is released. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 05:50:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 05:50:55 -0000 Subject: [GHC] #10442: Loading of shared libraries is problematic in ghc 7.10.1 In-Reply-To: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> References: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> Message-ID: <068.d6e2faa843a9ecaa38027259d539d8c6@haskell.org> #10442: Loading of shared libraries is problematic in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by artella.coding): Replying to [comment:5 trommler]: > Replying to [comment:3 rwbarton]: > > Isn't this another consequence of the fix for #8935 (opening shared libraries with RTLD_LOCAL)? > Yes it is. > > So should we also link temporary object files against any libraries specified on the ghc(i) command line with `-lfoo`? > > Building libtest.so like so > {{{ > gcc -shared -o libMy.so mylib.o -L. -l test -Wl,-rpath=. > }}} > > should fix the problem with `cabal repl`. I tried it with openSUSE's ghc 7.8.4 that has the fix for #8935 included. > > > Hi thanks a lot, your solution works in ghc 7.10.1. But another problem persists. If I now reorganise such that the shared libraries are created in a subdirectory `libDir`, then I get an error upon a `cabal run`. That is if I compile via : {{{ gcc -shared -o libDir/libtest.so test.c gcc -fPIC -c mylib.c -o mylib.o gcc -shared -o libDir/libMy.so mylib.o -L./libDir -l test -Wl,-rpath=./libDir }}} this creates the following shared libraries : {{{ libDir/libMy.so libDir/libtest.so }}} Then if I modify the cabal file to be : {{{ name: illustrate version: 0.1.0.0 build-type: Simple cabal-version: >=1.10 executable illustrate main-is: Main.hs build-depends: base >=4.8 && <4.9 default-language: Haskell2010 extra-libraries: test My extra-lib-dirs: ./libDir }}} then `cabal repl` works fine, but `cabal run` gives the following error : {{{ cabal run Preprocessing executable 'illustrate' for illustrate-0.1.0.0... [1 of 1] Compiling Main ( Main.hs, dist/build/illustrate /illustrate-tmp/Main.o ) Linking dist/build/illustrate/illustrate ... Running illustrate... /home/linux/Downloads/illustrate_withDir/dist/build/illustrate/illustrate: error while loading shared libraries: libtest.so: cannot open shared object file: No such file or directory }}} Why is this happening? Should I close this trac and post the problem above as a new Trac? Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 06:23:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 06:23:22 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.6539b40164b6d7f6cda07811afc84b02@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rpaladugu1): Without admin privileges, you can not even install it in c:\Program Files folder or anywhere else. The installer did ask admin privileges before starting the installation process if you logged in as standard user. The default location "i.e.C:\Program Files" is optional for MingGW or Haskell Platform during the install time. You can choose to override and install it somewhere. I have tested both MingGW and Haskell Platform and indeed was the case. As such there is no issue with the platform. However, doucmentation could be updated to highlight this issue so that there is a workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 08:14:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 08:14:12 -0000 Subject: [GHC] #10442: Loading of shared libraries is problematic in ghc 7.10.1 In-Reply-To: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> References: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> Message-ID: <068.c093b61bd32ecce2429ccaafb5016866@haskell.org> #10442: Loading of shared libraries is problematic in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:7 artella.coding]: > then `cabal repl` works fine, but `cabal run` gives the following error : > > {{{ > cabal run > Preprocessing executable 'illustrate' for illustrate-0.1.0.0... > [1 of 1] Compiling Main ( Main.hs, dist/build/illustrate /illustrate-tmp/Main.o ) > Linking dist/build/illustrate/illustrate ... > Running illustrate... > /home/linux/Downloads/illustrate_withDir/dist/build/illustrate/illustrate: error while loading shared libraries: libtest.so: cannot open shared object file: No such file or directory > > }}} > > Why is this happening? The linker line does not contain a `-rpath` argument for `libtest.so` > Should I close this trac and post the problem above as a new Trac? Thanks > Yes, please create a new ticket. Thanks! As a workaround you can add the following to `illustrate.cabal`: {{{ ghc-options: -optl=-Wl,-rpath,./libDir }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 10:02:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 10:02:46 -0000 Subject: [GHC] #8435: Do not copy stack after stack overflow In-Reply-To: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> References: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> Message-ID: <060.6adea58a408beb264dd6597b7a5e51f3@haskell.org> #8435: Do not copy stack after stack overflow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D938 -------------------------------------+------------------------------------- Changes (by archblob): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 10:03:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 10:03:08 -0000 Subject: [GHC] #8435: Do not copy stack after stack overflow In-Reply-To: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> References: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> Message-ID: <060.bb78f224d92f504ba8a45d340ab056c9@haskell.org> #8435: Do not copy stack after stack overflow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D938 -------------------------------------+------------------------------------- Changes (by archblob): * owner: => archblob -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 10:37:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 10:37:43 -0000 Subject: [GHC] #10490: Missing binder type check in coercion equality test? In-Reply-To: <045.88a8f8016d64e4642295e135154caccb@haskell.org> References: <045.88a8f8016d64e4642295e135154caccb@haskell.org> Message-ID: <060.ea71603b4e16d177b9ac3ff163724104@haskell.org> #10490: Missing binder type check in coercion equality test? -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire (added) Comment: That does look wrong, well caught. Richard, you agree? Edward, could you fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 12:01:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 12:01:26 -0000 Subject: [GHC] #10443: Regression in forall typechecking In-Reply-To: <044.7362b4be773be0b820eb3b3df909767a@haskell.org> References: <044.7362b4be773be0b820eb3b3df909767a@haskell.org> Message-ID: <059.4a8ff092e5f0be35393accb55a35368e@haskell.org> #10443: Regression in forall typechecking -------------------------------------+------------------------------------- Reporter: alanz | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: => simonpj * priority: high => highest Comment: Simon, could you give this one a quick glance for triaging? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 13:06:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 13:06:01 -0000 Subject: [GHC] #10443: Regression in forall typechecking In-Reply-To: <044.7362b4be773be0b820eb3b3df909767a@haskell.org> References: <044.7362b4be773be0b820eb3b3df909767a@haskell.org> Message-ID: <059.b5b0558e012cbe7171b82c12d84270cf@haskell.org> #10443: Regression in forall typechecking -------------------------------------+------------------------------------- Reporter: alanz | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by alanz): I've just noticed that line 294 {{{#!haskell deriving instance Generic Version }}} in `Language.Haskell.GhcMod.Types` needs to be commented out too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 13:45:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 13:45:38 -0000 Subject: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.b9087be53028e59506bc5937b498f2bc@haskell.org> #10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8004, #4384 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 15:08:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 15:08:01 -0000 Subject: [GHC] #10492: rpath & shared libraries in ghc 7.10.1 Message-ID: <053.8e0d059d0dcafb8986911d4bd2a6c057@haskell.org> #10492: rpath & shared libraries in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: new Type: bug | Milestone: 7.10.2 Priority: high | Version: 7.10.1 Component: Compiler | Operating System: Linux Keywords: | Type of failure: Runtime crash Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Suppose that I have : {{{#!hs //test.h int add(int a, int b); }}} {{{#!hs //test.c int add(int a, int b){ return (a + b); } }}} {{{#!hs //mylib.c #include "test.h" int testAdd(){ return add(2,3); } }}} Then I compile via : {{{#!hs gcc -shared -o libDir/libtest.so test.c gcc -fPIC -c mylib.c -o mylib.o gcc -shared -o libDir/libMy.so mylib.o -L./libDir -l test -Wl,-rpath=./libDir }}} Then I have Main.hs with : {{{#!hs module Main where import Foreign.C.Types foreign import ccall "testAdd" c_testAdd :: CInt -> CInt -> IO (CInt) main = do result <- c_testAdd 3 4 print result }}} and I have the associated cabal file : {{{#!hs name: illustrate version: 0.1.0.0 build-type: Simple cabal-version: >=1.10 executable illustrate main-is: Main.hs build-depends: base >=4.8 && <4.9 default-language: Haskell2010 extra-libraries: test My extra-lib-dirs: ./libDir }}} Then `cabal repl` works fine, but upon `cabal run` we get the following error : {{{ cabal run Preprocessing executable 'illustrate' for illustrate-0.1.0.0... [1 of 1] Compiling Main ( Main.hs, dist/build/illustrate /illustrate-tmp/Main.o ) Linking dist/build/illustrate/illustrate ... Running illustrate... /home/linux/Downloads/illustrate_withDir/dist/build/illustrate/illustrate: error while loading shared libraries: libtest.so: cannot open shared object file: No such file or directory }}} In https://ghc.haskell.org/trac/ghc/ticket/10442#comment:8 trommler mentions that the problem arises because `-rpath` is not fed as an argument for `libtest.so` during linking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 15:09:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 15:09:12 -0000 Subject: [GHC] #10488: Inconsistent reduction of type family In-Reply-To: <047.9df2f686bfc501a9f62f05407ae7e752@haskell.org> References: <047.9df2f686bfc501a9f62f05407ae7e752@haskell.org> Message-ID: <062.eb0752c1f02f389e619eb9b3902e49cc@haskell.org> #10488: Inconsistent reduction of type family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: Phab:D955 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"761fb7c4869a081da7320e4307dcb947b5ed95d1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="761fb7c4869a081da7320e4307dcb947b5ed95d1" Fix #10488 by unwrapping type synonyms. Summary: Previously, I had forgotten to unwrap vanilla type synonyms in the "flattener" that is used around the closed-type-family apartness check. Test Plan: validate Reviewers: austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D955 GHC Trac Issues: #10488 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 15:09:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 15:09:12 -0000 Subject: [GHC] #10489: Panic in TcEvidence due to wrong role In-Reply-To: <047.95d344fe6100d51b3187fc04a692030b@haskell.org> References: <047.95d344fe6100d51b3187fc04a692030b@haskell.org> Message-ID: <062.cd4a872b0b0571a4dd836dbcbb50c31e@haskell.org> #10489: Panic in TcEvidence due to wrong role -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"61b96a86c5342fb1c850361177d60fe855d948f6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="61b96a86c5342fb1c850361177d60fe855d948f6" Fix #10489 Dang, roles are annoying. Test case: typecheck/should_compile/T10489 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 15:09:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 15:09:21 -0000 Subject: [GHC] #10442: Loading of shared libraries is problematic in ghc 7.10.1 In-Reply-To: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> References: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> Message-ID: <068.8bec58b082a2883b7b8e07d0f39a0458@haskell.org> #10442: Loading of shared libraries is problematic in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by artella.coding): Hi I created a new ticket at https://ghc.haskell.org/trac/ghc/ticket/10492#ticket . Will close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 15:10:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 15:10:49 -0000 Subject: [GHC] #10442: Loading of shared libraries is problematic in ghc 7.10.1 In-Reply-To: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> References: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> Message-ID: <068.23a3f7a2066c93086cc0f0514e5ec894@haskell.org> #10442: Loading of shared libraries is problematic in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by artella.coding): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 15:10:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 15:10:59 -0000 Subject: [GHC] #10488: Inconsistent reduction of type family In-Reply-To: <047.9df2f686bfc501a9f62f05407ae7e752@haskell.org> References: <047.9df2f686bfc501a9f62f05407ae7e752@haskell.org> Message-ID: <062.fa37cbe9a16fb6c57a8e40ea79083b8a@haskell.org> #10488: Inconsistent reduction of type family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: Phab:D955 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => merge Comment: This is a nasty bug (that is, utterly broken type system) with a very easy fix. Please merge. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 15:11:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 15:11:58 -0000 Subject: [GHC] #10488: Inconsistent reduction of type family In-Reply-To: <047.9df2f686bfc501a9f62f05407ae7e752@haskell.org> References: <047.9df2f686bfc501a9f62f05407ae7e752@haskell.org> Message-ID: <062.2d8847a5c5f476876a2573690f0dbd79@haskell.org> #10488: Inconsistent reduction of type family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: Phab:D955 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): No test case added, as I was unable to tickle the bug without `singletons`. Besides, the fix is so straightforward, I'm not worried about a regression here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 15:14:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 15:14:06 -0000 Subject: [GHC] #10489: Panic in TcEvidence due to wrong role In-Reply-To: <047.95d344fe6100d51b3187fc04a692030b@haskell.org> References: <047.95d344fe6100d51b3187fc04a692030b@haskell.org> Message-ID: <062.92630534c9e470ecbd4545e086ac6c09@haskell.org> #10489: Panic in TcEvidence due to wrong role -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: highest | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_compile/T10489 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_compile/T10489 Comment: This bug does not happen in 7.10.1, but please test this in the 7.10.2 release candidate and merge if it happens there, too. I'm labeling this "merge" to make sure this doesn't get missed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 17:23:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 17:23:50 -0000 Subject: [GHC] #5014: canonicalizePath throws exception on paths that do not exist In-Reply-To: <048.38fed68301267b4479d1736f2f71b59d@haskell.org> References: <048.38fed68301267b4479d1736f2f71b59d@haskell.org> Message-ID: <063.3ffb9530508411f6bcdc200ee90c8702@haskell.org> #5014: canonicalizePath throws exception on paths that do not exist -------------------------------------+------------------------------------- Reporter: hesselink | Owner: ekmett Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Core Libraries | Version: 7.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4215 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Rufflewind): * status: new => closed * resolution: => fixed Comment: Fixed upstream. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 17:24:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 17:24:10 -0000 Subject: [GHC] #4215: canonicalizePath behaves strangely with paths that do not exist In-Reply-To: <047.bec475e57d7633f29981b0c1afde7835@haskell.org> References: <047.bec475e57d7633f29981b0c1afde7835@haskell.org> Message-ID: <062.f20ea82046e49abec5fda76aa6077833@haskell.org> #4215: canonicalizePath behaves strangely with paths that do not exist -------------------------------------+------------------------------------- Reporter: creswick | Owner: ekmett Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Core Libraries | Version: 6.12.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 Revisions: -------------------------------------+------------------------------------- Changes (by Rufflewind): * status: upstream => closed * resolution: => fixed Comment: Fixed upstream. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 20:13:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 20:13:14 -0000 Subject: [GHC] #10493: Inaccessible code might be accessible with newtypes and Coercible Message-ID: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> #10493: Inaccessible code might be accessible with newtypes and Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If I say {{{ module A (Age, ageCo) where import Data.Type.Coercion newtype Age = MkAge Int ageCo :: Coercion Age Int ageCo = Coercion }}} {{{ {-# LANGUAGE FlexibleContexts #-} module B where import Data.Coerce import A foo :: Coercible Age Int => () foo = () }}} I get {{{ B.hs:8:8: error: Couldn't match representation of type ?Age? with that of ?Int? Inaccessible code in the type signature for: foo :: Coercible Age Int => () In the ambiguity check for the type signature for ?foo?: foo :: Coercible Age Int => () To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ?foo?: foo :: Coercible Age Int => () }}} I agree that module `B` can't directly prove `Coercible Age Int`. But `ageCo` is in scope which proves exactly this! So it is provable, albeit directly. GHC should not claim that the code is inaccessible. Proposed fix: in `canDecomposableTyConApp`, only call `canEqHardFailure` for a representational equality when both tycons involved say `True` to `isDistinctTyCon`. I'm happy to put the fix in, once someone seconds this idea. Getting this right has proved harder than I thought! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 20:42:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 20:42:26 -0000 Subject: [GHC] #10494: Representational equalities over AppTys are not hard failures Message-ID: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> #10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If I say {{{ module App where import Data.Coerce foo :: Coercible (a b) (c d) => a b -> c d foo = undefined }}} I get {{{ App.hs:5:8: error: Couldn't match representation of type ?a b? with that of ?c d? Inaccessible code in the type signature for: foo :: Coercible (a b) (c d) => a b -> c d In the ambiguity check for the type signature for ?foo?: foo :: forall (a :: * -> *) b (c :: * -> *) d. Coercible (a b) (c d) => a b -> c d To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ?foo?: foo :: Coercible (a b) (c d) => a b -> c d }}} This is very silly, indeed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 20:42:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 20:42:49 -0000 Subject: [GHC] #10493: Inaccessible code might be accessible with newtypes and Coercible In-Reply-To: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> References: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> Message-ID: <062.ac0eeddb545ab96d8adcca6bc4848f7d@haskell.org> #10493: Inaccessible code might be accessible with newtypes and Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 20:43:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 20:43:10 -0000 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images In-Reply-To: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> References: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> Message-ID: <059.dd1d3922792355b4f5468ac17817a051@haskell.org> #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | thoughtpolice Priority: normal | Status: patch Component: Documentation | Milestone: 7.10.2 Resolution: | Version: 7.10.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D958 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"dcaaa980dc59202744bb3888d9662f9a7558cdf6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dcaaa980dc59202744bb3888d9662f9a7558cdf6" docs: Fix #10416 Summary: Apparently this was broken by b30c6012c7552c874281050d40e5a59012b2c5e7, but I can't reproduce the issue described there at all. Signed-off-by: Austin Seipp Test Plan: Use my eyes to read the resulting user manual. Reviewers: hvr, thomie Reviewed By: thomie Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D958 GHC Trac Issues: #10416 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 20:44:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 20:44:36 -0000 Subject: [GHC] #10495: Total inability to infer type for coerce Message-ID: <047.88be9b06528fbf6e5c30196ecacf3fe5@haskell.org> #10495: Total inability to infer type for coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If I say {{{ import Data.Coerce foo = coerce }}} I get {{{ Couldn't match representation of type ?a0? with that of ?b0? ?a0? is untouchable inside the constraints: () bound by the inferred type of foo :: a0 -> b0 at /Users/rae/temp/bug/App.hs:3:1-12 Relevant bindings include foo :: a0 -> b0 (bound at /Users/rae/temp/bug/App.hs:3:1) In the expression: coerce In an equation for ?foo?: foo = coerce }}} How awful. Eta-expanding `foo` works fine, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 20:44:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 20:44:41 -0000 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images In-Reply-To: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> References: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> Message-ID: <059.bcbd87495698edf3684c313c1429984a@haskell.org> #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | thoughtpolice Priority: normal | Status: merge Component: Documentation | Milestone: 7.10.2 Resolution: | Version: 7.10.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D958 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 20:49:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 20:49:55 -0000 Subject: [GHC] #10479: Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh In-Reply-To: <045.1ef1ca690686af7d2265216e3878b27c@haskell.org> References: <045.1ef1ca690686af7d2265216e3878b27c@haskell.org> Message-ID: <060.e1423b634b83801719a90e514dcffeed@haskell.org> #10479: Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Package system | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: 9506 | Differential Revisions: Phab:D922 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 20:59:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 20:59:23 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.f91919606de5aec7175fc63baa8cb96c@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Changes (by erikd): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 21:35:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 21:35:32 -0000 Subject: [GHC] #10495: Total inability to infer type for coerce In-Reply-To: <047.88be9b06528fbf6e5c30196ecacf3fe5@haskell.org> References: <047.88be9b06528fbf6e5c30196ecacf3fe5@haskell.org> Message-ID: <062.009c3f91b871724b600d7c3963509ebd@haskell.org> #10495: Total inability to infer type for coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Try `NonMonmorphismRestriction`; works fine. This is just the MR biting. I'm not sure there is much we can do here. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 21:51:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 21:51:34 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.440d01b429e941da048478c896cbefd9@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DeriveFunctor Here's a (rough draft of) a wiki article] about the {{{DeriveFunctor}}}, {{{DeriveFoldable}}}, and {{{DeriveTraversable}}} trio, included the proposed change from this feature request. Feedback is very much appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 22:19:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 22:19:15 -0000 Subject: [GHC] #10493: Inaccessible code might be accessible with newtypes and Coercible In-Reply-To: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> References: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> Message-ID: <062.4242950b2cca77a2dd002c902c1eb9b2@haskell.org> #10493: Inaccessible code might be accessible with newtypes and Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): That's the right place. Currently we have {{{ -- Fail straight away for better error messages -- See Note [Use canEqFailure in canDecomposableTyConApp] | isDataFamilyTyCon tc1 || isDataFamilyTyCon tc2 = canEqFailure ev eq_rel ty1 ty2 | otherwise = canEqHardFailure ev eq_rel ty1 ty2 }}} I think you are proposing {{{ | eq_rel == ReprEq && not (isDistinctTyCon tc1 && isDictinctTyCon tc2) = canEqFailure ev eq_rel ty1 ty2 | otherwise = canEqHardFailure ev eq_rel ty1 ty2 }}} That looks right, given the comment on `isDistinctTyCon`: {{{ -- | 'isDistinctTyCon' is true of 'TyCon's that are equal only to -- themselves, even via coercions (except for unsafeCoerce). -- This excludes newtypes, type functions, type synonyms. -- It relates directly to the FC consistency story: -- If the axioms are consistent, -- and co : S tys ~ T tys, and S,T are "distinct" TyCons, -- then S=T. }}} Tihs comment is vague about roles. If we have a poof co :: S ~r T, and S and T are "distinct" then S=T. But at what role is 'r'? It would be helpful to clarify this comment in role vocabulary. Similarly the comment `Note [Pruning dead case alternatives]` in `Unify.hs` needs reviewing in the role world. `Unify.typesCantMatch` is basically checking for apartness; which is also implemented somehwere else. Can we combine? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 22:34:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 22:34:39 -0000 Subject: [GHC] #10443: Regression in forall typechecking In-Reply-To: <044.7362b4be773be0b820eb3b3df909767a@haskell.org> References: <044.7362b4be773be0b820eb3b3df909767a@haskell.org> Message-ID: <059.3922c76447fd66cb4d127ce68f8c73a9@haskell.org> #10443: Regression in forall typechecking -------------------------------------+------------------------------------- Reporter: alanz | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: OK I've looked at this. It's a bug that 7.8 accepts it. The offending code is {{{ liftBaseWith f = GhcModT . liftBaseWith $ \runInBase -> f $ runInBase . unGhcModT }}} Here is a self-contained smaller version {{{ {-# LANGUAGE RankNTypes #-} module Foo where type RunInBase m = forall b. m b -> m b lbw :: (RunInBase m -> m a) -> m a lbw = error "urk" foo1 f = (id . lbw) (\r -> r f) foo2 f = id (lbw (\r -> r f)) }}} Now `foo2` is accepted by 7.10, but `foo1` is not. Why is `foo1` rejected? * Note that `RunInBase` is a polymorphic type. * So in `foo2`, in the application `(lbw (\r -> r f))`, GHC can look up the type of `lbw`, and propagate it into the argumet `(\r -> r f)`. So `r` gets a polymorphic type, `f :: RunInBase m`. * But in `foo1`, the call doesn't look like `(lbw arg)`; instead it looks like `(id . lbw) arg`. So the higher-rank propagation doesn't happen, and `r` gets a monotype, something like `r :: t -> m a`. * So in the end we get {{{ Couldn't match type ?t -> m a? with ?RunInBase m? }}} You want proper impredicative polymorphism, and GHC doesn't have that. There was a bug in GHC 7.8 that unpredictably allowed certain bits of impredicativity, but I fixed that. You can fix `ghc-mod` by writing {{{ liftBaseWith f = GhcModT (liftBaseWith $ \runInBase -> f $ runInBase . unGhcModT) }}} So I clain that this is not a bug. Yell if you disagree Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 5 23:24:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Jun 2015 23:24:55 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.0e3b3cea977ead47bf01e7ceb770b9bf@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8276 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mjmrotek): I can confirm that my second bugs (the ghc.exe bug and the liquid haskell bug) occured only on Windows, but the first (minor, because it's very situational) bug happened on Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 6 01:15:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Jun 2015 01:15:24 -0000 Subject: [GHC] #10495: Total inability to infer type for coerce In-Reply-To: <047.88be9b06528fbf6e5c30196ecacf3fe5@haskell.org> References: <047.88be9b06528fbf6e5c30196ecacf3fe5@haskell.org> Message-ID: <062.5314d437a78c37e8bdfba562c03ecd9e@haskell.org> #10495: Total inability to infer type for coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Yes; I realized that soon after posting the ticket. But the error message is terrible -- there's nothing about untouchable variables here. A fix to the error message is on the way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 6 08:52:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Jun 2015 08:52:32 -0000 Subject: [GHC] #10492: rpath & shared libraries in ghc 7.10.1 In-Reply-To: <053.8e0d059d0dcafb8986911d4bd2a6c057@haskell.org> References: <053.8e0d059d0dcafb8986911d4bd2a6c057@haskell.org> Message-ID: <068.4cbc498094a6a5bf361cab556abf5e01@haskell.org> #10492: rpath & shared libraries in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by trommler): * owner: => trommler * priority: high => normal Comment: Setting priority to normal. The issue affects only C libraries that are not installed in a standard location and there is a workaround https://ghc.haskell.org/trac/ghc/ticket/10442#comment:8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 6 09:01:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Jun 2015 09:01:44 -0000 Subject: [GHC] #10443: Regression in forall typechecking In-Reply-To: <044.7362b4be773be0b820eb3b3df909767a@haskell.org> References: <044.7362b4be773be0b820eb3b3df909767a@haskell.org> Message-ID: <059.1466d220b95ce7571d909b00c14d3ed2@haskell.org> #10443: Regression in forall typechecking -------------------------------------+------------------------------------- Reporter: alanz | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by alanz): I agree with the reasoning, but this is a change from 7.10.1 to ghc-7.10 branch, i.e. 7.10.2 Does it make sense to put something in the release notes for 7.10.2 about this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 6 10:28:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Jun 2015 10:28:34 -0000 Subject: [GHC] #8353: Easy way to defer type errors In-Reply-To: <047.34842edf8c636f9b11361128b151d960@haskell.org> References: <047.34842edf8c636f9b11361128b151d960@haskell.org> Message-ID: <062.9b06aced49396b1e4264cc41ca754695@haskell.org> #8353: Easy way to defer type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D960 -------------------------------------+------------------------------------- Changes (by triple): * status: new => patch * differential: => Phab:D960 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 6 12:31:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Jun 2015 12:31:36 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize In-Reply-To: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> References: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> Message-ID: <057.7d0024b8f5646a9a667573b1950425b1@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D938, | Phab:D961 -------------------------------------+------------------------------------- Changes (by archblob): * owner: => archblob * differential: Phab:D938 => Phab:D938, Phab:D961 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 6 16:12:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Jun 2015 16:12:44 -0000 Subject: [GHC] #10496: Update Haddock for 7.10.2 Message-ID: <042.4390876b176ea384032fa57b3511f6a4@haskell.org> #10496: Update Haddock for 7.10.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: thoughtpolice Type: task | Status: new Priority: high | Milestone: 7.10.2 Component: libraries | Version: (other) | Operating System: Unknown/Multiple Keywords: haddock | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've been told there are fixes queued for a point release of Haddock that ought to go along w/ GHC 7.10.2; This ticket is to ensure we don't forget about updating the Haddock submodule -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 6 21:20:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Jun 2015 21:20:19 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.2f90aef5a7c95d36c5f64c21e38f5413@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fuuzetsu): Another sample: parallel building {{{aeson-0.8.1.0}}}, we get sections like {{{ < 1e7b52dc510d1cf5d1c7dba94ff5093f < $cr4ZN :: Constr < 0d767d9de53af9e99867e765de72ede2 < $cr4ZO :: Constr < dc67d4c3fc9f3ce6c26b7594d8e6eae3 < $cr4ZP :: Constr < a2def0dbb719c6f881fc717fcb8298a4 < $cr4ZQ :: Constr < c6db659c87f4f30d7cd7837ade17c21a < $cr4ZR :: Constr < 0d876ce7c0dcbac035d3da6455b1dd5f < $cr4ZS :: Constr --- > bdb4c40eb8e399497201a7ebb5b21b8e > $cr5fY :: Constr > a1b0220e85ae58edc13e93774d8e283f > $cr5fZ :: Constr > 7d4faa76b1cc5a7319b59dca13194f80 > $cr5g0 :: Constr > 7fdf605be2abfeb55bab02c7c6b2124d > $cr5g1 :: Constr > 05b9af850c2c1ed35be735adcbdb7f6d > $cr5g2 :: Constr > bb94af6dd870df350419f5d32d4917cf > $cr5g3 :: Constr }}} which consequently screws up everything else. These are presumably generated by {{{Data}}} deriving. Attaching two sample interface files with the above, it was built with 7.10.1. In non-concurrent case, no issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 6 21:23:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Jun 2015 21:23:36 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.ee3b5e877e905e3693f4b4e19ae557b9@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fuuzetsu): Oh, by the way, there was a small experiment ran by nix users to judge the impact of this issue on parallel builds. You can find the results at https://github.com/peti/ghc-library-id-bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 6 22:05:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Jun 2015 22:05:08 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.e8cc0583b6113e01dfa57d9562faba2a@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: duncan Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: D172 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: GHC no longer depends on Cabal, I declare victory. {{{ commit 9597a258d356ae83411a512351c92428b61c112d Author: Duncan Coutts Date: Fri Aug 22 15:09:55 2014 +0100 Drop ghc library dep on Cabal }}} and many other commits in the vicinity -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 6 23:02:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Jun 2015 23:02:09 -0000 Subject: [GHC] #10497: Misc bugs with User Guide Message-ID: <049.6fde49e612d7b03a5a1adcd99eaad40d@haskell.org> #10497: Misc bugs with User Guide -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/prof- heap.html the image appears to be missing (it seems to be missing a `.png` extension). In https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/hp2ps.html the use of `-seaside` is suggested but the version of `gv` I have (3.7.4) only supports `-orientation=seaside`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 6 23:02:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Jun 2015 23:02:38 -0000 Subject: [GHC] #10497: Misc bugs with User Guide In-Reply-To: <049.6fde49e612d7b03a5a1adcd99eaad40d@haskell.org> References: <049.6fde49e612d7b03a5a1adcd99eaad40d@haskell.org> Message-ID: <064.17b9d8b494de3737b5de6da5ffaf23aa@haskell.org> #10497: Misc bugs with User Guide -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by Rufflewind: Old description: > In https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/prof- > heap.html the image appears to be missing (it seems to be missing a > `.png` extension). > > In > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/hp2ps.html > the use of `-seaside` is suggested but the version of `gv` I have (3.7.4) > only supports `-orientation=seaside`. New description: In https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/prof- heap.html the image appears to be missing (it seems to be missing a `.png` extension). In https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/hp2ps.html the use of `-seascape` is suggested but the version of `gv` I have (3.7.4) only supports `-orientation=seascape`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 7 02:40:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Jun 2015 02:40:08 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.940c50007405cbfe32a8e8327eb9c983@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T10047 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): re: what multiple declaration splices would see in their reification environments, the current behavior for quasiquoters seems to be to evaluate declaration quasiquoters in the order of appearance in the source. So decalarations produced by a declaration splice further up the file would make it into the reification environments of subsequent declaration splices. Declarations produced by splices lower down would be invisible to ones further up. This seems reasonable to me, as long as the scoping restriction is contained within the TH/quasiquoter processing and doesn't leak out over the rest of the source. I'm likely overlooking a deeper issue here, so please let me know what else would need to be addressed. re: anti-quotation in quasiquoters, I think I misunderstood simonpj's comment the first time around. If I understand correctly now, this isn't referring to some new native support for antiquotation, but rather an example of how a quasiquoter would come to use {{{reify}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 7 04:33:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Jun 2015 04:33:16 -0000 Subject: [GHC] #10498: "if ... then \case -> else ..." causes a "missing else clause" error Message-ID: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> #10498: "if ... then \case -> else ..." causes a "missing else clause" error -------------------------------------+------------------------------------- Reporter: | Owner: dramforever | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Parser) | Type of failure: Other Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following program: {{{#!hs {-# LANGUAGE LambdaCase #-} foo = if True then \case -> 1 -> 2 else id }}} Produces this message: {{{ problem.hs:4:5: parse error in if statement: missing required else clause }}} The problem in the code is that there's a -> after the \case. I don't know if a better error message can be generated, but this one is really unhelpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 7 04:34:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Jun 2015 04:34:50 -0000 Subject: [GHC] #10498: "if ... then \case -> else ..." causes a "missing else clause" error In-Reply-To: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> References: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> Message-ID: <065.c5b20695ea8194e5112ece903949dabb@haskell.org> #10498: "if ... then \case -> else ..." causes a "missing else clause" error -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dramforever): I ran into this in another more complex program yesterday. It took me 15 mins to find out the real cause of the error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 7 04:41:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Jun 2015 04:41:33 -0000 Subject: [GHC] #10498: "if ... then \case -> else ..." causes a "missing else clause" error In-Reply-To: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> References: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> Message-ID: <065.3c94a31ee5da0391bd9ad60345142a4c@haskell.org> #10498: "if ... then \case -> else ..." causes a "missing else clause" error -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Regression since 7.8 ("parse error on input ?->?"), so I guess it is caused by Phab:D201. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 7 06:56:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Jun 2015 06:56:25 -0000 Subject: [GHC] #9863: Provide PowerPC 64 bit native code generator In-Reply-To: <047.abf3d61d6edeed38824d04625109fece@haskell.org> References: <047.abf3d61d6edeed38824d04625109fece@haskell.org> Message-ID: <062.709b1b5d021f4439687170df9c39e271@haskell.org> #9863: Provide PowerPC 64 bit native code generator ------------------------------------+------------------------------------ Reporter: trommler | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D629 ------------------------------------+------------------------------------ Changes (by trommler): * owner: trommler => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 7 08:15:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Jun 2015 08:15:44 -0000 Subject: [GHC] #10499: Constraints should associate over ~ Message-ID: <047.83f97e075ebd50b473692509b2ca03c5@haskell.org> #10499: Constraints should associate over ~ -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Building the smallcheck package fails with this error: {{{ Test/SmallCheck/Property.hs:187:10: Could not deduce (Monad n) arising from the superclasses of an instance declaration from the context: (Monad m, m ~ n) bound by the instance declaration at Test/SmallCheck/Property.hs:187:10-52 Possible fix: add (Monad n) to the context of the instance declaration In the instance declaration for ?Testable n (Property m)? }}} Wondering if this is a bug in 7.11's constraint solver or 7.10's, since 7.10 and previous GHCs accept it and 7.11 doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 7 08:34:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Jun 2015 08:34:20 -0000 Subject: [GHC] #10499: Constraints should commute over ~ (was: Constraints should associate over ~) In-Reply-To: <047.83f97e075ebd50b473692509b2ca03c5@haskell.org> References: <047.83f97e075ebd50b473692509b2ca03c5@haskell.org> Message-ID: <062.d8f709d04907e927d899ff432ce037ea@haskell.org> #10499: Constraints should commute over ~ -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 7 10:52:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Jun 2015 10:52:10 -0000 Subject: [GHC] #10499: Constraints should commute over ~ In-Reply-To: <047.83f97e075ebd50b473692509b2ca03c5@haskell.org> References: <047.83f97e075ebd50b473692509b2ca03c5@haskell.org> Message-ID: <062.fe9b5b383be4d3d5f5b8562deda877d6@haskell.org> #10499: Constraints should commute over ~ -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: Fixed as #10423. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 7 11:31:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Jun 2015 11:31:52 -0000 Subject: [GHC] #10490: Missing binder type check in coercion equality test? In-Reply-To: <045.88a8f8016d64e4642295e135154caccb@haskell.org> References: <045.88a8f8016d64e4642295e135154caccb@haskell.org> Message-ID: <060.dc144cd607908c39685e7d3cdeb0f0a8@haskell.org> #10490: Missing binder type check in coercion equality test? -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Yes it's a bug. But do what you like here. I think you'll have a very hard time tickling this bug, and this code is all going away once kind equalities hits (later this summer, really!). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 7 22:42:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Jun 2015 22:42:39 -0000 Subject: [GHC] #10500: GHC runs out of memory building unicode-properties Message-ID: <042.a6f77d36e28a3c517be1a690a7797835@haskell.org> #10500: GHC runs out of memory building unicode-properties -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Building package https://hackage.haskell.org/package/unicode-properties uses extraordinary amounts of memory with recent compilers - it dies on my 16GB desktop, though the travis build does eventually complete (see it here: https://travis-ci.org/seereason/unicode-properties/builds/65815442.) I have imported the repo to github and untabified it here: https://github.com/seereason/unicode-properties. Building this package was somewhat slow but did complete under ghc-7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 8 01:12:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Jun 2015 01:12:23 -0000 Subject: [GHC] #10500: GHC runs out of memory building unicode-properties In-Reply-To: <042.a6f77d36e28a3c517be1a690a7797835@haskell.org> References: <042.a6f77d36e28a3c517be1a690a7797835@haskell.org> Message-ID: <057.91574e7f3cd73edf6e5d747f3e090367@haskell.org> #10500: GHC runs out of memory building unicode-properties -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dsf): I committed a patch that passes -O0 to one of the modules. This avoids the crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 8 01:14:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Jun 2015 01:14:13 -0000 Subject: [GHC] #10500: GHC runs out of memory building unicode-properties In-Reply-To: <042.a6f77d36e28a3c517be1a690a7797835@haskell.org> References: <042.a6f77d36e28a3c517be1a690a7797835@haskell.org> Message-ID: <057.f85885146c597848335fb4b8435175a2@haskell.org> #10500: GHC runs out of memory building unicode-properties -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dsf): This may only affect 7.10.1 and not 7.10.2 - I can't really test that yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 8 02:49:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Jun 2015 02:49:04 -0000 Subject: [GHC] #10500: GHC runs out of memory building unicode-properties In-Reply-To: <042.a6f77d36e28a3c517be1a690a7797835@haskell.org> References: <042.a6f77d36e28a3c517be1a690a7797835@haskell.org> Message-ID: <057.f2a79f6eb6031f1b7c80f68803c8539d@haskell.org> #10500: GHC runs out of memory building unicode-properties -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: Reproduced in 7.10.1 but not latest ghc-7.10 branch, so declaring already fixed, hooray! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 8 05:27:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Jun 2015 05:27:01 -0000 Subject: [GHC] #10501: Exception in :cmd command can terminate GHCi Message-ID: <046.3e7f0fdfcaaf3fb2b913d50772c6f884@haskell.org> #10501: Exception in :cmd command can terminate GHCi ----------------------------------+------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------+------------------------------- {{{ watashi % ghci -ignore-dot-ghci GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :cmd return $ head [] ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for i386-unknown-linux): Prelude.head: empty list Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 8 06:47:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Jun 2015 06:47:35 -0000 Subject: [GHC] #8353: Easy way to defer type errors In-Reply-To: <047.34842edf8c636f9b11361128b151d960@haskell.org> References: <047.34842edf8c636f9b11361128b151d960@haskell.org> Message-ID: <062.393a139186a994672f1f5ef0787434dc@haskell.org> #8353: Easy way to defer type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D960 -------------------------------------+------------------------------------- Changes (by thomie): * cc: bgamari (added) Comment: Moving design discussion to Trac, so it gets some more attention. bgamari asks in Phab:D960: > Is there consensus that we want to expand the use of the ! suffix on GHCi commands? It seems to me like we might want to consider a slightly less cryptic (albeit more verbose) flag structure to expose this sort of functionality. Currently we have: {{{ :ctags[!] [] create tags file for Vi (default: "tags") (!: use regex instead of line number) :info[!] [ ...] display information about the given names (!: do not filter instances) :kind[!] show the kind of (!: also print the normalised type) }}} The patch in D960 adds: {{{ :load[!] [*] ... load module(s) and their dependents (!: defer type errors) :reload[!] reload the current module set (!: defer type errors) }}} Seems all rather inconsistent, but not a huge problem either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 8 07:51:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Jun 2015 07:51:50 -0000 Subject: [GHC] #9259: GHCi should list its available command line options In-Reply-To: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> References: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> Message-ID: <063.9f4db0704e04d941c003e6df32bb3b5a@haskell.org> #9259: GHCi should list its available command line options -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: kolmodin Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Driver | Version: Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D337 -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:12 thomie]: > I think all work is done here. Well, I think we still didn't solve this: * Some flags are defined in DynFlags but not documented in the User's Guide. Should they be marked as hidden? Mail ghc-devs and find out. I don't think we git any replies about these flags and without that we cannot do better. Not sure if we should keep this ticket open as a reminder? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 8 11:21:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Jun 2015 11:21:38 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.bc39b01241e3f706760d3f88eecd85e2@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * owner: => niteria Comment: @niteria is going to look at this, with help from me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 8 20:41:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Jun 2015 20:41:09 -0000 Subject: [GHC] #10493: Inaccessible code might be accessible with newtypes and Coercible In-Reply-To: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> References: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> Message-ID: <062.7999a907816b950655ea43104abe1143@haskell.org> #10493: Inaccessible code might be accessible with newtypes and Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): It would be nice to combine `typesCantMatch` with the apartness check, but there's a key difference: `typesCantMatch` is about representational equality, but apartness is about nominal equality. In a perfect world, we would combine `typesCantMatch`, `tcMatchTys`, `tcUnifyTys`, and even `eqType`. But these are all subtly different, and the world isn't perfect. So, I propose to leave this for now. I'll update the comments and explain why we can't merge `typesCantMatch`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 8 20:52:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Jun 2015 20:52:11 -0000 Subject: [GHC] #10428: GHC cannot match representations using Coercible constraint In-Reply-To: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> References: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> Message-ID: <062.9dbad0ef4cb014355b2919aacd6b55fa@haskell.org> #10428: GHC cannot match representations using Coercible constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_compile/T10428 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => typecheck/should_compile/T10428 * resolution: => duplicate Comment: Turned out this is a duplicate of #10494, discovered separately. Fix on the way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 8 20:55:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Jun 2015 20:55:20 -0000 Subject: [GHC] #10485: Remove __MINGW32__ from all source files In-Reply-To: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> References: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> Message-ID: <060.f31fe6611b62b66dbce3a518bbfcc56d@haskell.org> #10485: Remove __MINGW32__ from all source files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Berdes Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Berdes): * owner: => Berdes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 8 21:20:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Jun 2015 21:20:27 -0000 Subject: [GHC] #10485: Remove __MINGW32__ from all source files In-Reply-To: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> References: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> Message-ID: <060.f422d5f60fac2fa98e5f8ec402fecedc@haskell.org> #10485: Remove __MINGW32__ from all source files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Berdes Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Berdes): Hello, I'm new to the project and I would like to make this task. I have found many files where {{{__MINGW32__}}} appears. Two of them are on utils and the others are on libraries. Since some of them are under sub-repositories (libraries/filepath for exemple), I'm not able to include them on a commit. What should I do? Note : I've never worked with sub-repositories, so I may have missed something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 8 21:34:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Jun 2015 21:34:18 -0000 Subject: [GHC] #10485: Remove __MINGW32__ from all source files In-Reply-To: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> References: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> Message-ID: <060.14f734851c6aff1d31cff492d13ad90e@haskell.org> #10485: Remove __MINGW32__ from all source files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Berdes Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Berdes): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 8 23:13:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Jun 2015 23:13:48 -0000 Subject: [GHC] #10485: Remove __MINGW32__ from all source files In-Reply-To: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> References: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> Message-ID: <060.a00ff913488f03450645f54d3f05d670@haskell.org> #10485: Remove __MINGW32__ from all source files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Berdes Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => new Comment: Only do the ones in the main repository. The libraries are mostly maintained by others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 8 23:52:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Jun 2015 23:52:58 -0000 Subject: [GHC] #10454: ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset In-Reply-To: <050.2db21865438175ee626af0337216c86d@haskell.org> References: <050.2db21865438175ee626af0337216c86d@haskell.org> Message-ID: <065.043a131b138094e2e01598dd264a1f97@haskell.org> #10454: ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset -------------------------------------+------------------------------------- Reporter: MetaMemoryT | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by tejon): Seeing similar, it started when I upgraded from an older version of MinGHC. In the process I moved from 32 to 64-bit toolchain, and I do see a bunch of "32" in that warning list. That's not my only variable and I haven't done any real testing, but it's the first thing that sticks out at me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 01:39:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 01:39:50 -0000 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images In-Reply-To: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> References: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> Message-ID: <059.047442eef7a53d82452ae55172c0b2e8@haskell.org> #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | thoughtpolice Priority: normal | Status: merge Component: Documentation | Milestone: 7.10.2 Resolution: | Version: 7.10.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D958 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"7944a68f0a91033f50c5d0c56e923948bba30be1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7944a68f0a91033f50c5d0c56e923948bba30be1" Revert "docs: Fix #10416" This causes the buildbots and other users to choke when building the user documentation, but I haven't figured out why. This reverts commit dcaaa980dc59202744bb3888d9662f9a7558cdf6. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 02:23:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 02:23:43 -0000 Subject: [GHC] #10501: Exception in :cmd command can terminate GHCi In-Reply-To: <046.3e7f0fdfcaaf3fb2b913d50772c6f884@haskell.org> References: <046.3e7f0fdfcaaf3fb2b913d50772c6f884@haskell.org> Message-ID: <061.0bd75de7fc428096a0740f127ebd1474@haskell.org> #10501: Exception in :cmd command can terminate GHCi -------------------------------+------------------------------------ Reporter: watashi | Owner: watashi Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D967 -------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => patch * differential: => Phab:D967 * milestone: 7.12.1 => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 02:30:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 02:30:13 -0000 Subject: [GHC] #10442: Loading of shared libraries is problematic in ghc 7.10.1 In-Reply-To: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> References: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> Message-ID: <068.224eab9720299be17e343979f4c69bde@haskell.org> #10442: Loading of shared libraries is problematic in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Ah I see how I was confused about this ticket earlier. I was imagining that `Main` was loaded from an object file and then I didn't understand why the error was with finding `add` rather than `testAdd`. Now I agree the behavior described in this ticket makes sense and that setting an rpath when building the shared library is a logical solution. Running `cabal repl` with `--ghc-option=-fobject-code` does fail with {{{ Preprocessing executable 'illustrate' for illustrate-0.1.0.0... GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Ok, modules loaded: Main. Prelude Main> main ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc4059_0/libghc4059_2.so: undefined symbol: testAdd }}} which is bad (it would link correctly with ghc, so it should just work under ghci), but that's #10458. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 02:48:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 02:48:58 -0000 Subject: [GHC] #10488: Inconsistent reduction of type family In-Reply-To: <047.9df2f686bfc501a9f62f05407ae7e752@haskell.org> References: <047.9df2f686bfc501a9f62f05407ae7e752@haskell.org> Message-ID: <062.ba308cdcb2b14aa9294a0afdb9bc8e2f@haskell.org> #10488: Inconsistent reduction of type family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: Phab:D955 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 02:50:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 02:50:08 -0000 Subject: [GHC] #10489: Panic in TcEvidence due to wrong role In-Reply-To: <047.95d344fe6100d51b3187fc04a692030b@haskell.org> References: <047.95d344fe6100d51b3187fc04a692030b@haskell.org> Message-ID: <062.2434a46d3ce00dda88b633360946fe39@haskell.org> #10489: Panic in TcEvidence due to wrong role -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_compile/T10489 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.12.1 Comment: Doesn't happen with the latest STABLE - but I've gone ahead and added a test to the `ghc-7.10` branch to be sure (see 2237c9818c1cc719560821c3153ac2059094fdd5). Thanks Richard! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 02:50:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 02:50:12 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.48a799a1ac2e726084e5a90d8cc1db70@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+----------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by rwbarton): * milestone: => 7.10.2 Comment: Actually I was wrong about the exact issue being discussed in #10442, but the rest of my comment still applies. Do you have `-fobject-code` set in your cabal file somewhere? Of course what you are trying to do should work even so, but as a workaround you can use the bytecode interpreter. You do need to build your cbits with `-fPIC` here. I thought that Cabal was smart enough to do that automatically, but I guess not? Anyways, a Cabal issue and not a GHC one. Tentatively re-milestoning for 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 03:23:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 03:23:06 -0000 Subject: [GHC] #10492: rpath & shared libraries in ghc 7.10.1 In-Reply-To: <053.8e0d059d0dcafb8986911d4bd2a6c057@haskell.org> References: <053.8e0d059d0dcafb8986911d4bd2a6c057@haskell.org> Message-ID: <068.1e4a9a29a927ecc5943cfb354a0e5492@haskell.org> #10492: rpath & shared libraries in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Isn't this a Cabal bug, not a GHC bug? We don't expect GHC to automatically add rpath entries for C libraries it is told to link against, do we? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 03:38:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 03:38:15 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.5243cf133fef58ca7b1362f3994a430c@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+----------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by rleslie): I do not have `-fobject-code` set in my cabal file. Adding `cc-options: -fPIC` to the cabal file does avoid the first problem I encountered, but the second one remains (with GHCi imploring me to report this as a GHC bug). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 04:17:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 04:17:31 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.a3cc52fb58c8018eb81ebbb2b2a914bd@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+----------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by rwbarton): OK, actually this particular error has nothing to do with loading Haskell modules as object code: cabal is presumably including some cbits `.o` file as an argument to ghci (as it should) and ghci is trying to load it eagerly at startup, and this fails at load time because the pcre library is not visible to the temporary shared library (due to the `RTLD_LOCAL` change). But, the same issue could arise in other settings, for example if a Haskell module that does a foreign import from a shared library is loaded with `-fobject-code`. (Regarding `-fPIC`, I just meant to say that it is expected that you have to use `-fPIC` as you described from the start, at least as far as GHC is concerned.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 04:34:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 04:34:45 -0000 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images In-Reply-To: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> References: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> Message-ID: <059.6c964b8ee5c1ccd71eb3233184231661@haskell.org> #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D958 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: thoughtpolice => * status: merge => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 04:36:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 04:36:38 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.35e7b48b64f5249752eaf7f7eb16fd60@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D924 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.2 => 7.12.1 Comment: From my notes from last week, we're moving this out of 7.10.2, which I forgot about. Punting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 05:10:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 05:10:18 -0000 Subject: [GHC] #10098: Refactor wild card renaming In-Reply-To: <052.6e4b7f96cd090e4532413a4e30b58f3a@haskell.org> References: <052.6e4b7f96cd090e4532413a4e30b58f3a@haskell.org> Message-ID: <067.090d95140aa6866c22f9308a8010d524@haskell.org> #10098: Refactor wild card renaming -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9922 | Blocking: | Differential Revisions: Phab:D613 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"058af6c90a0e8d122f2d1339b6b4fd0b5ec83d05/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="058af6c90a0e8d122f2d1339b6b4fd0b5ec83d05" Refactor wild card renaming Summary: Refactor wild card error reporting * Merge `HsWildcardTy` and `HsNamedWildcardTy` into one constructor `HsWildCardTy` with as field the new type `HsWildCardInfo`, which has two constructors: `AnonWildCard` and `NamedWildCard`. * All partial type checks are removed from `RdrHsSyn.hs` and are now done during renaming in order to report better error messages. When wild cards are allowed in a type, the new function `rnLHsTypeWithWildCards` (or `rnHsSigTypeWithWildCards`) should be used. This will bring the named wild cards into scope before renaming them. When this is not done, renaming will trigger "Unexpected wild card..." errors. Unfortunately, this has to be done separately for anonymous wild cards because they are given a fresh name during renaming, so they will not cause an out-of-scope error. They are handled in `tc_hs_type`, as a special case of a lookup that fails. The previous opt-out approach is replaced with an opt-in approach. No more panics because of forgotten checks! * `[t| _ |]` isn't caught by the above two checks, so it is currently handled by a special case. The error message (generated in the `DsM` monad) doesn't provide as much context information as the other cases. * Instead of three (!) functions that walk `HsType`, there is now only one pure function called `collectWildCards`. * Alternative approach: catch all unwanted wild cards in `rnHsTyKi` by looking at the `HsDocContext`. This will reduce the number of places to catch unwanted wild cards form three to one, and make the error messages more uniform, albeit less informative, as the error context for renaming is not as informative as the one for type checking. A new constructor of `HsDocContext` will be required for pattern synonyms signatures. Small problem: currently type-class type signatures can't be distinguished from type signatures using the `HsDocContext`. This requires an update to the Haddock submodule. Test Plan: validate Reviewers: goldfire, simonpj, austin Reviewed By: simonpj Subscribers: bgamari, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D613 GHC Trac Issues: #10098 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 05:24:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 05:24:39 -0000 Subject: [GHC] #10196: Regression regarding Unicode subscript characters in identifiers In-Reply-To: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> References: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> Message-ID: <060.94cc2735fbd96c44cdb7395759515aa7@haskell.org> #10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | thoughtpolice Priority: normal | Status: patch Component: Compiler | Milestone: 7.10.2 (Parser) | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #5108 | Differential Revisions: Phab:D969 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch * differential: => Phab:D969 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 05:52:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 05:52:58 -0000 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images In-Reply-To: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> References: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> Message-ID: <059.e19fa6f7ca66daa01854a9e7f4973db6@haskell.org> #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D958, | Phab:D970 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch * differential: Phab:D958 => Phab:D958, Phab:D970 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 08:04:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 08:04:35 -0000 Subject: [GHC] #10485: Remove __MINGW32__ from all source files In-Reply-To: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> References: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> Message-ID: <060.f7d8a08bd89e15460807e1db6476c40d@haskell.org> #10485: Remove __MINGW32__ from all source files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Berdes Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D971 -------------------------------------+------------------------------------- Changes (by Berdes): * status: new => patch * differential: => Phab:D971 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 08:56:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 08:56:38 -0000 Subject: [GHC] #10502: Bad interaction of sandboxes and coverage Message-ID: <045.511b135d0a4be356420d6101f7379df4@haskell.org> #10502: Bad interaction of sandboxes and coverage -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code | Version: 7.10.1 Coverage | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It seems that when using sandboxes with project and coverage (`--enable- coverage`) cabal fails to generate and find .mix files for dependencies. Steps to reproduce: 1. create shared sandbox (not sure that shared sandbox plays it's role here): {{{cabal sandbox init --sandbox=../.shared}}} 2. install all dependencies with enable-coverage {{{cabal install --dependencies-only --enable-coverage --enable-tests}}} 3. install library {{{cabal install --enable-coverage --run-tests}}} Expected results: 1. Library will be built, coverage output will be generated. Actual results: hpc fails to find .mix files: {{{ hpc: can not find netwo_Bdsn6Y1VKLa3MCczwSV70J/Network.Socket.ByteString.MsgHdr in ["./.hpc" ,"./dist/dist-sandbox-f7da581b/hpc/vanilla/mix/network-transport- tcp-0.4.1" ,"./dist/dist-sandbox-f7da581b/hpc/vanilla/mix/TestTCP"] }}} Tested on ghc-7.10.1 in clear official docker container on network- transport-tcp package. Side node: during tests on bigger project I have seen similar failures even on step 2 (e.g. network package fails with similar error message), but I was not able to reproduce it in minimal example. Possibly related report: #10259 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 10:40:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 10:40:11 -0000 Subject: [GHC] #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! In-Reply-To: <050.69a1127c662d09f1c26088e7d11c9d3b@haskell.org> References: <050.69a1127c662d09f1c26088e7d11c9d3b@haskell.org> Message-ID: <065.c594ab89b0359c4a8d710bb9233e7ece@haskell.org> #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D956 Related Tickets: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a48167eaaa984fbdc1ad31c2c674058ba3669ac6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a48167eaaa984fbdc1ad31c2c674058ba3669ac6" build: Clean testsuite before sdist When making the `sdist` tarball, we don't really need anything inside $(TOP)/testsuite in order to do our thing. So make sure we clean it first to avoid situations like #10406. With D917 landed, this can actually avoided entirely by fixing the official release process to instead build an `sdist` //first// from the clean git repository and then build that (to fixpoint) and test it. Then the originall clean tarball can be shipped. But it's nice to be safe in the general case where someone might want to (in the future) `sdist` out of their build tree. Signed-off-by: Austin Seipp Reviewed By: thomie Differential Revision: https://phabricator.haskell.org/D956 GHC Trac Issues: #10406 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 10:44:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 10:44:30 -0000 Subject: [GHC] #10501: Exception in :cmd command can terminate GHCi In-Reply-To: <046.3e7f0fdfcaaf3fb2b913d50772c6f884@haskell.org> References: <046.3e7f0fdfcaaf3fb2b913d50772c6f884@haskell.org> Message-ID: <061.7cccc43d7a641125fb9eb55f89a7fb53@haskell.org> #10501: Exception in :cmd command can terminate GHCi -------------------------------+------------------------------------ Reporter: watashi | Owner: watashi Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D967 -------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"3b55659d4f54e503f4e550d762bc55a2650ed13d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3b55659d4f54e503f4e550d762bc55a2650ed13d" Always force the exception in enqueued commands `enqueueCommands` should always force exception in commands. Otherwise the exception thrown in `:cmd` (e.g. `:cmd return $ head []`) will cause GHCi to terminate with panic. Test Plan: `cd testsuite/tests/ghci/ && make` Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D967 GHC Trac Issues: #10501 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 10:46:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 10:46:13 -0000 Subject: [GHC] #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! In-Reply-To: <050.69a1127c662d09f1c26088e7d11c9d3b@haskell.org> References: <050.69a1127c662d09f1c26088e7d11c9d3b@haskell.org> Message-ID: <065.09b4aadbc0df1e9b442ee7cf36cf7826@haskell.org> #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D956 Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 10:46:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 10:46:26 -0000 Subject: [GHC] #10501: Exception in :cmd command can terminate GHCi In-Reply-To: <046.3e7f0fdfcaaf3fb2b913d50772c6f884@haskell.org> References: <046.3e7f0fdfcaaf3fb2b913d50772c6f884@haskell.org> Message-ID: <061.cf700b9847c5a81e998e6c7d6a5b5eb6@haskell.org> #10501: Exception in :cmd command can terminate GHCi -------------------------------+------------------------------------ Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D967 -------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 11:26:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 11:26:35 -0000 Subject: [GHC] #10441: msys native python testsuite support doesn't work in some situations In-Reply-To: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> References: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> Message-ID: <060.f95291f175983e779a54300fe08ad4d1@haskell.org> #10441: msys native python testsuite support doesn't work in some situations -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D952 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"bb9967121f2383b857680b47b6bc20607f8fd1ff/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bb9967121f2383b857680b47b6bc20607f8fd1ff" Revert "The test runner now also works under the msys-native Python." To make the test runner work under msys-native Python... Commit 5258566ee5c89aa757b0cf1433169346319c018f broke the msys testsuite driver (#10441). It changed the quoting of `config.compiler` from single quotes to double quote, which turns out to not be compatible with what the function `passThroughCmd` expected. We could fix `passThroughCmd` to handle the case where `config.compiler` is double quoted, and scatter some notes around to make sure the quoting done in various places of the testsuite driver stay compatible. Instead, this commit reverts 101c62e26286353dd3fac1ef54323529b64c9902, which introdced the function `passThroughCmd` in the first place (#9626). ezyang reports that doing this revert fixes the testsuite driver for him using the the following version of msys2: msys2-keyring r8.3864337-1 msys2-runtime 2.1.0.16351.cd3184b-1 msys2-runtime-devel 2.1.0.16351.cd3184b-1 msys2-w32api-headers 5.0.0.4456.c8b6742-1 msys2-w32api-runtime 5.0.0.4455.32db221-1 Ideally we'd know what minimum version of msys2 we require, but for now this fix is better than nothing. Only gintas ever reported the original problem, and he actually mentioned shortly afterwards: "This may have been fixed by a recent release of msys2, but I am not sure." Differential Revision: https://phabricator.haskell.org/D952 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 11:26:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 11:26:35 -0000 Subject: [GHC] #9626: Test command lines munged on Windows when running on msys Python In-Reply-To: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> References: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> Message-ID: <060.f924600e024e9ae66ed3d70aa285af44@haskell.org> #9626: Test command lines munged on Windows when running on msys Python -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"bb9967121f2383b857680b47b6bc20607f8fd1ff/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bb9967121f2383b857680b47b6bc20607f8fd1ff" Revert "The test runner now also works under the msys-native Python." To make the test runner work under msys-native Python... Commit 5258566ee5c89aa757b0cf1433169346319c018f broke the msys testsuite driver (#10441). It changed the quoting of `config.compiler` from single quotes to double quote, which turns out to not be compatible with what the function `passThroughCmd` expected. We could fix `passThroughCmd` to handle the case where `config.compiler` is double quoted, and scatter some notes around to make sure the quoting done in various places of the testsuite driver stay compatible. Instead, this commit reverts 101c62e26286353dd3fac1ef54323529b64c9902, which introdced the function `passThroughCmd` in the first place (#9626). ezyang reports that doing this revert fixes the testsuite driver for him using the the following version of msys2: msys2-keyring r8.3864337-1 msys2-runtime 2.1.0.16351.cd3184b-1 msys2-runtime-devel 2.1.0.16351.cd3184b-1 msys2-w32api-headers 5.0.0.4456.c8b6742-1 msys2-w32api-runtime 5.0.0.4455.32db221-1 Ideally we'd know what minimum version of msys2 we require, but for now this fix is better than nothing. Only gintas ever reported the original problem, and he actually mentioned shortly afterwards: "This may have been fixed by a recent release of msys2, but I am not sure." Differential Revision: https://phabricator.haskell.org/D952 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 11:32:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 11:32:55 -0000 Subject: [GHC] #10441: msys native python testsuite support doesn't work in some situations In-Reply-To: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> References: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> Message-ID: <060.de8d3206265e0251faaa40962db408d1@haskell.org> #10441: msys native python testsuite support doesn't work in some situations -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.2 Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D952 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => merge * version: 7.11 => 7.10.1 * milestone: 7.12.1 => 7.10.2 Comment: Please merge to ghc-7.10, as that branch also contains the patch that changed the quoting (dde3a2378e3961f7eed82d07d2f1e904878cc2b0, #10164). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 11:36:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 11:36:04 -0000 Subject: [GHC] #10493: Inaccessible code might be accessible with newtypes and Coercible In-Reply-To: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> References: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> Message-ID: <062.fd2aaf1e0eba74a7a7d3686bfe5744d4@haskell.org> #10493: Inaccessible code might be accessible with newtypes and Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:3 goldfire]: > It would be nice to combine `typesCantMatch` with the apartness check, but there's a key difference: `typesCantMatch` is about representational equality, but apartness is about nominal equality. I don't agree at all! If you look at the single call to `typesCantMatch` you'll see that it's passed a list of '''Nominal''' equalities, namely the ones bound by the GADT. Admittedly this is not documented, and it should be. But it's true. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 11:36:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 11:36:57 -0000 Subject: [GHC] #10441: msys native python testsuite support doesn't work in some situations In-Reply-To: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> References: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> Message-ID: <060.349ef85be0b7ddc7696aedd0601907d3@haskell.org> #10441: msys native python testsuite support doesn't work in some situations -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Test Suite | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D952 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 12:20:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 12:20:17 -0000 Subject: [GHC] #10503: The impossible happened (no skolem info) - untouchable kind variable Message-ID: <052.5d02a2c16ec59101e0384598dc01335f@haskell.org> #10503: The impossible happened (no skolem info) - untouchable kind variable -------------------------------------+------------------------------------- Reporter: | Owner: AlekseyKliger | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: | crash Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE RankNTypes, PolyKinds, DataKinds, TypeFamilies #-} module GHCBug where data Proxy p = Proxy data KProxy (a :: *) = KProxy h :: forall r . (Proxy ('KProxy :: KProxy k) ~ Proxy ('KProxy :: KProxy *) => r) -> r h = undefined }}} GHC reports {{{ GHCBug.hs:8:6: Couldn't match kind ?k? with ?*? ?k? is untouchable inside the constraints (Proxy 'KProxy ~ Proxy 'KProxy) bound by the type signature for h :: (Proxy 'KProxy ~ Proxy 'KProxy) => r at GHCBug.hs:8:6-87ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): No skolem info: k_amc[sk] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 12:31:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 12:31:52 -0000 Subject: [GHC] #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! In-Reply-To: <050.69a1127c662d09f1c26088e7d11c9d3b@haskell.org> References: <050.69a1127c662d09f1c26088e7d11c9d3b@haskell.org> Message-ID: <065.f0c52fce002947d7844ea4627b6af5ca@haskell.org> #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D956 Related Tickets: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"5828457d8d26fd33130d4b5850847c9a73a8d3e5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5828457d8d26fd33130d4b5850847c9a73a8d3e5" make sdist: distclean testsuite for real (#10406) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 12:32:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 12:32:55 -0000 Subject: [GHC] #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! In-Reply-To: <050.69a1127c662d09f1c26088e7d11c9d3b@haskell.org> References: <050.69a1127c662d09f1c26088e7d11c9d3b@haskell.org> Message-ID: <065.c59f066f4a44dee550979c64197c31ad@haskell.org> #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D956 Related Tickets: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => merge Comment: Fix up previous commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 13:03:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 13:03:37 -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.a1405cd7138f38848cefb818446f63dd@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) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by thomie): * os: Windows => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 13:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 13:23:08 -0000 Subject: [GHC] #7428: GHC compile times are seriously non-linear in program size In-Reply-To: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> References: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> Message-ID: <060.4e25b2691fbf06008adaa2dcf15a8d25@haskell.org> #7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): I've updated the test case. By default, even on my monster build machine, it looks like the compilation of this test is literally never going to finish, so it needs to be toned down to look at it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 13:26:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 13:26:53 -0000 Subject: [GHC] #10289: compiling huge HashSet hogs memory In-Reply-To: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> References: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> Message-ID: <059.2979903e011885e2e7e5c617250f5fda@haskell.org> #10289: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): After looking back at my tests, the situation should be significantly better with GHC 7.10.2 based on my quick examination; the resident memory usage for me at least looks to be closer to 2GB on my machine. However, the total build time seems to be worse (1m52s to compile `EntrySet` at `-O2` vs your Travis machines ~30 seconds, but only a maximum residency of 2GB). So there's still more to be done here, but enabling -O2 shouldn't cripple you anymore at least. Would you mind giving this a go with the latest `ghc-7.10` branch (or the 7.10.2 RC, which will be out soon?) You can use Herbert's PPA in combination with travis to get automated testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 13:44:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 13:44:51 -0000 Subject: [GHC] #7428: GHC compile times are seriously non-linear in program size In-Reply-To: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> References: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> Message-ID: <060.f48843702a825a9a1e860d3d06f208a1@haskell.org> #7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Here's a smaller version (that actually completes in a reasonable amount of time), along with a profile. Something is definitely quadratic or something around `CorePrep`/`TidyCore`; when run with `-v3`, I estimate `CorePrep` alone takes about 20 seconds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 13:46:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 13:46:32 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.0f1540c70998ac40b27903e7796322eb@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): I've attached a quick profile from looking at this, and it looks like there's still more room to do around `TidyCore`/`CorePrep` in this area. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 13:47:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 13:47:06 -0000 Subject: [GHC] #7428: GHC compile times are seriously non-linear in program size In-Reply-To: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> References: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> Message-ID: <060.940bd7ad6d9195838d356b70de29dcb6@haskell.org> #7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): (For a build that's about 1 minute, FWIW) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 14:14:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 14:14:23 -0000 Subject: [GHC] #10504: GHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabled Message-ID: <042.80c23fb36e07186e80db084dbbf4d79a@haskell.org> #10504: GHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Minimal example code: https://github.com/nh2/ghc-omit-interface-pragmas- dsImpSpecs-bug/ I'm encountering a problem that prevents me from using Haskell program coverage on a code base, getting a GHC panic referring to `dsImpSpecs`. This looks pretty much like this old bug: https://ghc.haskell.org/trac/ghc/ticket/4870 I checked that it happens on GHC 7.8.4 and GHC 7.10.1. ---- The problem happens when I run `cabal build --ghc-options "-fhpc"`, giving me {{{ Package has never been configured. Configuring with default flags. If this fails, please run configure manually. Resolving dependencies... Configuring ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0... Building ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0... Preprocessing library ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0... [1 of 2] Compiling A ( src/A.hs, dist/build/A.o ) [2 of 2] Compiling B ( src/B.hs, dist/build/B.o ) src/B.hs:5:1: Warning: SPECIALISE pragma for non-overloaded function ?myfun? ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): dsImpSpecs ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0:A.myfun{v rpu} [gid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 $ cabal --version cabal-install version 1.18.0.8 using version 1.18.1.5 of the Cabal library }}} This doesn't happen when I compile directly with `ghc --make`: {{{ $ cd src && ghc --make -fhpc -fomit-interface-pragmas B.hs -Wall [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) }}} So running cabal with `-v`, I see that the problem happens in: {{{ /home/niklas/opt/ghc-7.8/bin/ghc --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -isrc -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -package-name ghc-omit-interface- pragmas-dsImpSpecs-bug-0.1.0.0 -hide-all-packages -package-db dist/package.conf.inplace -package-id base-4.7.0.2-bfd89587617e381ae01b8dd7b6c7f1c1 -XHaskell98 B A -Wall -fhpc [1 of 2] Compiling A ( src/A.hs, dist/build/A.o ) [2 of 2] Compiling B ( src/B.hs, dist/build/B.o ) src/B.hs:5:1: Warning: SPECIALISE pragma for non-overloaded function ?myfun? ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): dsImpSpecs ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0:A.myfun{v rpu} [gid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} So there it be some flag that cabal passes to GHC that makes this GHC crash appear. Nevertheless, it's a panic, so I guess it's a bug in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 14:18:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 14:18:57 -0000 Subject: [GHC] #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! In-Reply-To: <050.69a1127c662d09f1c26088e7d11c9d3b@haskell.org> References: <050.69a1127c662d09f1c26088e7d11c9d3b@haskell.org> Message-ID: <065.18bde4f65a7327c5a0fc93e231739c57@haskell.org> #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D956 Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Already merged, thanks Thomas! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 14:19:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 14:19:06 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize In-Reply-To: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> References: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> Message-ID: <057.4d99ff0abe95b7b1a2229ee15acfa3ad@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D938, | Phab:D961 -------------------------------------+------------------------------------- Comment (by thoughtpolice): In lieu of Phab:D961 getting flagged by Simon, I'm going to move this out of 7.10.2 - archblob, if you fix it up before the end of this week (when I'd like to do the RC), please just remilestone it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 14:19:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 14:19:33 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize In-Reply-To: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> References: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> Message-ID: <057.5907404fca08dcfb275b1a4a215b738c@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D938, | Phab:D961 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.2 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 14:26:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 14:26:03 -0000 Subject: [GHC] #10443: Regression in forall typechecking In-Reply-To: <044.7362b4be773be0b820eb3b3df909767a@haskell.org> References: <044.7362b4be773be0b820eb3b3df909767a@haskell.org> Message-ID: <059.a3e3db2d9a2e70a9063a08aef62d507d@haskell.org> #10443: Regression in forall typechecking -------------------------------------+------------------------------------- Reporter: alanz | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, it's a change in behaviour from 7.10.1 to 7.10.2; but of course all bug-fixes are! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 14:28:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 14:28:41 -0000 Subject: [GHC] #10504: GHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabled In-Reply-To: <042.80c23fb36e07186e80db084dbbf4d79a@haskell.org> References: <042.80c23fb36e07186e80db084dbbf4d79a@haskell.org> Message-ID: <057.6670aea39e43d73f43c519af849f8eaa@haskell.org> #10504: GHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nh2): Ok, I found what makes the difference, `-O` is the culprit. With `-O`: {{{ $ ghc --make -O -isrc B A -Wall -fhpc [2 of 2] Compiling B ( src/B.hs, src/B.o ) src/B.hs:5:1: Warning: SPECIALISE pragma for non-overloaded function ?myfun? ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): dsImpSpecs main:A.myfun{v r0} [gid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Without `-O`: {{{ $ ghc --make -isrc B A -Wall -fhpc [2 of 2] Compiling B ( src/B.hs, src/B.o ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 14:30:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 14:30:48 -0000 Subject: [GHC] #10504: GHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabled In-Reply-To: <042.80c23fb36e07186e80db084dbbf4d79a@haskell.org> References: <042.80c23fb36e07186e80db084dbbf4d79a@haskell.org> Message-ID: <057.f50ff7c8bb9ee827b133dede2d6eb2d7@haskell.org> #10504: GHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nh2): By the way, ignore the fact that the repository has `omit-interface- pragmas` in its name - I originally thought that this problem only happens when I enable `-fomit-interface-pragmas`, but it already happens on plain `-fhpc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 14:52:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 14:52:06 -0000 Subject: [GHC] #10502: Bad interaction of sandboxes and coverage In-Reply-To: <045.511b135d0a4be356420d6101f7379df4@haskell.org> References: <045.511b135d0a4be356420d6101f7379df4@haskell.org> Message-ID: <060.222d3841ae7ec776892fa07910df92f4@haskell.org> #10502: Bad interaction of sandboxes and coverage -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: This is a Cabal issue, not a GHC issue. Cabal does not really support installing packages built with `--enable-coverage`. The installation will succeed, and the libraries themselves work, but Cabal does not install the `.mix` files anywhere, so running hpc on a program that uses the libraries will fail, as you found. You can just omit `--enable-coverage` from the `install --dependencies- only` command to get a coverage report that includes the modules from the library you are testing (here network-transport-tcp). If you really want to get a report of how the network-transport-tcp tests cover the modules in its dependencies, then you need support for this to be added to Cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 14:54:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 14:54:51 -0000 Subject: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.7180713f87f362955329f18436778121@haskell.org> #10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8004, #4384 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Notes from conversation with Herbert and Simon PJ. Proposed data types: {{{ data Warnings = ... | WarnSome [WarnItem] data WarnItem = WI OccName WarnInfo (Located SourceText) [Located (SourceText,FastString)] data WarnInfo = Warning | DeprecTop | DeprecMeth }}} The new bit is the `DeprecMeth`. Need updated ticket description, or wiki page, to give examples of the different behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 15:01:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 15:01:43 -0000 Subject: [GHC] #10259: HPC code coverage fails In-Reply-To: <051.5eb6d52bae1ecbfd49110a391027e287@haskell.org> References: <051.5eb6d52bae1ecbfd49110a391027e287@haskell.org> Message-ID: <066.dfb33b0670762b92c71e19683c40d142@haskell.org> #10259: HPC code coverage fails -------------------------------------+------------------------------------- Reporter: LukeHoersten | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: hpc Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Right, actually the problem specifically is that Cabal doesn't install the `.mix` files anywhere when installing a package built with `--enable- coverage`. So effectively you never want to use `cabal install --enable- coverage`. This is a Cabal issue, not a GHC issue. > Also, it's unclear to me when to use -fhpc vs. --enable-coverage. Is there anywhere this is documented? `-fhpc` is an option to GHC, and `--enable-coverage` is an option to cabal-install. If you use `--enable-coverage` then Cabal will take care of passing `-fhpc` to GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 19:48:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 19:48:57 -0000 Subject: [GHC] #8842: Make sure msys2 builds non emulating binaries In-Reply-To: <046.86a6364bab91651953306fe81692398f@haskell.org> References: <046.86a6364bab91651953306fe81692398f@haskell.org> Message-ID: <061.855fce81e5a80b0cbde977fce5237511@haskell.org> #8842: Make sure msys2 builds non emulating binaries -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: task | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: msys2 Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * milestone: => 7.12.1 Comment: On Windows, GHC uses a mingw gcc compiler. This command shows that it does define the `_WIN32` macro: {{{ $ /opt/ghc-7.8.3/mingw/bin/gcc -dM -E -x c /dev/null | grep ' _WIN32' #define _WIN32 1 }}} I also compiled a small c program containing an `#ifdef _WIN32` block on Windows using `ghc -c`, and it indeed showed that `_WIN32` is defined. The [wiki:Building/Preparation/Windows build instruction on Windows] for GHC itself are also pretty clear to use the non-emulating version of MSYS2. Anything else I can do to check this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 20:04:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 20:04:16 -0000 Subject: [GHC] #9101: Need option to use system gcc and binutils on Windows/msys2 In-Reply-To: <047.9aaf79de73007bb10bd989466d9c86e1@haskell.org> References: <047.9aaf79de73007bb10bd989466d9c86e1@haskell.org> Message-ID: <062.230f993fcf156d6ca6a0ab72c5b5c4f4@haskell.org> #9101: Need option to use system gcc and binutils on Windows/msys2 -------------------------------------+------------------------------------- Reporter: cchantep | Owner: gintas Type: feature request | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9218 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: > Trying to build GHC 7.8.2 from sources on Windows 7, from msys2 shell, required binaries such as gcc, ld, ar are forced to those in inplace directories (windows-extra) I understand this is by design. Quoting Simon in this [https://mail.haskell.org/pipermail/ghc-devs/2014-June/005174.html email] to ghc-devs: "We physically include very selective chunks of MinGW in a GHC Windows distribution - so that users don't need to install MinGW - so that GHC doesn't break just because a user has a different version of MinGW than we expected We keep these chunks of MinGW in the GHC repo (in ghc-tarballs) precisely so that we know exactly which bits to ship. The intention is that the MinGW bits shipped with GHC are essentially invisible to the user. They just see a ghc.exe, which just happens internally to call some Mingw binaries." But the version of MinGW shipped with GHC at the moment is indeed out of date. Please subscribe to #9218 for updates. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 20:07:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 20:07:40 -0000 Subject: [GHC] #9663: Windows build process should give better message if you forgot to clone tarballs In-Reply-To: <045.1da0869ddf56108fdfa02fd69e07ae82@haskell.org> References: <045.1da0869ddf56108fdfa02fd69e07ae82@haskell.org> Message-ID: <060.8c29b871647c5e0cb4b01566c9d1b55a@haskell.org> #9663: Windows build process should give better message if you forgot to clone tarballs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.9 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9218 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: With #9218 and Phab:D339 the intention is to download the mingw toolchain on the fly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 9 20:23:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Jun 2015 20:23:18 -0000 Subject: [GHC] #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc In-Reply-To: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> References: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> Message-ID: <057.06bf71ec71a0977497da73c0c0ef7885@haskell.org> #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc -------------------------------------+------------------------------------- Reporter: nwf | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9883 | Blocking: 9883 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by s9gf4ult): Hello. I propose little different solution. I dont think we should put methods `isNil` and `uncons` inside of this proposal, because they do not relate with lists construction. Here is full example of my proposal: {{{#!hs {-# LANGUAGE FlexibleInstances , TypeOperators , TypeFamilies , DataKinds , GADTs #-} import GHC.TypeLits -- | Types which can be constructed with 'cons' should instantiate this class Cons a where type Head a :: * type Tail a :: * cons :: Head a -> Tail a -> a -- | And types which is a empty list should instantiate this class Nil a where nil :: a --------------------------------- -- Simple homogenous lists -- --------------------------------- instance Cons [a] where type Head [a] = a type Tail [a] = [a] cons elem b = elem:b instance Nil [a] where nil = [] -- | synoym for '[10, 20, 42]' justList :: [Int] justList = cons 10 $ cons 20 $ cons 42 $ nil ------------------------------- -- Simple heterogenous lists -- ------------------------------- -- | Simple heterogenous list data HList (typs :: [*]) where HNil :: HList '[] HCons :: typ -> HList typs -> HList (typ ': typs) instance Cons (HList (t ': ts)) where type Head (HList (t ': ts)) = t type Tail (HList (t ': ts)) = HList ts cons = HCons instance Nil (HList '[]) where nil = HNil -- | synonym of '[10, 20, "hello"]' hlist :: HList '[Int, Integer, String] hlist = cons 10 $ cons 20 $ cons "hello" nil --------------------------------------------------------------------------- -- More complex heterogenous list with constraints for it's elements -- --------------------------------------------------------------------------- -- | Checks that element contained in type list type family Elem (typ :: *) (typs :: [*]) :: Bool where Elem typ '[] = 'False Elem typ (typ ': typs) = 'True Elem typ1 (typ2 ': typs) = Elem typ1 typs -- | Heterogenous list with uniq elements data UniqHList (typs :: [*]) where UHNil :: UniqHList '[] UHCons :: ('False ~ (Elem typ typs)) => typ -> UniqHList typs -> UniqHList (typ ': typs) -- | Look at instance constraint, it is the same constraint as in -- 'UHCons' constructor instance ('False ~ (Elem t ts)) => Cons (UniqHList (t ': ts)) where type Head (UniqHList (t ': ts)) = t type Tail (UniqHList (t ': ts)) = UniqHList ts cons = UHCons instance Nil (UniqHList '[]) where nil = UHNil -- | This should be written as '[10, "string", 42.2, 20]' uniqHlist :: UniqHList '[Integer, String, Double, Int] uniqHlist = cons 10 $ cons "string" $ cons 42.2 $ cons 20 nil --------------------------------------- -- Vectors parametrized with length -- --------------------------------------- data Vector (len :: Nat) a where VNil :: Vector 0 a VCons :: a -> Vector len a -> Vector (len + 1) a -- | Look at the constraint again. It is a little hackish because GHC -- can not infer that __len ~ ((len - 1) + 1)__ instance (len ~ ((len - 1) + 1)) => Cons (Vector len a) where type Head (Vector len a) = a type Tail (Vector len a) = Vector (len - 1) a cons = VCons instance Nil (Vector 0 a) where nil = VNil vector :: Vector 3 Int vector = cons 1 $ cons 2 $ cons 3 $ nil }}} It is compilable and contains instances for some complex cases. The method `cons` shoud be considered as `(:)` and `nil` should become `[]`. What do you think? Cheers! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 04:27:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 04:27:32 -0000 Subject: [GHC] #10367: "ghc: panic! (the 'impossible' happened)" In-Reply-To: <046.238a760b2e418cfdcf3889e9cb306409@haskell.org> References: <046.238a760b2e418cfdcf3889e9cb306409@haskell.org> Message-ID: <061.e8e085e8f7439ae23d2f4c74aecea629@haskell.org> #10367: "ghc: panic! (the 'impossible' happened)" -------------------------------------+------------------------------------- Reporter: bgwines | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: panic Operating System: MacOS X | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Tyilo): * cc: asgerdrewsen@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 04:32:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 04:32:30 -0000 Subject: [GHC] #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc In-Reply-To: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> References: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> Message-ID: <057.0aef5bfb960f7d89bb9a2b679db336c8@haskell.org> #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc -------------------------------------+------------------------------------- Reporter: nwf | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9883 | Blocking: 9883 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): hrm, thats an intersting take the analogous design I was playing with was {{{#!hs class HetCons (f:: k -> * ) (f':: m -> * ) (h :: * ) (tl:: k) (res :: m) | f-> f', f'-> f ,f h tl -> res , f h res -> tl, f res tl -> h , f' res -> h , f tl res -> h , f' tl res -> h where hcons :: h -> f tl -> f' res class HetNil nil where -- (f:: k -> * ) (a :: k) where hnil :: nil }}} i have a few example instances in https://github.com/cartazio/HetList/blob/master/HetList.hs, and type inference would work out pretty nicely. one idea that i dont think we've articulated or explored properly is understanding how to use pattern synonym machinery to overload pattern matching list syntax or something! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 07:19:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 07:19:52 -0000 Subject: [GHC] #7428: GHC compile times are seriously non-linear in program size In-Reply-To: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> References: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> Message-ID: <060.35bafe1d7f756b11e69785b0a76a8b13@haskell.org> #7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 07:21:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 07:21:16 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.0debf84bfedc7c065306f7143065e069@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 07:26:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 07:26:05 -0000 Subject: [GHC] #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc In-Reply-To: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> References: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> Message-ID: <057.5489e4e3289cc26c6e08cff6f695221e@haskell.org> #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc -------------------------------------+------------------------------------- Reporter: nwf | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9883 | Blocking: 9883 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by s9gf4ult): Your example is much more complex, why so many parameters in `HetCons` and functional dependencies? Pattern matching overload is interesting idea. Pattern `(x:xs)` should be considered by compiler as `HCons x xs` for `HList`, but compiler knowns about `HList` just after type inference and see pattern `(x:xs)` after parsing and desugaring, so pattern `(x:xs)` must be replaced with `HCons x xs` after type inference somehow. I am not very familiar with GHC internals anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 08:54:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 08:54:10 -0000 Subject: [GHC] #10348: HEAD: `KnownNat` does not imply `Typeable` any more In-Reply-To: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> References: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> Message-ID: <063.4d88fd385fd75308ed6fddfee7120443@haskell.org> #10348: HEAD: `KnownNat` does not imply `Typeable` any more -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: diatchki Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by heisenbug): Ping. Any chance to fix this, so that I can swim with GHC master again? ''Iavor, if you are buried in other stuff I could look into this myself.'' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 09:32:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 09:32:52 -0000 Subject: [GHC] #9769: User's Guide missing from Windows binary distributions In-Reply-To: <051.92b9ec823fa5402a4972db991a6f829e@haskell.org> References: <051.92b9ec823fa5402a4972db991a6f829e@haskell.org> Message-ID: <066.ba456a3cbdfff5c8a086daef777f6219@haskell.org> #9769: User's Guide missing from Windows binary distributions -------------------------------------+------------------------------------- Reporter: Dangthrimble | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge * milestone: 7.12.1 => 7.10.2 Comment: Running `pacman -Sy docbook-xsl` on the machine where the windows bindist is build should solve this. I tested it. Note: no postscript or pdf though, since pacman on msys2 doesn't have dblatex. I updated [wiki:Building/Preparation/Windows]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 09:40:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 09:40:28 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.bbf9c661b35953f7a8e16cca4dba8a1c@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: low | Milestone: Component: hsc2hs | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Build System => hsc2hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 10:47:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 10:47:02 -0000 Subject: [GHC] #10267: Add support for typed holes in Template Haskell In-Reply-To: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> References: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> Message-ID: <063.751ee54c7b14748b3cfa7202a0b18485@haskell.org> #10267: Add support for typed holes in Template Haskell -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D835 -------------------------------------+------------------------------------- Comment (by jstolarek): I'd appreciate if anyone with more knowledge of name handling inside the renamer could take a look at the Phab revision. I'm blocked with this ticket at the moment but would love to push it forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 13:00:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 13:00:49 -0000 Subject: [GHC] #10505: more specific types in the generated *_stub.h files Message-ID: <042.0c58a835030516b3c843e8f17d99b20d@haskell.org> #10505: more specific types in the generated *_stub.h files -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.1 Component: Compiler | Operating System: Linux (FFI) | Type of failure: Other Keywords: | Blocked By: Architecture: | Related Tickets: #2979, #8222 Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Having a declaration like: {{{#!hs foreign export ccall "respond" respond :: CWString -> IO CWString }}} all the types in the corresponding `_stub.h` are `HsPtr`. Wouldn't it be possible to write more specific types reflecting my expectations, i.e., `wchar_t *`? It would be nice in order to signal automatically to the C code which uses the Haskell functions that the types of the Haskell functions changed. In simple cases, one could simply include the stub.h, and get automatically an error if the C code doesn't match the new types. I've tried using a CTYPE pragma (cf. #2979 , #8222 ) on a newtype to get such results: {{{#!hs newtype {-# CTYPE "wchar_t *" #-} CWString' = CWString' CWString foreign export ccall "respond" respond :: CWString' -> IO CWString }}} but that still produces `HsPtr`. (Well, I see, the CTYPE pragma was mostly intended for imports rather than exports.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 13:18:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 13:18:18 -0000 Subject: [GHC] #10505: more specific types in the generated *_stub.h files In-Reply-To: <042.0c58a835030516b3c843e8f17d99b20d@haskell.org> References: <042.0c58a835030516b3c843e8f17d99b20d@haskell.org> Message-ID: <057.dc697a84f7521d6daf9a487313e9604b@haskell.org> #10505: more specific types in the generated *_stub.h files -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #2979, #8222 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by imz): The same problem and wish as mine are illustrated in http://stackoverflow.com/q/23629000/94687 by an attempt to use a Haskell function on Strings . The solutions so far: Either manual editing of the `.h` file (which may result in inconsistencies with the real code, and which is additional burden), or casting in the C code (which opens the door wide for inconsistencies with the real Haskell code). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 13:34:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 13:34:35 -0000 Subject: [GHC] #10505: more specific types in the generated *_stub.h files In-Reply-To: <042.0c58a835030516b3c843e8f17d99b20d@haskell.org> References: <042.0c58a835030516b3c843e8f17d99b20d@haskell.org> Message-ID: <057.fc346d26330bd48804d2805b224ecec5@haskell.org> #10505: more specific types in the generated *_stub.h files -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #2979, #8222 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by imz: Old description: > Having a declaration like: > > {{{#!hs > foreign export ccall "respond" respond :: CWString -> IO CWString > }}} > > all the types in the corresponding `_stub.h` are `HsPtr`. > > Wouldn't it be possible to write more specific types reflecting my > expectations, i.e., `wchar_t *`? > > It would be nice in order to signal automatically to the C code which > uses the Haskell functions that the types of the Haskell functions > changed. In simple cases, one could simply include the stub.h, and get > automatically an error if the C code doesn't match the new types. > > I've tried using a CTYPE pragma (cf. #2979 , #8222 ) on a newtype to get > such results: > > {{{#!hs > newtype {-# CTYPE "wchar_t *" #-} CWString' = CWString' CWString > foreign export ccall "respond" respond :: CWString' -> IO CWString > }}} > > but that still produces `HsPtr`. (Well, I see, the CTYPE pragma was > mostly intended for imports rather than exports.) New description: Having a declaration like: {{{#!hs foreign export ccall "respond" respond :: CWString -> IO CWString }}} all the types in the corresponding `_stub.h` are `HsPtr`. Wouldn't it be possible to write more specific types reflecting my expectations, i.e., `wchar_t *`? It would be nice in order to signal automatically to the C code which uses the Haskell functions that the types of the Haskell functions changed. In simple cases, one could simply include the stub.h, and get automatically an error if the C code doesn't match the new types. I've tried using a CTYPE pragma (cf. #2979 , #8222 , and https://mail.haskell.org/pipermail/haskell/2012-February/023155.html ) on a newtype to get such results: {{{#!hs newtype {-# CTYPE "wchar_t *" #-} CWString' = CWString' CWString foreign export ccall "respond" respond :: CWString' -> IO CWString }}} but that still produces `HsPtr`. (Well, I see, the CTYPE pragma was mostly intended for imports rather than exports.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 14:06:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 14:06:51 -0000 Subject: [GHC] #2437: More accurate package dependencies In-Reply-To: <047.68fd28011c214b441523af716564e799@haskell.org> References: <047.68fd28011c214b441523af716564e799@haskell.org> Message-ID: <062.48976aa7ff8c6eef66c9230182940695@haskell.org> #2437: More accurate package dependencies -------------------------------------+------------------------------------- Reporter: simonmar | Owner: niteria Type: task | Status: new Priority: lowest | Milestone: 7.12.1 Component: Package system | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #3560, #8174 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by niteria): * owner: => niteria -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 14:55:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 14:55:38 -0000 Subject: [GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python In-Reply-To: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> References: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> Message-ID: <060.5ef6f20fd2106997faa3ba8666c0d3d1@haskell.org> #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python ---------------------------------+----------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: 9218 Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by thomie): * blocking: => 9218 Comment: The solution is to either: * use a different (smaller) mingw binary package from somewhere or * copy only the stuff we actually need during installation Note that we do want a C++ compiler (#3893). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 15:14:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 15:14:26 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.56ff7081c0893c4bee753844d2ebb168@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: We are figuring out what all the #ifdefs actually mean, and cleaning them up in #10485. Building on Windows works currently, so I'm closing this ticket. David: please open a new ticket for adding those export lists (reapplying your patches). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 15:21:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 15:21:30 -0000 Subject: [GHC] #2437: More accurate package dependencies In-Reply-To: <047.68fd28011c214b441523af716564e799@haskell.org> References: <047.68fd28011c214b441523af716564e799@haskell.org> Message-ID: <062.6f820b02bd06a9f72657d375aae3afe3@haskell.org> #2437: More accurate package dependencies -------------------------------------+------------------------------------- Reporter: simonmar | Owner: niteria Type: task | Status: patch Priority: lowest | Milestone: 7.12.1 Component: Package system | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #3560, #8174 | Blocking: | Differential Revisions: D973 -------------------------------------+------------------------------------- Changes (by niteria): * status: new => patch * differential: => D973 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 16:58:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 16:58:27 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers Message-ID: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling {{{ module Foo where foo x = x + 1 bar y = foo y }}} with `-g` produces {{{ $ ghc -g -ddump-ticked test.hs [1 of 1] Compiling Foo ( test.hs, test.o ) AbsBinds [a_avC] [$dNum_avD] {Exports: [foo <= foo_amB <>] Exported types: foo :: forall a_avC. Num a_avC => a_avC -> a_avC [LclId, Str=DmdType] Binds: -- ticks = [src] foo_amB x_alA = src (+) src x_alA src 1} AbsBinds [a_avV] [$dNum_avW] {Exports: [bar <= bar_avN <>] Exported types: bar :: forall a_avV. Num a_avV => a_avV -> a_avV [LclId, Str=DmdType] Binds: -- ticks = [src] bar_avN y_amz = src foo (src y_amz)} }}} Note that neither the occurrence of `(+)` in `foo`, nor the occurrence of `foo` in `bar` have their own Ticks. Instead they are only covered by the Tick for the entire application `x + 1` (resp. `foo y`). I'm trying to use the new SourceNote infrastructure to map CoreExprs back to their original source location, but unfortunately I need these locations for each identifier in the source. Would it be reasonable to add a SourceNote to each occurrence of an identifier? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 18:15:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 18:15:28 -0000 Subject: [GHC] #10127: There is no ghc-7.8.4 for 32 bit Windows In-Reply-To: <047.804fe1d7244a5a49e8039cd864eea478@haskell.org> References: <047.804fe1d7244a5a49e8039cd864eea478@haskell.org> Message-ID: <062.84eb754379d02f8d6c181f6a7f28cbe9@haskell.org> #10127: There is no ghc-7.8.4 for 32 bit Windows -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: https://www.haskell.org/ghc/download_ghc_7_8_4#windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 19:31:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 19:31:56 -0000 Subject: [GHC] #1307: Warning refers to code not in the source In-Reply-To: <044.8d564721f12ddb1ee285a76b57133b86@haskell.org> References: <044.8d564721f12ddb1ee285a76b57133b86@haskell.org> Message-ID: <059.6c48573aa3bce700a5a8660d237dce3a@haskell.org> #1307: Warning refers to code not in the source -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 6.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * os: Windows => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 19:37:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 19:37:17 -0000 Subject: [GHC] #1308: Type signature in warning is wrong In-Reply-To: <044.cdb2d58a8b031df50c8e8c2eb0e27b56@haskell.org> References: <044.cdb2d58a8b031df50c8e8c2eb0e27b56@haskell.org> Message-ID: <059.af7b755ec2d015a859bdbf3ee25de418@haskell.org> #1308: Type signature in warning is wrong -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler (Type | Version: 6.7 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: => None/Unknown * component: Compiler => Compiler (Type checker) * os: Windows => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 20:39:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 20:39:23 -0000 Subject: [GHC] #1612: GHC_PACKAGE_PATH and $topdir bug In-Reply-To: <047.68efe858edf43056de08968f61a7dc37@haskell.org> References: <047.68efe858edf43056de08968f61a7dc37@haskell.org> Message-ID: <062.0a552c9fd4c6a43c04930c6ccaf3accf@haskell.org> #1612: GHC_PACKAGE_PATH and $topdir bug -------------------------------------+------------------------------------- Reporter: eivuokko | Owner: Type: bug | Status: new Priority: lowest | Milestone: ? Component: Package system | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * os: Windows => Unknown/Multiple * milestone: 7.12.1 => ? Comment: The bug is minor, but it's still there after 8 years. Here goes: In the file `/opt/ghc/7.10.1/lib/ghc-7.10.1/package.conf.d/base-4.8.0.0-1b689eb8d72c4d4cc88f445839c1f01a.conf` I make the following change: {{{ -haddock-interfaces: /opt/ghc/7.10.1/share/doc/ghc/html/libraries/base-4.8.0.0/base.haddock +haddock-interfaces: $topdir/../../share/doc/ghc/html/libraries/base-4.8.0.0/base.haddock }}} The path that ghc-pkg returns for the haddock-interfaces files exists: {{{ $ ghc-pkg field base haddock-interfaces --package- db=/opt/ghc/7.10.1/lib/ghc-7.10.1/package.conf.d/ haddock-interfaces: /opt/ghc/7.10.1/lib/ghc-7.10.1/../../share/doc/ghc/html/libraries/base-4.8.0.0/base.haddock }}} But when I do the same query while telling ghc-pkg that the global package database is an empty package.conf.d directory, it returns the following: {{{ $ mkdir package.conf.d $ ghc-pkg field base haddock-interfaces --package- db=/opt/ghc/7.10.1/lib/ghc-7.10.1/package.conf.d/ --global-package- db=./package.conf.d/ haddock-interfaces: /home/thomas/package.conf.d/../../share/doc/ghc/html/libraries/base-4.8.0.0/base.haddock }}} Note that that last path doesn't exist. It made the wrong substitution for $topdir. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 21:34:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 21:34:06 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.2816467ec8fb11852d35f2834260519c@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): This is to do with the HPC program coverage stuff (Andy Gill), right? Or is it DWARF stuff (Peter Wortman)? Embarrassingly I cannot see documentation in the manual for `-g` or `-ddump-ticked`; so that should be fixed too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 21:34:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 21:34:27 -0000 Subject: [GHC] #3266: Segment fault with WxHaskell and GHC 6.10.2 In-Reply-To: <051.cf64c613e81199a56945f37be31832f5@haskell.org> References: <051.cf64c613e81199a56945f37be31832f5@haskell.org> Message-ID: <066.34bc6746d4ab32634b0da2a526010447@haskell.org> #3266: Segment fault with WxHaskell and GHC 6.10.2 ---------------------------------+------------------------------------ Reporter: mcastellazzi | Owner: Type: bug | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: 6.10.2 Resolution: wontfix | Keywords: wxhaskell Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+------------------------------------ Changes (by thomie): * status: new => closed * failure: => None/Unknown * resolution: => wontfix Comment: We no longer support GHC 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 21:40:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 21:40:44 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.25ed9b09d3eac2f7532ec6deef64aa00@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gridaphobe): `-g` is the DWARF stuff, but judging by the Coverage module, the DWARF and HPC flags use the same strategy for ticking expressions (`TickForCoverage`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 21:44:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 21:44:39 -0000 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images In-Reply-To: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> References: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> Message-ID: <059.5b549a4704573831aca657274ca5b879@haskell.org> #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D958, | Phab:D970 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"ca39b96ee783e124909a89ea3ad366bf99defa7b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ca39b96ee783e124909a89ea3ad366bf99defa7b" docs: Fix #10416 This commit fixes #10416 by using an EPS-based file-format for embedding images in the users guide, as opposed to a png. This is because 'latex' in some distributions is actually 'pdflatex', which supports reading the size of PNGs in DVI mode, while traditional latex does not. Rather than fiddle with the build a whole bunch, it's easy and simple to just convert the png into a eps file and embed that instead. But apparently we already had an EPS file, added in 1cce2f51656cfbd8c7933a914a4bd981792aa1e6! But it was quite large, so instead I used `convert` to shrink it down from 1.7MB to about 20kb, the same size as the original PDF (by using level3 postscript, which is not as wasteful.) Signed-off-by: Austin Seipp Differential Revision: https://phabricator.haskell.org/D970 GHC Trac Issues: #10416 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 21:46:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 21:46:26 -0000 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images In-Reply-To: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> References: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> Message-ID: <059.5378f673e4ac88fbe3b498216d91b48e@haskell.org> #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D958, | Phab:D970 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge Comment: Should be fixed for good this time! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 22:12:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 22:12:10 -0000 Subject: [GHC] #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc In-Reply-To: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> References: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> Message-ID: <057.43b60a267b1a9d4b1e7664735b004e5a@haskell.org> #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc -------------------------------------+------------------------------------- Reporter: nwf | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9883 | Blocking: 9883 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I like comment:11. Do start a wiki page to describe the design. Issues you don't cover yet * Pattern matching * What about `[a,b..c]` and friends? * One could add this as a different and incompatible extension to the existing `OverloadedLists`, but it would be better to get the best of both worlds. Can we? What can the existing `OverloadedLists` do that the new design cannot? There are probably more issues. A wiki page is a good place to put the current best-effort design; while the ticket is a good place to discuss it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 23:13:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 23:13:06 -0000 Subject: [GHC] #10491: Simplifier explosion with Accelerate In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.a388191ab13db5ef0cca673c20a63e0d@haskell.org> #10491: Simplifier explosion with Accelerate -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): This doesn't seem to be a problem on the 7.10.2 alpha Haskell Platform: ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150601 cabal install --ghc-options="-O2" accelerate --reinstall cabal install --ghc-options="-O2" accelerate --reinstall Resolving dependencies... In order, the following will be installed: accelerate-0.15.1.0 (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring accelerate-0.15.1.0... Building accelerate-0.15.1.0... Installed accelerate-0.15.1.0 Updating documentation index /Users/gcolpitts/Library/Haskell/share/doc/x86_64-osx- ghc-7.10.1.20150601/index.html fwiw the following didn't give an error but not sure if it did the "right" thing, in any case the above should be definitive cabal install -j3 -O2 accelerate cabal install -j3 -O2 accelerate Resolving dependencies... Configuring fclabels-2.0.2.2... Configuring hashtables-1.2.0.2... Building hashtables-1.2.0.2... Building fclabels-2.0.2.2... Installed fclabels-2.0.2.2 Installed hashtables-1.2.0.2 Configuring accelerate-0.15.1.0... Building accelerate-0.15.1.0... Installed accelerate-0.15.1.0 Updating documentation index /Users/gcolpitts/Library/Haskell/share/doc/x86_64-osx- ghc-7.10.1.20150601/index.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 10 23:52:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Jun 2015 23:52:47 -0000 Subject: [GHC] #10167: Error with dash character In-Reply-To: <045.7058519873a76f56757172245184b3a3@haskell.org> References: <045.7058519873a76f56757172245184b3a3@haskell.org> Message-ID: <060.467af290de50b75fd06e3f0edf245af7@haskell.org> #10167: Error with dash character -------------------------------------+------------------------------------- Reporter: elvinz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #6037 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #6037 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 00:04:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 00:04:36 -0000 Subject: [GHC] #10491: Simplifier explosion with Accelerate In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.c0f40822b2e4dc740cd46f8196f6be00@haskell.org> #10491: Simplifier explosion with Accelerate -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by robertce): Accelerate itself compiles without issue. The issue arises when compiling the attached `Slice.hs`, which is not part of the `accelerate` package. Sorry if that was unclear. It's actually part of an experimental version of the `accelerate-cuda` package, but I pulled it out to reduce the the number of dependencies required. Are you able to compile `Slice.hs` with the Haskell platform? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 00:11:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 00:11:02 -0000 Subject: [GHC] #10491: Simplifier explosion with Accelerate In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.20717caa7a07b7923fecfe47cc93e5e5@haskell.org> #10491: Simplifier explosion with Accelerate -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by robertce: Old description: > In [https://github.com/AccelerateHS/accelerate Accelerate] we are > encountering problems with the simplifier exploding the number of terms, > which consequently cause huge compile times. This has only happened since > the release of 7.10.1 and it appears to still be happening in the > ghc-7.10 branch. > > In the attached Slice.hs you can see what is about the worst case > example. Trying to compile this with `-O2` yields > > {{{ > [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, > Slice.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.1.20150602 for x86_64-apple-darwin): > Simplifier ticks exhausted > When trying UnfoldingDone $j_s1FRp > To increase the limit, use -fsimpl-tick-factor=N (default 100) > If you need to do this, let GHC HQ know, and what factor you needed > To see detailed counts use -ddump-simpl-stats > Total ticks: 1668604 > }}} > > Bumping the tick factor to 150 stops this from happening, but at that > point the simplifier blows up. See output.txt for the output of `ghc -v`. > After half an hour we end up with ~4 million terms. At this point ghc > takes up about 9GB of memory and I have to kill it. > > In order to reproduce this, you will need the `accelerate` package and > all its various dependencies. It doesn't have to be the latest from > github. The version on hackage also works with the example I have given. > I will try to come up with a test case that is not so heavy on > dependencies, but I wanted to ensure this was raised before 7.10.2 is > released. New description: In [https://github.com/AccelerateHS/accelerate Accelerate] we are encountering problems with the simplifier exploding the number of terms, which consequently cause huge compile times. This has only happened since the release of 7.10.1 and it appears to still be happening in the ghc-7.10 branch. In the attached Slice.hs you can see what is about the worst case example. Trying to compile this with `-O2` yields {{{ [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, Slice.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150602 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_s1FRp To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 1668604 }}} Bumping the tick factor to 150 stops this from happening, but at that point the simplifier blows up. See output.txt for the output of `ghc -v`. After half an hour we end up with ~4 million terms. At this point ghc takes up about 9GB of memory and I have to kill it. In order to reproduce this, you will need the `accelerate` package and all its various dependencies. It doesn't have to be the latest from github. The version on hackage also works with the example I have given. I will try to come up with a test case that is not so heavy on dependencies, but I wanted to ensure this was raised before 7.10.2 is released. Steps to reproduce: {{{ cabal install accelerate ghc -O2 -fsimpl-tick-factor=150 Slice.hs }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 00:40:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 00:40:18 -0000 Subject: [GHC] #10491: Simplifier explosion with Accelerate In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.72bd5a7616684793333cb5bbabff8f62@haskell.org> #10491: Simplifier explosion with Accelerate -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): Nope, I cannot successfully compile, I reproduce the problem: ghc -O2 Slice.hs [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, Slice.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150601 for x86_64-apple-darwin): Simplifier ticks exhausted When trying RuleFired Class op bound To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 1668404 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 00:43:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 00:43:03 -0000 Subject: [GHC] #10491: Simplifier explosion with Accelerate, increasing tick factor is not a workaround (was: Simplifier explosion with Accelerate) In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.faada9de2ad2d9bd053cf8c49109d33b@haskell.org> #10491: Simplifier explosion with Accelerate, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 00:46:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 00:46:38 -0000 Subject: [GHC] #10491: Simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround (was: Simplifier explosion with Accelerate, increasing tick factor is not a workaround) In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.3c68b6299b058c76c5aa1459854e91ad@haskell.org> #10491: Simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 01:03:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 01:03:01 -0000 Subject: [GHC] #10507: Looping with type level naturals Message-ID: <047.5fd95e048f3c3bca89022fe8d424335a@haskell.org> #10507: Looping with type level naturals -------------------------------------+------------------------------------- Reporter: jhendrix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When compiling the code below, I run into an error with GHC 7.10.1: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE EmptyDataDecls #-} {-# LANGUAGE ExplicitNamespaces #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeOperators #-} module Loop ( ) where import Data.Type.Equality ( (:~:)(Refl) ) import Prelude (Maybe(..), undefined) import GHC.TypeLits ( Nat, type (<=)) data V (n::Nat) testEq :: (m <= n) => V m -> V n -> Maybe (m :~: n) testEq = undefined uext :: (1 <= m, m <= n) => V m -> V n -> V n uext e w = case testEq e w of Just Refl -> e }}} The error I get in GHC 7.10.1 is: {{{#!hs % ghc -c Loop.hs Loop.hs:21:9: Context reduction stack overflow; size = 102 Use -fcontext-stack=N to increase stack size to N (1 GHC.TypeLits.<=? n) ~ 'GHC.Types.True }}} GHC 7.8.4 compiles this without errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 02:06:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 02:06:58 -0000 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> Message-ID: <066.8aa5ec61fbe90b068ef1c6e1065e6cb3@haskell.org> #3085: warn about language extensions that are not used -------------------------------------+------------------------------------- Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: warnings Operating System: Unknown/Multiple | extensions language Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9757 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 02:33:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 02:33:18 -0000 Subject: [GHC] #10508: comipleExpr or :def in GHCi rejects valid multiline expr or accepts invalid expr Message-ID: <046.c1b1b2bc0314b9941dba83381f0b0248@haskell.org> #10508: comipleExpr or :def in GHCi rejects valid multiline expr or accepts invalid expr -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: GHC rejects Test Case: | valid program Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- dynComipleExpr will accept invalid expr or reject valid expr because it compiles the expr as `"let _dynComipleExpr = (" ++ expr ++ ")"`. {{{#!hs -- tail -n 15 Test.hs forM_ exprs $ \expr -> handleSourceError printException $ do dyn <- dynCompileExpr expr liftIO $ print dyn where exprs = [ "" , "(),()" , "()" , "\"test\"" , unlines [ "[()]" , " :: [()]" ] ] -- ./Test /lib/ghc <<()>> <<((),())>> <<()>> <<[Char]>> :2:2: parse error (possibly incorrect indentation or mismatched brackets) }}} As `:def` and `:cmd` uses `compileExpr`, they have the same problem: {{{ GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :{ Prelude| :cmd return $ unlines Prelude| [ "1" Prelude| , "2" Prelude| ] Prelude| :} :2:3: parse error (possibly incorrect indentation or mismatched brackets) Prelude> import Prelude (return, id, ShowS, IO) Prelude> :cmd return "0" :1:42: Not in scope: type constructor or class ?String? Prelude> type String = ShowS Prelude> :cmd return id zsh: segmentation fault (core dumped) ghci }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 02:56:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 02:56:49 -0000 Subject: [GHC] #10508: comipleExpr or :def in GHCi rejects valid multiline expr or accepts invalid expr In-Reply-To: <046.c1b1b2bc0314b9941dba83381f0b0248@haskell.org> References: <046.c1b1b2bc0314b9941dba83381f0b0248@haskell.org> Message-ID: <061.3eaba667c01b5a8635744e9df14a74e1@haskell.org> #10508: comipleExpr or :def in GHCi rejects valid multiline expr or accepts invalid expr -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Phab:D974 Related Tickets: | -------------------------------------+------------------------------------- Changes (by watashi): * differential: => Phab:D974 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 04:51:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 04:51:08 -0000 Subject: [GHC] #10491: Simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.3f5e3a752d7de5d240d1029ffedfcbfc@haskell.org> #10491: Simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by tmcdonell): * cc: tmcdonell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 06:56:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 06:56:15 -0000 Subject: [GHC] #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc In-Reply-To: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> References: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> Message-ID: <057.77025e4249981290e6f9da6def5e5265@haskell.org> #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc -------------------------------------+------------------------------------- Reporter: nwf | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9883 | Blocking: 9883 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by s9gf4ult): * Pattern matching: I believe we should not put pattern matching into `OverloadedLists` and stay with just list construction. It looks like implementation of generic list construction is simpler than generic pattern matching. The usability of list construction is higher because things like {{{#!hs [ OneTypeConstructor , OtherTypeConstructor , "string" ] }}} looks more clean and simple to write than {{{#!hs HCons OneTypeConstructor $ HCons OtherTypeConstructor $ HCons "string" HNil }}} but when you pattern match some list you probably expect some concrete list type, not just some list (heterogeneous or homogeneous) with some elements. Maybe add separate `OverloadedListPatterns` extension instead? * About `[a,b..c]`: There should nothing changed for homogeneous lists, but heterogeneous lists can not be constructed dynamically, especially lists like `[1..]`. Maybe it would be nice to make sugar `[a,b..f]` unwrap to {{{#!hs HCons a $ HCons b $ HCons c $ HCons e $ HCons f HNil }}} but it is not an option for homogeneous lists, especially lists like `[1,2..10000000]`. Maybe special syntax like `[1,2...5]` (three dots) for constructing heterogeneous lists at compile time? * I don't see any things which current `OverloadedLists` can do and this new can not. Maybe some issues with type inference ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 08:22:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 08:22:05 -0000 Subject: [GHC] #10492: rpath & shared libraries in ghc 7.10.1 In-Reply-To: <053.8e0d059d0dcafb8986911d4bd2a6c057@haskell.org> References: <053.8e0d059d0dcafb8986911d4bd2a6c057@haskell.org> Message-ID: <068.b88aa060bc8d6eea53528cbd817d0b5d@haskell.org> #10492: rpath & shared libraries in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:2 rwbarton]: > Isn't this a Cabal bug, not a GHC bug? We don't expect GHC to automatically add rpath entries for C libraries it is told to link against, do we? I am not sure anymore that this is actually a bug. If an executable is linked against a shared object that is not found in a standard location the user needs to provide the extra RPATH (or RUNPATH) or set LD_LIBRARY_PATH accordingly. So what I said in comment:1 is not a workaround but the actual fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 08:22:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 08:22:55 -0000 Subject: [GHC] #10492: rpath & shared libraries in ghc 7.10.1 In-Reply-To: <053.8e0d059d0dcafb8986911d4bd2a6c057@haskell.org> References: <053.8e0d059d0dcafb8986911d4bd2a6c057@haskell.org> Message-ID: <068.72dcce3233b58312e6fdd4e39c110c41@haskell.org> #10492: rpath & shared libraries in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: trommler Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by trommler): * status: new => closed * resolution: => wontfix Comment: Closing as won't fix. Please reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 09:03:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 09:03:26 -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.b3f10fb8ec5eb4f50c49e703be94a7a7@haskell.org> #10162: Add unicode syntax for banana brackets -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by zardoz): I?ve noticed that this has been proposed before, in passing, but wasn?t part of the respective patch. https://ghc.haskell.org/trac/ghc/ticket/2978 Beside banana brackets, the ticket also proposed these, which seem to fit together nicely. ? 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 (| |) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 09:10:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 09:10:44 -0000 Subject: [GHC] #10509: UnicodeSyntax documentation lists wrong symbols Message-ID: <045.99753819878229404545a65d82eb520e@haskell.org> #10509: UnicodeSyntax documentation lists wrong symbols -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I?ve noticed that the documentation on UnicodeSyntax lists erroneous Unicode variants for (-<) and (>-). Notably, it gives ? and ?, while the lexer actually uses ? and ?. The numeric Unicode codepoints are accurate, but glyphs displayed in the table are wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 09:38:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 09:38:00 -0000 Subject: [GHC] #10509: UnicodeSyntax documentation lists wrong symbols In-Reply-To: <045.99753819878229404545a65d82eb520e@haskell.org> References: <045.99753819878229404545a65d82eb520e@haskell.org> Message-ID: <060.a4dba0edb450bd9ae9bc28c6e9b6d72e@haskell.org> #10509: UnicodeSyntax documentation lists wrong symbols -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Would you like to submit a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 09:46:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 09:46:48 -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.6f337980c268b1c48561f216013171a8@haskell.org> #10162: Add unicode syntax for banana brackets -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Please ask the glasgow-haskell-users mailinglist to see if other want this as well. See [wiki:WorkingConventions/AddingFeatures]. This is not going to get a lot of attention otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 10:07:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 10:07:54 -0000 Subject: [GHC] #10510: Testsuite driver does not run tests in parallel on Windows Message-ID: <045.f7051a2be634cd79e52b8850db4fc44f@haskell.org> #10510: Testsuite driver does not run tests in parallel on Windows -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Test Suite | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `testsuite/driver/runtests.py` contains the following 3 lines: {{{ if windows: print("Warning: Ignoring request to use threads as running on Windows") config.use_threads = 0 }}} They were introduced in commit e9b3d6cc65c0b69bd4a50bfa7bc7e1d3536446a8: {{{ Author: Ian Lynagh <> Date: Wed Oct 28 17:54:21 2009 +0000 Don't use threads on Windows It seems to cause some sort of deadlock }}} I tried removing them (Windows 64 bit, using msys2), but then running validate doesn't get any further than: {{{ ... =====> Overlap3(normal) 1605 of 4525 [2, 7, 0] =====> Overlap4(normal) 1606 of 4525 [2, 7, 0] =====> Overlap5(normal) 1607 of 4525 [2, 7, 0] =====> Overlap6(normal) 1608 of 4525 [2, 7, 0] =====> Overlap7(normal) 1609 of 4525 [2, 7, 0] =====> Overlap9(normal) 1610 of 4525 [2, 7, 0] }}} It would be great if we could run the testsuite in parallel again, since running validate takes forever currently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 11:59:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 11:59:01 -0000 Subject: [GHC] #10491: Simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.f0650248b48c38247596fd0552a871eb@haskell.org> #10491: Simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by George): * cc: george (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 12:31:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 12:31:42 -0000 Subject: [GHC] #10511: Simplify some preprocessor expressions Message-ID: <045.698f4b8298888964595c9d1036b07fd4@haskell.org> #10511: Simplify some preprocessor expressions -------------------------------------+------------------------------------- Reporter: Berdes | Owner: Berdes Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Some proprocessor expressions can be simplified. For exemple, when `_MSC_VER` is defined, `_WIN32` is also defined. So `#if defined(_MSC_VER) || defined(_WIN32)` can be simplified to `#if defined(_WIN32)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 12:32:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 12:32:22 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.b394ab4e971681d5fb6abe085cab9008@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ddbb97d00fdbc5870a4076ed15af8e607b161cb2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ddbb97d00fdbc5870a4076ed15af8e607b161cb2" Another major improvement of "improvement" I wasn't very happy with my fix to Trac #10009. This is much better. The main idea is that the inert set now contains a "model", which embodies *all* the (nominal) equalities that we know about, with a view to exposing unifications. This requires a lot fewer iterations of the solver than before. There are extensive comments in TcSMonad: Note [inert_model: the inert model] Note [Adding an inert canonical constraint the InertCans] The big changes are * New inert_model field in InertCans * Functions addInertEq, addInertCan deal with adding a constraint, maintaining the model * A nice improvement is that unification variables can unify with fmvs, so that from, say alpha ~ fmv we get alpha := fmv See Note [Orientation of equalities with fmvs] in TcFlatten It's still not perfect, as the Note explains New flag -fconstraint-solver-iterations=n, allows us to control the number of constraint solver iterations, and in particular will flag up when it's more than a small number. Performance is generally slightly better: T5837 is a lot better for some reason. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 12:56:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 12:56:22 -0000 Subject: [GHC] #10468: debug test case fails on Windows In-Reply-To: <045.b19678979c06629a2acceac03a72cd6b@haskell.org> References: <045.b19678979c06629a2acceac03a72cd6b@haskell.org> Message-ID: <060.66c4385b1fa535a2d414e5690c6b8d58@haskell.org> #10468: debug test case fails on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: scpmw Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.11 (Debugging) | Keywords: Resolution: | Architecture: Operating System: Windows | Unknown/Multiple Type of failure: None/Unknown | Test Case: debug Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 7.10.2 Comment: I confirm that the test succeeds on 64 bit Windows after applying this patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 13:10:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 13:10:23 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.60eaeef949bf9773f915e0784c5eddf8@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by jeltsch): Thank you very much, Simon. I think I will test this new solution with `incremental-computing` soon. Is there any chance that this patch or the previous one will make it into GHC?7.10.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 13:12:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 13:12:02 -0000 Subject: [GHC] #10491: Regression: Simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround (was: Simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround) In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.05365568a68c0b9901e88c0f43225f57@haskell.org> #10491: Regression: Simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 13:13:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 13:13:21 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround (was: Regression: Simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround) In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.fd9177003fb3d52e5306e4d3ed8ffe82@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 13:16:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 13:16:36 -0000 Subject: [GHC] #2648: Report out of date interface files robustly In-Reply-To: <046.fcbe859a05356d3f8331ef4b72030e02@haskell.org> References: <046.fcbe859a05356d3f8331ef4b72030e02@haskell.org> Message-ID: <061.155e8e5c7ca694a3ea4a20c70985d6b9@haskell.org> #2648: Report out of date interface files robustly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.12.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 13:25:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 13:25:42 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.757f80569a59db87a91c64ace88b20df@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D194 -------------------------------------+------------------------------------- Changes (by thomie): * owner: archblob => * resolution: fixed => * status: closed => new * os: Unknown/Multiple => Windows Comment: There are 2 problems with the above patch on Windows: * the test fails, because `-ldl` can not be found. * in ghci, I can type `:set -lsomethingnonexistent` and it doesn't complain Note that running `ghci -lsomethingnonexistent` does fail on all platforms. Running `:set -lsomethingnonexist` in ghci on linux also fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 14:13:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 14:13:29 -0000 Subject: [GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python In-Reply-To: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> References: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> Message-ID: <060.c225a6d50dd1951986f89b40080ebc1f@haskell.org> #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python ---------------------------------+----------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: 9218 Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 14:14:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 14:14:28 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.4d41b3dd8a7346732d3086d334241605@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 9014 | Test Case: Related Tickets: #3390 | Blocking: 9215 | Differential Revisions: Phab:D339 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 14:40:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 14:40:19 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.92760a82bb980364aa188a89ee4f2612@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by simonpj): > Is there any chance that this patch or the previous one will make it into GHC 7.10.2? coment:33 won't. I hope that comment:22 will (Austin is working on exactly that). According to comment:21, it's to be enough to solve your problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 14:47:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 14:47:33 -0000 Subject: [GHC] #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc In-Reply-To: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> References: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> Message-ID: <057.e4b4f4a158cf7eed88a46b43351ab9c4@haskell.org> #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc -------------------------------------+------------------------------------- Reporter: nwf | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9883 | Blocking: 9883 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): > I don't see any things which current `OverloadedLists` can do and this new can not. Well, how about pattern matching and `[1..n]`?! Maybe people are using those already. Have you talked to the authors of `OverloadedLists` to see what they think? Do you expect this new design to ''replace'' `OverloadedLists`, or just be a competing extension? Let me continue to encourage you to start a wiki page explaining the design and its relationship to other extensions. Build up a community of people who support the idea, and work with them to refine it. Ultimately, develop a patch. Good work! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 14:51:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 14:51:22 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.a323ec75b4966cbc75f6370b4f0ca9f3@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D586 | Phab:D587 -------------------------------------+------------------------------------- Changes (by thomie): * owner: facundo.dominguez => * resolution: fixed => * status: closed => new * os: Unknown/Multiple => Windows Comment: This is failing in a scary way on Windows 64 bit. {{{ =====> T9878b(ghci) 138 of 147 [0, 0, 0] cd . && HC="D:/home/thomie/ghc-master/inplace/bin/ghc-stage2.exe" HC_OPTS ="-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history " "D:/home/thomie/ghc-master/inplace/bin /ghc-stage2.exe" -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-warn-tabs -fno-ghci-history --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS -fobject-code T9878b.run.stdout 2> T9878b.run.stderr Wrong exit code (expected 0 , actual 3 ) Stdout: Stderr: : internal error: checkProddableBlock: invalid fixup in runtime linker: 0000000000270508 (GHC version 7.11.20150610 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. *** unexpected failure for T9878b(ghci) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 15:05:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 15:05:25 -0000 Subject: [GHC] #9381: Implement -rdynamic In-Reply-To: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> References: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> Message-ID: <071.64d307f98727bbc7bca979c45906123d@haskell.org> #9381: Implement -rdynamic -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Status: new Type: feature request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Operating System: Windows | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7015 | Differential Revisions: Phab:D102 -------------------------------------+------------------------------------- Changes (by thomie): * owner: facundo.dominguez => * resolution: fixed => * status: closed => new * os: Unknown/Multiple => Windows Comment: This test is failing on Windows 64 bit. {{{ =====> rdynamic(normal) 50 of 71 [0, 0, 0] cd . && "D:/home/thomie/ghc-master/inplace/bin/ghc-stage2.exe" -o rdynamic rdynamic.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug- output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -rdynamic -package ghc -v > rdynamic.comp.stderr 2>&1 cd . && ./rdynamic rdynamic.run.stdout 2> rdynamic.run.stderr Wrong exit code (expected 0 , actual 160 ) Stdout: Stderr: *** unexpected failure for rdynamic(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 16:31:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 16:31:09 -0000 Subject: [GHC] #2437: More accurate package dependencies In-Reply-To: <047.68fd28011c214b441523af716564e799@haskell.org> References: <047.68fd28011c214b441523af716564e799@haskell.org> Message-ID: <062.f08efacdf886ca2791f65271a0044c5d@haskell.org> #2437: More accurate package dependencies -------------------------------------+------------------------------------- Reporter: simonmar | Owner: niteria Type: task | Status: patch Priority: lowest | Milestone: 7.12.1 Component: Package system | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #3560, #8174 | Blocking: | Differential Revisions: Phab:D973 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: D973 => Phab:D973 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 17:10:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 17:10:31 -0000 Subject: [GHC] #10468: debug test case fails on Windows In-Reply-To: <045.b19678979c06629a2acceac03a72cd6b@haskell.org> References: <045.b19678979c06629a2acceac03a72cd6b@haskell.org> Message-ID: <060.d1546ed403f6e3bc8a82440171cd637d@haskell.org> #10468: debug test case fails on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: scpmw Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.11 (Debugging) | Keywords: Resolution: | Architecture: Operating System: Windows | Unknown/Multiple Type of failure: None/Unknown | Test Case: debug Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a66ef3567ea29c93a9c010befc672602dc1c644c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a66ef3567ea29c93a9c010befc672602dc1c644c" Fix DWARF generation for MinGW (#10468) Fortunately this is relatively straightforward - all we need to do is switch to a non-ELF-specific way of specifying object file sections and make sure that section-relative addresses work correctly. This is enough to make "gdb" work on MinGW builds. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 17:11:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 17:11:22 -0000 Subject: [GHC] #10468: debug test case fails on Windows In-Reply-To: <045.b19678979c06629a2acceac03a72cd6b@haskell.org> References: <045.b19678979c06629a2acceac03a72cd6b@haskell.org> Message-ID: <060.2a2e014e01085579a5dbd36452b122da@haskell.org> #10468: debug test case fails on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: scpmw Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.11 (Debugging) | Keywords: Resolution: | Architecture: Operating System: Windows | Unknown/Multiple Type of failure: None/Unknown | Test Case: debug Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 17:28:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 17:28:58 -0000 Subject: [GHC] #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc In-Reply-To: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> References: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> Message-ID: <057.dbf4eeb9e3b5a23b794aedc911712148@haskell.org> #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc -------------------------------------+------------------------------------- Reporter: nwf | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9883 | Blocking: 9883 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by s9gf4ult): You absolutely right about pattern matching (using view patterns) and `[1..n]` expressions. I just missed this features of `OverloadedLists`. It is not obvious how to deal with it. My code differs from original code of this proposal, I am also not an author of proposal. Maybe @carter should start wiki page? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 17:29:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 17:29:48 -0000 Subject: [GHC] #8172: Expose CWD and import search paths in GHCi via new `:show paths` command In-Reply-To: <042.d5f523c48aacba6f52cb89b34a5dcdb4@haskell.org> References: <042.d5f523c48aacba6f52cb89b34a5dcdb4@haskell.org> Message-ID: <057.6fbd1368a8e066a10b6b1ce2b0af39a3@haskell.org> #8172: Expose CWD and import search paths in GHCi via new `:show paths` command -------------------------------------+--------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by Thomas Miedema ): In [changeset:"da84fd5475d189c39bd3e12d29f45618c92ed800/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="da84fd5475d189c39bd3e12d29f45618c92ed800" Testsuite Windows: fix T8172 (#8172) Use the new function `normalise_drive_letter` to change D:\ to C:\ before comparing outputs. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 17:29:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 17:29:48 -0000 Subject: [GHC] #9381: Implement -rdynamic In-Reply-To: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> References: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> Message-ID: <071.b3339094f84bd307b13d9e271cb5d1df@haskell.org> #9381: Implement -rdynamic -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Status: new Type: feature request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Operating System: Windows | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7015 | Differential Revisions: Phab:D102 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"a765f72c130111cdbd30f2a3e159186c6e625d2a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a765f72c130111cdbd30f2a3e159186c6e625d2a" Testsuite: mark tests as expect_broken on win64 Tickets: #1407, #9381, #9878. Differential Revision: https://phabricator.haskell.org/D977 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 17:29:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 17:29:48 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.7e6f451b97c52272c65de2e1641737b6@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D586 | Phab:D587 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"a765f72c130111cdbd30f2a3e159186c6e625d2a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a765f72c130111cdbd30f2a3e159186c6e625d2a" Testsuite: mark tests as expect_broken on win64 Tickets: #1407, #9381, #9878. Differential Revision: https://phabricator.haskell.org/D977 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 17:29:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 17:29:48 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.12e63d0058b009327e70f428d0c2bee0@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D194 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"a765f72c130111cdbd30f2a3e159186c6e625d2a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a765f72c130111cdbd30f2a3e159186c6e625d2a" Testsuite: mark tests as expect_broken on win64 Tickets: #1407, #9381, #9878. Differential Revision: https://phabricator.haskell.org/D977 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 17:34:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 17:34:52 -0000 Subject: [GHC] #4945: Another SpecConstr infelicity In-Reply-To: <053.dd99f570cc6450886c16aa213467aa21@haskell.org> References: <053.dd99f570cc6450886c16aa213467aa21@haskell.org> Message-ID: <068.6bee27cb630a8789b1a3912d402d257e@haskell.org> #4945: Another SpecConstr infelicity -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.0.2 Component: Compiler | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T4945 Blocked By: | Blocking: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"506522c95f5d43db4d469135878c56fe20eb81f6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="506522c95f5d43db4d469135878c56fe20eb81f6" Testsuite: mark T4945 as expect_broken (#4945) In commit 7d519dabd2006c9742e82fce02df55704da15482, the file T4945.stdout was added to the repository, to make T4945 pass validatation presumably. When that test produces output however, there is a bug somewhere, and we shouldn't hide it. There is a comment in the Makefile which says: "When SpecConstr works there are no STUArrays at all" So here we remove T4945.stdout again, mark T4945 as expect_broken, and reopen the ticket. Differential Revision: https://phabricator.haskell.org/D976 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 17:36:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 17:36:53 -0000 Subject: [GHC] #4945: Another SpecConstr infelicity In-Reply-To: <053.dd99f570cc6450886c16aa213467aa21@haskell.org> References: <053.dd99f570cc6450886c16aa213467aa21@haskell.org> Message-ID: <068.b3ae899056c643a9849261ecfc4acf22@haskell.org> #4945: Another SpecConstr infelicity -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | simplCore/should_compile/T4945 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => high * status: closed => new * resolution: fixed => * milestone: 7.0.2 => 7.12.1 Comment: Marking regression with priority high. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 18:00:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 18:00:27 -0000 Subject: [GHC] #9252: Generalize hs-boot files to be more like module signatures In-Reply-To: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> References: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> Message-ID: <060.dfe0b8e33a636140817c95fa90dc98d9@haskell.org> #9252: Generalize hs-boot files to be more like module signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D130 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"5e66a698dae8c01bcd1a9335346145b32016e119/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5e66a698dae8c01bcd1a9335346145b32016e119" Testsuite: change some expect_fail tests to expect_broken Change the following tests from expect_fail to expect_broken: and list the ticket number: * driver/sigof03m/sigof03 (#9252) * driver/static001 (#8127) * partial-sigs/should_compile/EqualityConstraint (#9478) * partial-sigs/should_compile/ExtraNumAMROn (#9478) * partial-sigs/should_compile/PatBind2 (#9478) * partial-sigs/should_fail/TidyClash2 (#9478) * simplCore/should_compile/T8832 (#8832) The following tests are still marked as expect_fail, but it is not clearly documented why so: * gadt/lazypatok * indexed-types/should_fail/SkolemOccursLoop All other expect_fail tests are only expected to fail on either a certain platform/os or for a certain way only. Differential Revision: https://phabricator.haskell.org/D966 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 18:00:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 18:00:27 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.e9be90686155c08375549a1278e2c937@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | simplCore/should_compile/T8832 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"5e66a698dae8c01bcd1a9335346145b32016e119/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5e66a698dae8c01bcd1a9335346145b32016e119" Testsuite: change some expect_fail tests to expect_broken Change the following tests from expect_fail to expect_broken: and list the ticket number: * driver/sigof03m/sigof03 (#9252) * driver/static001 (#8127) * partial-sigs/should_compile/EqualityConstraint (#9478) * partial-sigs/should_compile/ExtraNumAMROn (#9478) * partial-sigs/should_compile/PatBind2 (#9478) * partial-sigs/should_fail/TidyClash2 (#9478) * simplCore/should_compile/T8832 (#8832) The following tests are still marked as expect_fail, but it is not clearly documented why so: * gadt/lazypatok * indexed-types/should_fail/SkolemOccursLoop All other expect_fail tests are only expected to fail on either a certain platform/os or for a certain way only. Differential Revision: https://phabricator.haskell.org/D966 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 18:00:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 18:00:27 -0000 Subject: [GHC] #9478: Partial type signatures In-Reply-To: <046.53a47ac5f73cf1b7df317af2585f061e@haskell.org> References: <046.53a47ac5f73cf1b7df317af2585f061e@haskell.org> Message-ID: <061.1aac34940a1a6818edf029572bcea129@haskell.org> #9478: Partial type signatures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D168 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"5e66a698dae8c01bcd1a9335346145b32016e119/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5e66a698dae8c01bcd1a9335346145b32016e119" Testsuite: change some expect_fail tests to expect_broken Change the following tests from expect_fail to expect_broken: and list the ticket number: * driver/sigof03m/sigof03 (#9252) * driver/static001 (#8127) * partial-sigs/should_compile/EqualityConstraint (#9478) * partial-sigs/should_compile/ExtraNumAMROn (#9478) * partial-sigs/should_compile/PatBind2 (#9478) * partial-sigs/should_fail/TidyClash2 (#9478) * simplCore/should_compile/T8832 (#8832) The following tests are still marked as expect_fail, but it is not clearly documented why so: * gadt/lazypatok * indexed-types/should_fail/SkolemOccursLoop All other expect_fail tests are only expected to fail on either a certain platform/os or for a certain way only. Differential Revision: https://phabricator.haskell.org/D966 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 18:00:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 18:00:27 -0000 Subject: [GHC] #8127: iOS patch no 19: Linking In-Reply-To: <056.cfb2c89196b093d46cda3044197779e0@haskell.org> References: <056.cfb2c89196b093d46cda3044197779e0@haskell.org> Message-ID: <071.a48cc0249d68a6ab3b46e37ec2136aa6@haskell.org> #8127: iOS patch no 19: Linking --------------------------------------------+----------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Other | Architecture: arm Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: 7724 Related Tickets: | --------------------------------------------+----------------------- Comment (by Thomas Miedema ): In [changeset:"5e66a698dae8c01bcd1a9335346145b32016e119/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5e66a698dae8c01bcd1a9335346145b32016e119" Testsuite: change some expect_fail tests to expect_broken Change the following tests from expect_fail to expect_broken: and list the ticket number: * driver/sigof03m/sigof03 (#9252) * driver/static001 (#8127) * partial-sigs/should_compile/EqualityConstraint (#9478) * partial-sigs/should_compile/ExtraNumAMROn (#9478) * partial-sigs/should_compile/PatBind2 (#9478) * partial-sigs/should_fail/TidyClash2 (#9478) * simplCore/should_compile/T8832 (#8832) The following tests are still marked as expect_fail, but it is not clearly documented why so: * gadt/lazypatok * indexed-types/should_fail/SkolemOccursLoop All other expect_fail tests are only expected to fail on either a certain platform/os or for a certain way only. Differential Revision: https://phabricator.haskell.org/D966 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 18:00:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 18:00:27 -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.f4aef0eec50f519876a71ef639f5b24c@haskell.org> #10510: Testsuite driver does not run tests in parallel on Windows -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"6cefeb373e13c25f6c8c1d08975e14a8655f0bc9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6cefeb373e13c25f6c8c1d08975e14a8655f0bc9" Testsuite: mention the existence of ticket #10510 [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 18:06:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 18:06:37 -0000 Subject: [GHC] #8127: iOS patch no 19: Linking In-Reply-To: <056.cfb2c89196b093d46cda3044197779e0@haskell.org> References: <056.cfb2c89196b093d46cda3044197779e0@haskell.org> Message-ID: <071.e4609280e83bf1c3eb651a153929ac9c@haskell.org> #8127: iOS patch no 19: Linking -------------------------------------+------------------------------------- Reporter: | Owner: StephenBlackheath | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: arm Operating System: MacOS X | Test Case: Type of failure: GHC doesn't work | Blocking: 7724 at all | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: fixed => * os: Other => MacOS X Comment: Reopening this ticket so that we don't forget to fix the test. In commit cd3e3455d4c5307ab4f089209181d7c8e457173d: {{{ Author: Austin Seipp <> Date: Mon Jan 13 08:40:28 2014 -0600 Mark static001 as failing Right now the stderr output doesn't match because we don't suppress some libtool errors, but these seem to be benign... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 18:24:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 18:24:19 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.1e34052985fc2b3658ad47b44d673728@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): I submitted a patch for this: https://phabricator.haskell.org/D978 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 18:33:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 18:33:37 -0000 Subject: [GHC] #10485: Remove __MINGW32__ from all source files In-Reply-To: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> References: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> Message-ID: <060.8d5c92d670424a8f255e44a753244321@haskell.org> #10485: Remove __MINGW32__ from all source files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Berdes Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D971 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"0db0ac4a255931036c5859c3f22108f4e27ccd11/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0db0ac4a255931036c5859c3f22108f4e27ccd11" Removes all occurrences of __MINGW32__ (#10485) In Haskell files, replace `__MINGW32__` by `mingw32_HOST_OS`. In .c and .h files, delete `__MINGW32__` when `_WIN32` is also tested because `_WIN32` is always defined when `__MINGW32__` is. Also replace `__MINGW32__` by `_WIN32` when used standalone for consistency. Differential Revision: https://phabricator.haskell.org/D971 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 18:42:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 18:42:24 -0000 Subject: [GHC] #10485: Remove __MINGW32__ from all source files In-Reply-To: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> References: <045.63e10c9ecaf755318a737b5d5d3fda09@haskell.org> Message-ID: <060.a76cb8fbf389671e4f02de01d4d40d85@haskell.org> #10485: Remove __MINGW32__ from all source files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Berdes Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: newcomer Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D971 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: Sorry, for some reason this patch didn't get your name on it. It should have! So for the record: {{{ This patch was authored by Bernard Desmyter. }}} Thanks. See you in #10511. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 21:09:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 21:09:59 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.c6b988301281dd9fcce98451c10f16b9@haskell.org> #3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: alanz (added) * owner: kseo => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 21:14:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 21:14:17 -0000 Subject: [GHC] #9746: tests/ghci/scripts/T8172 is sensitive to drive name on Windows In-Reply-To: <045.7af0e04e1ed640383fef9f280530ad11@haskell.org> References: <045.7af0e04e1ed640383fef9f280530ad11@haskell.org> Message-ID: <060.29630d99a6b736bc477dd1444374f6aa@haskell.org> #9746: tests/ghci/scripts/T8172 is sensitive to drive name on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 7.12.1 Comment: Ha. I fixed this today in da84fd5475d189c39bd3e12d29f45618c92ed800, not knowing this ticket existed. {{{ Author: Thomas Miedema Date: Thu Jun 11 19:26:11 2015 +0200 Testsuite Windows: fix T8172 (#8172) Use the new function `normalise_drive_letter` to change D:\ to C:\ before comparing outputs. }}} Any other letter is fine too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 21:19:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 21:19:12 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.c628dcfab10332f108d5cf6f6d75c100@haskell.org> #3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by alanz): This looks interesting. No attempt to preserve comments/layout, but ensure it can be round tripped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 21:25:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 21:25:31 -0000 Subject: [GHC] #10211: Validate fails in RTS tests on Mac OS X In-Reply-To: <046.ceeba31edc5276171ff0db279007810e@haskell.org> References: <046.ceeba31edc5276171ff0db279007810e@haskell.org> Message-ID: <061.1b20124b402c0e1df3e1f39fdc98eba5@haskell.org> #10211: Validate fails in RTS tests on Mac OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9389 | rts/linker_unload | Blocking: | Differential Revisions: Phab:D765 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: Thanks. We're waiting for more patches from you Dave. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 21:31:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 21:31:56 -0000 Subject: [GHC] #10239: Fragile CPP test for big endian in T7600 In-Reply-To: <047.4141fef62b155ef45c7ff2e676f4002e@haskell.org> References: <047.4141fef62b155ef45c7ff2e676f4002e@haskell.org> Message-ID: <062.ed312830d155bb757fb71b568d1237bd@haskell.org> #10239: Fragile CPP test for big endian in T7600 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: T7600 Related Tickets: | Blocking: | Differential Revisions: Phab:D795 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 21:38:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 21:38:28 -0000 Subject: [GHC] #9543: Testsuite driver: replace "extra_clean" by "git clean -X" In-Reply-To: <045.2f69795abaf71b802d453cc5970d5177@haskell.org> References: <045.2f69795abaf71b802d453cc5970d5177@haskell.org> Message-ID: <060.18ed29e8bd673c7f6e17a7c3ece1a9ae@haskell.org> #9543: Testsuite driver: replace "extra_clean" by "git clean -X" -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): This approach doesn't quite work, because it should also be possible to delete only the files that a single test generates. A simpler solution: enforce the rule that all files which a test generates go into a single subdirectory. The directory could have the same name as the test. test('T1234', normal, ..., ...) can only create files in the directory 'T1234'. Then 'make CLEANUP=1' just removes that directory afterwards. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 21:50:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 21:50:17 -0000 Subject: [GHC] #10479: Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh In-Reply-To: <045.1ef1ca690686af7d2265216e3878b27c@haskell.org> References: <045.1ef1ca690686af7d2265216e3878b27c@haskell.org> Message-ID: <060.da4a3d1de000280cd46ae99c70384dd4@haskell.org> #10479: Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Package system | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: 9506 | Differential Revisions: Phab:D922 -------------------------------------+------------------------------------- Comment (by ezyang): Fix is in the 1.22 Cabal branch, all we need is for Cabal to cut a release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 21:50:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 21:50:22 -0000 Subject: [GHC] #10480: Ship Cabal with Windows filepath fix In-Reply-To: <045.437e09638d10b0a54f88e3ea0078e353@haskell.org> References: <045.437e09638d10b0a54f88e3ea0078e353@haskell.org> Message-ID: <060.7d895476fb99be363d5968437ce2b07d@haskell.org> #10480: Ship Cabal with Windows filepath fix -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: libraries | Version: 7.10.1 (other) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Fix is in the 1.22 Cabal branch, all we need is for Cabal to cut a release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 21:57:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 21:57:42 -0000 Subject: [GHC] #9562: Type families + hs-boot files = unsafeCoerce In-Reply-To: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> References: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> Message-ID: <062.bcecf9705d6a6b6cc1f7e3d39684c92e@haskell.org> #9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #10270 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"23582b0c16bb147dad6bd7dee98686a8b61eacea/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="23582b0c16bb147dad6bd7dee98686a8b61eacea" Add failing test for #9562. Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 22:03:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 22:03:39 -0000 Subject: [GHC] #10511: Simplify some preprocessor expressions In-Reply-To: <045.698f4b8298888964595c9d1036b07fd4@haskell.org> References: <045.698f4b8298888964595c9d1036b07fd4@haskell.org> Message-ID: <060.33e06450660f562c28b6cfbc823615ba@haskell.org> #10511: Simplify some preprocessor expressions -------------------------------------+------------------------------------- Reporter: Berdes | Owner: Berdes Type: task | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: D981 -------------------------------------+------------------------------------- Changes (by Berdes): * status: new => patch * differential: => D981 Old description: > Some proprocessor expressions can be simplified. For exemple, when > `_MSC_VER` is defined, `_WIN32` is also defined. > > So `#if defined(_MSC_VER) || defined(_WIN32)` can be simplified to `#if > defined(_WIN32)`. New description: Some preprocessor expressions can be simplified. For exemple, when `_MSC_VER` is defined, `_WIN32` is also defined. So `#if defined(_MSC_VER) || defined(_WIN32)` can be simplified to `#if defined(_WIN32)`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 22:18:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 22:18:25 -0000 Subject: [GHC] #10345: Testsuite timeout_multiplier setting does not work as expected In-Reply-To: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> References: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> Message-ID: <063.78b626e2bf0468dacb25baf36bc84682@haskell.org> #10345: Testsuite timeout_multiplier setting does not work as expected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): I can not reproduce this issue yet. Can you try a few things. I am assuming you are on Linux. When you run the following, does it stop after 3 seconds? * `python testsuite/timeout/timeout.py 3 'sleep 100'` * In `testsuite/tests/ghc-api/annotations/all.T`, make the following change: {{{ -test('annotations', normal, run_command, ['$MAKE -s --no-print-directory annotations']) +test('annotations', timeout_multiplier(0.01), run_command, ['$MAKE -s --no-print-directory annotations']) }}} When running `make TEST=annotations`, does it stop after 3 seconds? I guess it doesn't, otherwise you wouldn't have opened this ticket, but I want to be sure it's not something with the test you were writing in particular. It must be something specific to your platform, as timeout works for me. The issue only I seem to be having is that running `python testsuite/timeout/timeout.py 10 'echo ok' ` doesn't return immediately, but only after 10 seconds. Can you try that one as well? For some reason producing output is not allowed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 11 23:18:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Jun 2015 23:18:35 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.9368dd95fd8c44b70cbeefe19186edd0@haskell.org> #3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 03:36:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 03:36:02 -0000 Subject: [GHC] #10496: Update Haddock for 7.10.2 In-Reply-To: <042.4390876b176ea384032fa57b3511f6a4@haskell.org> References: <042.4390876b176ea384032fa57b3511f6a4@haskell.org> Message-ID: <057.ef809dd2d59750f47d38291ac50820c0@haskell.org> #10496: Update Haddock for 7.10.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | thoughtpolice Priority: high | Status: new Component: libraries | Milestone: 7.10.2 (other) | Version: Resolution: | Keywords: haddock Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fuuzetsu): Can probably point 7.10 branch at 5aaa14fa020da56be7fdf943f6da3310d11a3593 (current Haddock master), it's as good as any other commit for it. I may be changing stuff soon though shouldn't be anything critical that would hold up GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 07:00:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 07:00:41 -0000 Subject: [GHC] #10345: Testsuite timeout_multiplier setting does not work as expected In-Reply-To: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> References: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> Message-ID: <063.5fd9cf857f465e9a2d82a915bcf67581@haskell.org> #10345: Testsuite timeout_multiplier setting does not work as expected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:1 thomie]: > I am assuming you are on Linux. Yes, that's correct > When you run the following, does it stop after 3 seconds? > * `python testsuite/timeout/timeout.py 3 'sleep 100'` Yes. > * In `testsuite/tests/ghc-api/annotations/all.T`, make the following change: > {{{ > -test('annotations', normal, run_command, ['$MAKE -s --no-print- directory annotations']) > +test('annotations', timeout_multiplier(0.01), run_command, ['$MAKE -s --no-print-directory annotations']) > }}} > When running `make TEST=annotations`, does it stop after 3 seconds? Yes. > I guess it doesn't, otherwise you wouldn't have opened this ticket So the above tests work, but my tests still doesn't time out. An obvious explanation is that I've configured the test incorrectly. Another is that the timeout does not work if GHC becomes unresponsive (ie. hits a black hole). (In the latter case: why would a 5 minute timeout work?) > The issue only I seem to be having is that running `python testsuite/timeout/timeout.py 10 'echo ok' ` doesn't return immediately, but only after 10 seconds. Can you try that one as well? For some reason producing output is not allowed. That work for me as it should - finishes immediately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 07:13:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 07:13:27 -0000 Subject: [GHC] #10345: Testsuite timeout_multiplier setting does not work as expected In-Reply-To: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> References: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> Message-ID: <063.02f65d70092d0d25c3c8d17f1d188ce8@haskell.org> #10345: Testsuite timeout_multiplier setting does not work as expected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): There are 2 timeout programs. On Linux we use the one written in Python by default, on Windows the one in written in Haskell. Can you try the following: {{{ $ cd testsuite/timeout $ rm -r install-inplace $ make WINDOWS=YES $ cd ../ $ make TEST='' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 07:18:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 07:18:24 -0000 Subject: [GHC] #10345: Testsuite timeout_multiplier setting does not work as expected In-Reply-To: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> References: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> Message-ID: <063.788a6d42c7e3a224f8c9459c5ecb6487@haskell.org> #10345: Testsuite timeout_multiplier setting does not work as expected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Sorry, the one in Haskell doesn't compile at the moment, I forgot. You need this patch: {{{ commit c5759a04c73de36f94bb7239f9ead91f8741e6af Author: Thomas Miedema Date: Fri May 29 20:37:29 2015 +0200 Testsuite: fix timeout.hs diff --git a/testsuite/timeout/timeout.hs b/testsuite/timeout/timeout.hs index f78baa1..d75e13c 100644 --- a/testsuite/timeout/timeout.hs +++ b/testsuite/timeout/timeout.hs @@ -65,7 +65,7 @@ run secs cmd = do killProcess pid exitWith (ExitFailure 99) Just (Exited r) -> exitWith r - Just (Terminated s) -> raiseSignal s + Just (Terminated s _) -> raiseSignal s Just _ -> exitWith (ExitFailure 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 07:42:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 07:42:08 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.47d29e6084a0c1efd86719819049c05d@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D194 -------------------------------------+------------------------------------- Changes (by archblob): * owner: => archblob Comment: I'll do windows build and see what's wrong. The test case we should change to a library guaranteed to be on both plaform, I thought libdl was, we need something better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 08:10:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 08:10:02 -0000 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@haskell.org> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@haskell.org> Message-ID: <059.56dd0667badcfa58d95f935b6b6f85ec@haskell.org> #1475: Adding imports and exports with Template Haskell -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by cdupont): I have also a use case for it. I need to generate imports that are extracted from GIT history. Using TH to do that would be elegant as I could extract the file and splice in the module name in the import list at the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 08:20:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 08:20:00 -0000 Subject: [GHC] #10345: Testsuite timeout_multiplier setting does not work as expected In-Reply-To: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> References: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> Message-ID: <063.ed658ac466fb23fc1bd287e18a6fbd5b@haskell.org> #10345: Testsuite timeout_multiplier setting does not work as expected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): Still the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 08:28:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 08:28:46 -0000 Subject: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules (was: Unhelpful error from instance Generic) In-Reply-To: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> References: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> Message-ID: <066.458a4d9054afd5a5c2761d518d0764d8@haskell.org> #10487: DeriveGeneric breaks when the same data name is used in different modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 08:33:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 08:33:37 -0000 Subject: [GHC] #10509: UnicodeSyntax documentation lists wrong symbols In-Reply-To: <045.99753819878229404545a65d82eb520e@haskell.org> References: <045.99753819878229404545a65d82eb520e@haskell.org> Message-ID: <060.c781f625b10faa74381c21677e97ae52@haskell.org> #10509: UnicodeSyntax documentation lists wrong symbols -------------------------------------+------------------------------------- Reporter: zardoz | Owner: zardoz Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by zardoz): * owner: => zardoz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 08:38:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 08:38:51 -0000 Subject: [GHC] #10512: Generic instances missing for Int32, Word64 etc. Message-ID: <051.eb2fd15ce978c34ac9303293c51292d1@haskell.org> #10512: Generic instances missing for Int32, Word64 etc. -------------------------------------+------------------------------------- Reporter: | Owner: ekmett andreas.abel | Status: new Type: feature | Milestone: request | Version: 7.10.1 Priority: normal | Operating System: Unknown/Multiple Component: Core | Type of failure: None/Unknown Libraries | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Some base types have Generic instances, like Integer, the machine-specific ones like Int32 have none. But these would be most useful when using generic Binary serialization. I think it makes sense to add Generic instances for *all* primitive types in base. I can define the instance myself, see https://github.com/agda/agda/commit/1d3710189989aced61be79c8e52945651fc94c0e {{{#!hs import GHC.Generics (Generic(..)) import qualified GHC.Generics as Gen data D_Int32 data C_Int32 instance Gen.Datatype D_Int32 where datatypeName _ = "Int32" moduleName _ = "GHC.Int32" -- packageName _ = "base" instance Gen.Constructor C_Int32 where conName _ = "" -- JPM: I'm not sure this is the right implementation... instance Generic Int32 where type Rep Int32 = Gen.D1 D_Int32 (Gen.C1 C_Int32 (Gen.S1 Gen.NoSelector (Gen.Rec0 Int32))) from x = Gen.M1 (Gen.M1 (Gen.M1 (Gen.K1 x))) to (Gen.M1 (Gen.M1 (Gen.M1 (Gen.K1 x)))) = x }}} However, as GHC.Generics is a moving target, and changes over the compiler versions, I'd rather not have to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 08:42:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 08:42:17 -0000 Subject: [GHC] #10509: UnicodeSyntax documentation lists wrong symbols In-Reply-To: <045.99753819878229404545a65d82eb520e@haskell.org> References: <045.99753819878229404545a65d82eb520e@haskell.org> Message-ID: <060.060f6a3425d7047b05f012a389c9dd02@haskell.org> #10509: UnicodeSyntax documentation lists wrong symbols -------------------------------------+------------------------------------- Reporter: zardoz | Owner: zardoz Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by zardoz): Replying to [comment:1 thomie]: > Would you like to submit a patch? Okay :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 08:53:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 08:53:28 -0000 Subject: [GHC] #10513: ghc 7.6.3 Compiler panic with Generics Message-ID: <051.c09e61e0961a632608f776aed9796e7c@haskell.org> #10513: ghc 7.6.3 Compiler panic with Generics -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently, Agda only compiles with ghc 7.4, 7.8, and 7.10, see https://code.google.com/p/agda/issues/detail?id=1558 Here is a the relevant commit: https://github.com/agda/agda/commit/f7b47de0cb167514f6db859b204abd638887b76f Generics do not seem to work properly in ghc 7.6 {{{ [ 92 of 312] Compiling Agda.Syntax.Abstract.Name ( src/full/Agda/Syntax/Abstract/Name.hs, dist/build/Agda/Syntax/Abstract/Name.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: Agda-2.4.3:Agda.Syntax.Fixity.D1PrecedenceLevel{tc a4mIV} [(rc0D, Type constructor `Agda-2.4.3:Agda.Syntax.Fixity.Fixity'{tc rc0D}'), (r4mFT, Type constructor `Agda-2.4.3:Agda.Syntax.Fixity.Precedence{tc r4mFT}'), [?] (r4mKa, Identifier `Agda-2.4.3:Agda.Syntax.Fixity.$fTypeable1ThingWithFixity{v r4mKa}'), (r4mKb, Identifier `Agda-2.4.3:Agda.Syntax.Fixity.$fGenericThingWithFixity{v r4mKb}'), (r4mKc,ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: <
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I don't know whether you are maintaining old ghcs, but it seems we have to drop Generics until we drop support for ghc 7.6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 08:59:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 08:59:18 -0000 Subject: [GHC] #10514: Generic for existential types Message-ID: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> #10514: Generic for existential types -------------------------------------+------------------------------------- Reporter: | Owner: ekmett andreas.abel | Status: new Type: feature | Milestone: request | Version: 7.10.1 Priority: normal | Operating System: Unknown/Multiple Component: Core | Type of failure: None/Unknown Libraries | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I have some use for Generic for an existential type which is constraint to be Generic. {{{!#hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE StandaloneDeriving #-} import GHC.Generics data U = forall a. (Generic a) => U a -- deriving (Generic) -- Can't make a derived instance of ?Generic U?: -- Constructor ?U? has existentials or constraints in its type -- Possible fix: use a standalone deriving declaration instead -- deriving instance Generic U -- Can't make a derived instance of ?Generic U?: -- U must be a vanilla data constructor -- In the stand-alone deriving instance for ?Generic U? data D1Ser data C1_0Ser instance Generic U where type Rep U = D D1Ser (C1 C1_0Ser (S1 NoSelector (Rep a))) -- Not in scope: type variable ?a? -- How to bring the existential type `a' into scope? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 09:00:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 09:00:59 -0000 Subject: [GHC] #10514: Generic for existential types In-Reply-To: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> References: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> Message-ID: <066.2b5b613966720fe07b2d82f58cb3e915@haskell.org> #10514: Generic for existential types -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by andreas.abel: Old description: > I have some use for Generic for an existential type which is constraint > to be Generic. > > {{{!#hs > > {-# LANGUAGE DeriveGeneric #-} > {-# LANGUAGE ExistentialQuantification #-} > {-# LANGUAGE StandaloneDeriving #-} > > import GHC.Generics > > data U = forall a. (Generic a) => U a > -- deriving (Generic) > -- Can't make a derived instance of ?Generic U?: > -- Constructor ?U? has existentials or constraints in its type > -- Possible fix: use a standalone deriving declaration instead > > -- deriving instance Generic U > -- Can't make a derived instance of ?Generic U?: > -- U must be a vanilla data constructor > -- In the stand-alone deriving instance for ?Generic U? > > data D1Ser > data C1_0Ser > > instance Generic U where > type Rep U = D D1Ser (C1 C1_0Ser (S1 NoSelector (Rep a))) > -- Not in scope: type variable ?a? > > -- How to bring the existential type `a' into scope? > > }}} New description: I have some use for Generic for an existential type which is constraint to be Generic. {{{#!hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE StandaloneDeriving #-} import GHC.Generics data U = forall a. (Generic a) => U a deriving (Generic) -- TRY 1 -- Can't make a derived instance of ?Generic U?: -- Constructor ?U? has existentials or constraints in its type -- Possible fix: use a standalone deriving declaration instead deriving instance Generic U -- TRY 2 -- Can't make a derived instance of ?Generic U?: -- U must be a vanilla data constructor -- In the stand-alone deriving instance for ?Generic U? data D1Ser data C1_0Ser instance Generic U where -- TRY 3 type Rep U = D D1Ser (C1 C1_0Ser (S1 NoSelector (Rep a))) -- Not in scope: type variable ?a? -- How to bring the existential type `a' into scope? }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 09:03:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 09:03:54 -0000 Subject: [GHC] #10511: Simplify some preprocessor expressions In-Reply-To: <045.698f4b8298888964595c9d1036b07fd4@haskell.org> References: <045.698f4b8298888964595c9d1036b07fd4@haskell.org> Message-ID: <060.67a9c46b5ca305e6811bf56d31fef917@haskell.org> #10511: Simplify some preprocessor expressions -------------------------------------+------------------------------------- Reporter: Berdes | Owner: Berdes Type: task | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: D981 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"ce53138ff0d156e9f229d0adab745d2d4cfaf582/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ce53138ff0d156e9f229d0adab745d2d4cfaf582" Delete _MSC_VER when not necessary, fix #10511 Simplify some preprocessor expressions involving `_MSC_VER` because `_WIN32` is always defined when `_MSC_VER` is. Differential Revision: https://phabricator.haskell.org/D981 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 09:06:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 09:06:16 -0000 Subject: [GHC] #10509: UnicodeSyntax documentation lists wrong symbols In-Reply-To: <045.99753819878229404545a65d82eb520e@haskell.org> References: <045.99753819878229404545a65d82eb520e@haskell.org> Message-ID: <060.c47eba911048f36633e37f881070e743@haskell.org> #10509: UnicodeSyntax documentation lists wrong symbols -------------------------------------+------------------------------------- Reporter: zardoz | Owner: zardoz Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by zardoz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 09:08:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 09:08:39 -0000 Subject: [GHC] #10511: Simplify some preprocessor expressions In-Reply-To: <045.698f4b8298888964595c9d1036b07fd4@haskell.org> References: <045.698f4b8298888964595c9d1036b07fd4@haskell.org> Message-ID: <060.f86b1dbdf2062a95108493bf41b6ac00@haskell.org> #10511: Simplify some preprocessor expressions -------------------------------------+------------------------------------- Reporter: Berdes | Owner: Berdes Type: task | Status: closed Priority: low | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: D981 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed * milestone: => 7.10.2 Comment: Thanks. Feel free to cleanup other things if you see them. First discuss if it would be a very large patch, since we prefer to do those only if they have significant benefit. The problem is that they make it more difficult to use 'git blame' effectively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 09:09:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 09:09:14 -0000 Subject: [GHC] #10511: Simplify some preprocessor expressions In-Reply-To: <045.698f4b8298888964595c9d1036b07fd4@haskell.org> References: <045.698f4b8298888964595c9d1036b07fd4@haskell.org> Message-ID: <060.e5de1d69f8a51dbdcbb5fa36114bd50b@haskell.org> #10511: Simplify some preprocessor expressions -------------------------------------+------------------------------------- Reporter: Berdes | Owner: Berdes Type: task | Status: closed Priority: low | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D981 -------------------------------------+------------------------------------- Changes (by thomie): * differential: D981 => Phab:D981 * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 09:09:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 09:09:41 -0000 Subject: [GHC] #10511: Simplify some preprocessor expressions In-Reply-To: <045.698f4b8298888964595c9d1036b07fd4@haskell.org> References: <045.698f4b8298888964595c9d1036b07fd4@haskell.org> Message-ID: <060.72076f725481291e3457871cf9e63499@haskell.org> #10511: Simplify some preprocessor expressions -------------------------------------+------------------------------------- Reporter: Berdes | Owner: Berdes Type: task | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D981 -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 7.10.2 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 09:19:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 09:19:34 -0000 Subject: [GHC] #10509: UnicodeSyntax documentation lists wrong symbols In-Reply-To: <045.99753819878229404545a65d82eb520e@haskell.org> References: <045.99753819878229404545a65d82eb520e@haskell.org> Message-ID: <060.eb730b6c2336acf767db7742526896bc@haskell.org> #10509: UnicodeSyntax documentation lists wrong symbols -------------------------------------+------------------------------------- Reporter: zardoz | Owner: zardoz Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"016bbfd261b91193baa99ec008b469a70c66b8be/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="016bbfd261b91193baa99ec008b469a70c66b8be" docs: Fix unicode alternatives table (fixes #10509). The alternatives table gave the wrong glyphs for LEFTWARDS resp. RIGHTWARDS ARROW-TAIL notation. The listed codepoint was correct, but the entities corresponded to characters different from those codepoints. This also adds the glyphs for LEFTWARDS resp. RIGHTWARDS DOUBLE ARROW-TAIL, which were formerly missing, and the PROPORTION glyph, which was formerly given as ASCII. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 09:20:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 09:20:19 -0000 Subject: [GHC] #10509: UnicodeSyntax documentation lists wrong symbols In-Reply-To: <045.99753819878229404545a65d82eb520e@haskell.org> References: <045.99753819878229404545a65d82eb520e@haskell.org> Message-ID: <060.307c428e49c243a55189f3fcdf1b0168@haskell.org> #10509: UnicodeSyntax documentation lists wrong symbols -------------------------------------+------------------------------------- Reporter: zardoz | Owner: zardoz Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Documentation | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed * milestone: => 7.12.1 Comment: Thanks, looks good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 09:40:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 09:40:22 -0000 Subject: [GHC] #10345: Testsuite timeout_multiplier setting does not work as expected In-Reply-To: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> References: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> Message-ID: <063.f56853f732bd4136cbfcc484a9f3acac@haskell.org> #10345: Testsuite timeout_multiplier setting does not work as expected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Should I try building Phab:D202 or do you have a smaller testcase? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 09:45:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 09:45:02 -0000 Subject: [GHC] #10345: Testsuite timeout_multiplier setting does not work as expected In-Reply-To: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> References: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> Message-ID: <063.9a821e83160222200cbf0fae085575a4@haskell.org> #10345: Testsuite timeout_multiplier setting does not work as expected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): I'm afraid I don't have a smaller one :-/ If you want to build D202 please note that it changes format of interface files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 09:55:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 09:55:37 -0000 Subject: [GHC] #10345: Testsuite timeout_multiplier setting does not work as expected In-Reply-To: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> References: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> Message-ID: <063.4f59ed3282de2317a79ebbb26f6ad8e3@haskell.org> #10345: Testsuite timeout_multiplier setting does not work as expected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Oh, I see it now. Fix coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 12:15:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 12:15:01 -0000 Subject: [GHC] #10508: comipleExpr or :def in GHCi rejects valid multiline expr or accepts invalid expr In-Reply-To: <046.c1b1b2bc0314b9941dba83381f0b0248@haskell.org> References: <046.c1b1b2bc0314b9941dba83381f0b0248@haskell.org> Message-ID: <061.b45292d1acf3b190cbe9b6fb0394ff94@haskell.org> #10508: comipleExpr or :def in GHCi rejects valid multiline expr or accepts invalid expr -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Phab:D974 Related Tickets: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"d20031d4c88b256cdae264cb05d9d850e973d956/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d20031d4c88b256cdae264cb05d9d850e973d956" Add parseExpr and compileParsedExpr and use them in GHC API and GHCi Summary: This commit brings following changes and fixes: * Implement parseExpr and compileParsedExpr; * Fix compileExpr and dynCompilerExpr, which returned `()` for empty expr; * Fix :def and :cmd, which didn't work if `IO` or `String` is not in scope; * Use GHCiMonad instead IO in :def and :cmd; * Clean PrelInfo: delete dead comment and duplicate entries, add assertion. See new tests for more details. Test Plan: ./validate Reviewers: austin, dterei, simonmar Reviewed By: simonmar Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D974 GHC Trac Issues: #10508 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 15:12:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 15:12:30 -0000 Subject: [GHC] #10496: Update Haddock for 7.10.2 In-Reply-To: <042.4390876b176ea384032fa57b3511f6a4@haskell.org> References: <042.4390876b176ea384032fa57b3511f6a4@haskell.org> Message-ID: <057.f9fe748947bfcbd4cc23fb0834143165@haskell.org> #10496: Update Haddock for 7.10.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | thoughtpolice Priority: high | Status: new Component: libraries | Milestone: 7.10.2 (other) | Version: Resolution: | Keywords: haddock Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fuuzetsu): New candidate: f48474f640387dca4b42182c1ac78ba30865742d -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 15:48:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 15:48:51 -0000 Subject: [GHC] #4440: time004 fails depending on the date In-Reply-To: <056.7cae293d5c5c202bca7e240bc720a730@haskell.org> References: <056.7cae293d5c5c202bca7e240bc720a730@haskell.org> Message-ID: <071.29485e6a968accade2380f14bdd46e40@haskell.org> #4440: time004 fails depending on the date -------------------------------------+------------------------------------- Reporter: | Owner: daniel.is.fischer | Status: closed Type: bug | Milestone: 7.12.1 Priority: low | Version: 7.1 Component: Test Suite | Keywords: Resolution: wontfix | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: `old-time` has been removed from the GHC tree in 86dda8f7adb887eb376a938dd48780e503b53a08 and 6efe5729252ea50843e1b04e21c7a3e1769a3434. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 15:55:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 15:55:08 -0000 Subject: [GHC] #7305: T5975a is broken on Windows In-Reply-To: <047.9f0dc90b5cf8e0afa160ab6e09aa4504@haskell.org> References: <047.9f0dc90b5cf8e0afa160ab6e09aa4504@haskell.org> Message-ID: <062.1f29868a6d31b6c3671a9de659df9da0@haskell.org> #7305: T5975a is broken on Windows -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.6.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: gintas (removed) * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 16:12:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 16:12:32 -0000 Subject: [GHC] #960: Lexical call site string In-Reply-To: <057.da5a7918d3a237f53bbf07bfe2771af6@haskell.org> References: <057.da5a7918d3a237f53bbf07bfe2771af6@haskell.org> Message-ID: <072.4d06ee154f39060232892bdb2800f78d@haskell.org> #960: Lexical call site string -------------------------------------+------------------------------------- Reporter: paul@? | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: 6.6 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: N/A Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 16:15:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 16:15:35 -0000 Subject: [GHC] #10340: Type inference regression with Any In-Reply-To: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> References: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> Message-ID: <058.fb465075a7af8159cb36df4ea3fafc34@haskell.org> #10340: Type inference regression with Any -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 16:40:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 16:40:28 -0000 Subject: [GHC] #10507: Looping with type level naturals In-Reply-To: <047.5fd95e048f3c3bca89022fe8d424335a@haskell.org> References: <047.5fd95e048f3c3bca89022fe8d424335a@haskell.org> Message-ID: <062.7bd893b3e26b68f054dbcb649c746006@haskell.org> #10507: Looping with type level naturals -------------------------------------+------------------------------------- Reporter: jhendrix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 16:45:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 16:45:39 -0000 Subject: [GHC] #8435: Do not copy stack after stack overflow In-Reply-To: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> References: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> Message-ID: <060.74cc546f9f3551db6fd996ff6dcfed6c@haskell.org> #8435: Do not copy stack after stack overflow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D938 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"892c3e98bcef50aa56ec818f4d001aee36e05bbc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="892c3e98bcef50aa56ec818f4d001aee36e05bbc" Do not copy stack after stack overflow, refix #8435 Summary: This was reverted in d70b19bfb5ed79b22c2ac31e22f46782fc47a117 and is a part of the reason for #10445. Test Plan: validate Reviewers: ezyang, simonmar, austin Reviewed By: simonmar, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D938 GHC Trac Issues: #8435 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 16:45:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 16:45:40 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize In-Reply-To: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> References: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> Message-ID: <057.8332772ca17d5828bca33ba5f0c4a097@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D938, | Phab:D961 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"892c3e98bcef50aa56ec818f4d001aee36e05bbc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="892c3e98bcef50aa56ec818f4d001aee36e05bbc" Do not copy stack after stack overflow, refix #8435 Summary: This was reverted in d70b19bfb5ed79b22c2ac31e22f46782fc47a117 and is a part of the reason for #10445. Test Plan: validate Reviewers: ezyang, simonmar, austin Reviewed By: simonmar, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D938 GHC Trac Issues: #8435 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 16:47:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 16:47:29 -0000 Subject: [GHC] #8435: Do not copy stack after stack overflow In-Reply-To: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> References: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> Message-ID: <060.cbef539a47e7ec30fc531b2ef95aef5f@haskell.org> #8435: Do not copy stack after stack overflow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: archblob Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D938 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 17:02:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 17:02:45 -0000 Subject: [GHC] #1009: GHC Performance Index In-Reply-To: <047.30acc15c10473104aafbbefab63a08b2@haskell.org> References: <047.30acc15c10473104aafbbefab63a08b2@haskell.org> Message-ID: <062.7c86f6de20c991bc7efc80935ef078d3@haskell.org> #1009: GHC Performance Index -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 6.6 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: N/A Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: => None/Unknown * resolution: => fixed * milestone: ? => 7.12.1 Comment: I think we have this now, thanks to Joachim: https://perf.haskell.org/ghc/ Setting are in this file: https://github.com/nomeata/gipeda/blob/master/ghc/settings.yaml -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 17:13:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 17:13:12 -0000 Subject: [GHC] #7371: Supporting old GHC versions in our libraries In-Reply-To: <044.073d0c6083c0b5143c6233182e57bf02@haskell.org> References: <044.073d0c6083c0b5143c6233182e57bf02@haskell.org> Message-ID: <059.60372aeac25c11e0b4b8297f733168a4@haskell.org> #7371: Supporting old GHC versions in our libraries -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Not a GHC task. But library maintainers do this by using Travis to test their library with several versions of GHC. See for example: https://github.com/haskell/filepath/blob/master/.travis.yml Phabricator is also configured to be 2 generations older than HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 17:40:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 17:40:41 -0000 Subject: [GHC] #10392: typo in Debug.Trace.traceShowM example In-Reply-To: <048.7a8a138fe18cc1cc48d044dd03dfc1d1@haskell.org> References: <048.7a8a138fe18cc1cc48d044dd03dfc1d1@haskell.org> Message-ID: <063.44570ea31979f8d50e4ae4879af8969a@haskell.org> #10392: typo in Debug.Trace.traceShowM example -------------------------------------+------------------------------------- Reporter: sebastian | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"dd5cac7cd379367d29c3ca486989f5c32e5ae848/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dd5cac7cd379367d29c3ca486989f5c32e5ae848" Fix typo in `traceShowM` haddock comment (#10392) [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 17:40:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 17:40:41 -0000 Subject: [GHC] #10497: Misc bugs with User Guide In-Reply-To: <049.6fde49e612d7b03a5a1adcd99eaad40d@haskell.org> References: <049.6fde49e612d7b03a5a1adcd99eaad40d@haskell.org> Message-ID: <064.8caa89683ab9c7e0cd120aa8ef30587d@haskell.org> #10497: Misc bugs with User Guide -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"0a086c82638c443df10fa2f80896e30107e546e3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0a086c82638c443df10fa2f80896e30107e546e3" Docs: it's `gv --orientation=seascape` nowadays (#10497) [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 17:41:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 17:41:51 -0000 Subject: [GHC] #10392: typo in Debug.Trace.traceShowM example In-Reply-To: <048.7a8a138fe18cc1cc48d044dd03dfc1d1@haskell.org> References: <048.7a8a138fe18cc1cc48d044dd03dfc1d1@haskell.org> Message-ID: <063.a29b6fde99975c7af313b35f13f06978@haskell.org> #10392: typo in Debug.Trace.traceShowM example -------------------------------------+------------------------------------- Reporter: sebastian | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 7.12.1 Comment: Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 17:43:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 17:43:11 -0000 Subject: [GHC] #10497: Misc bugs with User Guide In-Reply-To: <049.6fde49e612d7b03a5a1adcd99eaad40d@haskell.org> References: <049.6fde49e612d7b03a5a1adcd99eaad40d@haskell.org> Message-ID: <064.c6479f28620213d9a81a9c0226b5cfa3@haskell.org> #10497: Misc bugs with User Guide -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Thanks. The image issue is also resolved already, in #10496. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 17:43:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 17:43:33 -0000 Subject: [GHC] #10497: Misc bugs with User Guide In-Reply-To: <049.6fde49e612d7b03a5a1adcd99eaad40d@haskell.org> References: <049.6fde49e612d7b03a5a1adcd99eaad40d@haskell.org> Message-ID: <064.36f99697926349ef5146e18fe99686be@haskell.org> #10497: Misc bugs with User Guide -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Documentation | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 17:45:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 17:45:56 -0000 Subject: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.c6bc899ba6089c4de7e413b5537ca45c@haskell.org> #10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | MonadFail Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #8004, #4384 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * keywords: AMP => AMP MonadFail Old description: > == What? > > Implement a `DEPRECATED`-variant to be attached to method declarations > (in `class`-definitions) with default implementations that triggers > warnings when > > 1. When an `instance` overrides the default implementation of that > method, and/or > 2. when such a deprecated method is explicitly im/(re)exported via > `Class(method)`-syntax. > > But not when > > 1. imported as e.g. `import Mod1 (Class, method)` (which doesn't require > `method` to be a method of `Class`), nor when > 2. merely referring to `method` in an expression (as that doesn't > require `method` to be a method either). > > Syntax suggestion: > > {{{ > class C a where > foo :: a > > bar :: a -> a > bar x = x > > doo :: a > > -- this is the new syntax > {-# DEPRECATED C(bar) "'bar' is going to become a non-method soon, please > avoid referring to it as a method" #-} > > -- this works already now > {-# DEPRECATED foo "'foo' is obsolete and going away soon, please use > 'doo' instead" #-} > }}} > > == Why? > > This would aid long-term transitions like phasing out class-methods, such > as e.g. `Monad(return)` in the spirit of #4834: > > With the AMP, `Monad(return)` being a class method becomes an historic > artifact. The ideal long-term situation would rather be to have `return` > become a top-level definition (i.e. outside the `Monad`-class), > generalised to `Applicative` just aliasing `Applicative(pure)`, i.e. > > {{{#!hs > return :: Applicative f => a -> f a > return = pure > }}} > > This may be beneficial for things like ApplicativeDo which otherwise > would require a `return` to be handled is if it was `pure` in order to > weaken the type-constraint in an `do`-expression like e.g. > > {{{#!hs > do { x <- f; return (fst x) } > }}} > > Right now, we can attach a `DEPRECATED`-pragma to the `return`-class- > method. That however would trigger warnings on ''all'' uses of `return`, > rather than only when using `return` in a context that requires it to be > a class-method (like overriding `return` in instance definitions, or > importing/exporting it via the explicit `Monad(return)`-syntax) > > Instead we need a way to warn about such uses of `return` which assume it > to be a class-method, in order to phase out such uses. > > NB: This will probably require additional discussions, but we shouldn't > wait too long, if we want to integrate the AMP into a future Haskell > Report (for which we should try to clean up historic warts such as > `Monad(return)` if feasable). New description: See Design/MethodDeprecations for details -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 17:49:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 17:49:26 -0000 Subject: [GHC] #9991: runghc shows the value produced by main when its type is a non-() Show instance In-Reply-To: <046.b9f38b4c270b0f9b3352ad5f26fb4a6f@haskell.org> References: <046.b9f38b4c270b0f9b3352ad5f26fb4a6f@haskell.org> Message-ID: <061.4e394ab0384155bda871b188ba736420@haskell.org> #9991: runghc shows the value produced by main when its type is a non-() Show instance -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * type: bug => task Comment: Looks fixed in 7.10, but we could still use a test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 18:03:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 18:03:02 -0000 Subject: [GHC] #10217: Provide link to GPG signature on download page. In-Reply-To: <042.3be3cfd04f796daabfe8f3ac5fc1b22c@haskell.org> References: <042.3be3cfd04f796daabfe8f3ac5fc1b22c@haskell.org> Message-ID: <057.f8f543e4d537e5160a6a7ee08268a955@haskell.org> #10217: Provide link to GPG signature on download page. -------------------------------------+------------------------------------- Reporter: f-a | Owner: Type: feature request | thoughtpolice Priority: normal | Status: new Component: Documentation | Milestone: 7.12.1 Resolution: | Version: Operating System: Unknown/Multiple | Keywords: GPG, Type of failure: Documentation | signature bug | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thoughtpolice * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 18:09:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 18:09:25 -0000 Subject: [GHC] #1574: Broken link testing In-Reply-To: <056.4175938f47088948409e38405f44cd8f@haskell.org> References: <056.4175938f47088948409e38405f44cd8f@haskell.org> Message-ID: <071.981ae105aadbbcf5a8cf64393a7e2ac5@haskell.org> #1574: Broken link testing -------------------------------------+------------------------------------- Reporter: iampure@? | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.12.1 Component: Documentation | Version: 6.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 18:34:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 18:34:23 -0000 Subject: [GHC] #9665: Add "since" information to LANGUAGE extensions in GHC user guide In-Reply-To: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> References: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> Message-ID: <066.d43945c80cb0f69c989daf5424da7e97@haskell.org> #9665: Add "since" information to LANGUAGE extensions in GHC user guide -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer * priority: high => normal Comment: The file to change is `docs/users_guide/flags.xml`. Bonus: you'll learn something about all the language extensions GHC offers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 18:41:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 18:41:11 -0000 Subject: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas In-Reply-To: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> References: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> Message-ID: <059.169bb75c23273c75bfad665f76c31c47@haskell.org> #4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): peddle: did you make any progress with this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 18:43:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 18:43:48 -0000 Subject: [GHC] #9095: make sdist picks up test files In-Reply-To: <045.5bc6b697ad76318e7d59aba1132cfee1@haskell.org> References: <045.5bc6b697ad76318e7d59aba1132cfee1@haskell.org> Message-ID: <060.f11bc359236d1dbe1d73277a63bd7cc0@haskell.org> #9095: make sdist picks up test files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: thomie Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => * owner: => thomie -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 18:47:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 18:47:19 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.dfe934924290550a824333a4915d9587@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Changes (by thomie): * owner: => osa1 * differential: => Phab:D978 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 18:52:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 18:52:53 -0000 Subject: [GHC] #10175: User's Guide 7.4.4 ExplicitTypeOperators typo In-Reply-To: <043.b535f2862d0e2897a77c4244ce1cf331@haskell.org> References: <043.b535f2862d0e2897a77c4244ce1cf331@haskell.org> Message-ID: <058.5e2d3f1770aa438833d3e3ae6e6b8b2b@haskell.org> #10175: User's Guide 7.4.4 ExplicitTypeOperators typo -------------------------------------+------------------------------------- Reporter: Shou | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: typo Operating System: Unknown/Multiple | extension Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"b07dcccd2219eb2d08868bc6144f289b4e0aadf1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b07dcccd2219eb2d08868bc6144f289b4e0aadf1" Docs: `-XTypeOperators` (#10175) [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 18:53:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 18:53:45 -0000 Subject: [GHC] #10175: User's Guide 7.4.4 ExplicitTypeOperators typo In-Reply-To: <043.b535f2862d0e2897a77c4244ce1cf331@haskell.org> References: <043.b535f2862d0e2897a77c4244ce1cf331@haskell.org> Message-ID: <058.e508e9cbbcc1fa17a65f3dbfc56af47e@haskell.org> #10175: User's Guide 7.4.4 ExplicitTypeOperators typo -------------------------------------+------------------------------------- Reporter: Shou | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Documentation | Version: 7.8.4 Resolution: fixed | Keywords: typo Operating System: Unknown/Multiple | extension Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 7.12.1 Comment: Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 18:57:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 18:57:48 -0000 Subject: [GHC] #10468: debug test case fails on Windows In-Reply-To: <045.b19678979c06629a2acceac03a72cd6b@haskell.org> References: <045.b19678979c06629a2acceac03a72cd6b@haskell.org> Message-ID: <060.5d3b030a13d88bc8310f5c8ca0392f32@haskell.org> #10468: debug test case fails on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: scpmw Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.11 (Debugging) | Keywords: Resolution: fixed | Architecture: Operating System: Windows | Unknown/Multiple Type of failure: None/Unknown | Test Case: debug Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 18:57:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 18:57:51 -0000 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images In-Reply-To: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> References: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> Message-ID: <059.976b62e076ad110ce1c9bcd2968eeb35@haskell.org> #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D958, | Phab:D970 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 18:57:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 18:57:54 -0000 Subject: [GHC] #8435: Do not copy stack after stack overflow In-Reply-To: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> References: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> Message-ID: <060.86c0dc40fa6189df61f89868e7d928c8@haskell.org> #8435: Do not copy stack after stack overflow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: archblob Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D938 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 19:01:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 19:01:35 -0000 Subject: [GHC] #10479: Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh In-Reply-To: <045.1ef1ca690686af7d2265216e3878b27c@haskell.org> References: <045.1ef1ca690686af7d2265216e3878b27c@haskell.org> Message-ID: <060.fb92494bd7a2e3b6233bfa7021b9f446@haskell.org> #10479: Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Package system | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: 9506 | Differential Revisions: Phab:D922 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10` - the RC will ship these bugfixes, but we don't have to wait on a release from them. I'm going to go ahead and close this; next week we'll comb over the libraries and update them to their final release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 19:01:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 19:01:49 -0000 Subject: [GHC] #10480: Ship Cabal with Windows filepath fix In-Reply-To: <045.437e09638d10b0a54f88e3ea0078e353@haskell.org> References: <045.437e09638d10b0a54f88e3ea0078e353@haskell.org> Message-ID: <060.446e096aea8c8d20f9e3e5883d561f08@haskell.org> #10480: Ship Cabal with Windows filepath fix -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: merge Priority: high | Milestone: 7.10.2 Component: libraries | Version: 7.10.1 (other) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => merge Comment: Merged to `ghc-7.10` - the RC will ship these bugfixes, but we don't have to wait on a release from them. I'm going to go ahead and close this; next week we'll comb over the libraries and update them to their final release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 19:02:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 19:02:17 -0000 Subject: [GHC] #10480: Ship Cabal with Windows filepath fix In-Reply-To: <045.437e09638d10b0a54f88e3ea0078e353@haskell.org> References: <045.437e09638d10b0a54f88e3ea0078e353@haskell.org> Message-ID: <060.d2c75d8dfcc86a5aad22d0c7c8aa4d97@haskell.org> #10480: Ship Cabal with Windows filepath fix -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: libraries | Version: 7.10.1 (other) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 19:02:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 19:02:53 -0000 Subject: [GHC] #10496: Update Haddock for 7.10.2 In-Reply-To: <042.4390876b176ea384032fa57b3511f6a4@haskell.org> References: <042.4390876b176ea384032fa57b3511f6a4@haskell.org> Message-ID: <057.45d84c1b88f79b0d247972630ecc222d@haskell.org> #10496: Update Haddock for 7.10.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | thoughtpolice Priority: high | Status: closed Component: libraries | Milestone: 7.10.2 (other) | Version: Resolution: fixed | Keywords: haddock Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Done, merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 19:10:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 19:10:10 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.7bdd5587d5f1421ced628a5320a7f13a@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: scpmw (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 19:13:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 19:13:06 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.889cc4b07a006fbfd398cf956787d6e9@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): I'm trying to understand this ticket; do we need to compile these functions: {{{ minDbl :: Double -> Double -> Double minDbl !d1 !d2 = if d1 < d2 then d1 else d2 minDbl' :: Double -> Double -> Double minDbl' !d1 !d2 = if d2 < d1 then d2 else d1 }}} to branchless code(using `movsd` with right argument ordering, and similarly `movss` for `Float`), or are we only interested in branchless `Ord.min`, `Ord.max` etc.? E.g. something like this: {{{ mindbl'' :: Double -> Double -> double mindbl'' (D# d1) (D# d2) = ... use new primop here ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 19:48:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 19:48:27 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2310515=3A_ghc=3A_panic=3A_tyThingTyCon_Ide?= =?utf-8?b?bnRpZmllciDigJgkZlN0ZW5jaWw6LmEoLCwsLCk34oCZ?= Message-ID: <046.1a69329a1db1e1b89b8b31699fd5aae1@haskell.org> #10515: ghc: panic: tyThingTyCon Identifier ?$fStencil:.a(,,,,)7? -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Has anyone seen something like this? {{{ : ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150519 for x86_64-unknown-linux): tyThingTyCon Identifier ?$fStencil:.a(,,,,)7? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 20:12:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 20:12:25 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.31077374c43fc8b95b79e3826cf43244@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by scpmw): I didn't actually change how `TickForCoverage` behaves, so these design decisions actually go back to HPC. Changing it would be quite easy - probably just replacing a few `addTickLHsExprNever` in `addTickHsExpr` by `addTickLHsExpr`. On the other hand I'm not quite sure we want that. The original reason was probably that it leads to rather silly stacks of ticks on functions that are applied to many arguments. Plus both source notes and HPC ticks would instantly float upwards, which means that we are not actually gaining any information. Source notes get merged eventually, but for HPC it certainly would make a performance difference. Do you positively need every single expression annotated? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 20:19:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 20:19:08 -0000 Subject: [GHC] #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.7aafe5a933bec46369841963f1a832ab@haskell.org> #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hsyl20): I have made a patch for this one (https://phabricator.haskell.org/D985) With the example given in the ticket I get: {{{ Linux (64bit) 7.10.1 174 MB / 20209 calls to mmap HEAD with patch 95 KB / 332 calls to mmap }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 20:50:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 20:50:10 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.8abb6432c14cedb0af1f5a73329f34eb@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gridaphobe): I don't think we need every expression annotated, but we do need every '''identifier''' annotated. This is in the context of LiquidHaskell, where we infer refinement types for Haskell functions. One output mode we have (which is invaluable in my experience) is an HTML version of the Haskell module where each identifier is annotated with a popup containing its refined type. To create this annotated HTML document, we do need precise source locations for each occurrence of an identifier (and lambda expressions). I doubt the performance overhead would be that bad if we restrict the extra ticks to identifiers and lambdas, but if it turns out to be a problem I'd also be perfectly happy with a separate `TickEverything` strategy that we can select. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 23:01:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 23:01:28 -0000 Subject: [GHC] #10152: Testsuite diffs can be misleading when normalisers are in use In-Reply-To: <045.9e8cc1c7996562f5a21caab577ceef49@haskell.org> References: <045.9e8cc1c7996562f5a21caab577ceef49@haskell.org> Message-ID: <060.8e787e52d6010dfd43134868aafa8fcb@haskell.org> #10152: Testsuite diffs can be misleading when normalisers are in use -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: low | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"5ddd90415f307cac72d75d86da58e552b168ee30/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5ddd90415f307cac72d75d86da58e552b168ee30" Testsuite: diff non-whitespace normalised output (#10152) On a test failure, we show a diff between the expected and the actual output. The method of how we do this has changed a couple of times: * In 2007: 9951189ccf90b709436fa55ee49eeef031f79f4e "On failure, diff the normalised test outputs" * In 2011: 3019b1e409c129ef7af63e6a7408fb36ec44444b "When the output files differ, present the diffs between the *actual* output, not the normalised output. The latter may have newlines removed, making the diff unreadable." * In 2015 (now): do something in between. - Do apply the normalisers again, to make the diff smaller (only showing the actual problem). - But don't apply normalise_whitespace, as it indeed makes the diff unreadable. Differential Revision: https://phabricator.haskell.org/D984 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 23:01:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 23:01:28 -0000 Subject: [GHC] #10345: Testsuite timeout_multiplier setting does not work as expected In-Reply-To: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> References: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> Message-ID: <063.c085344fbb5d3a3ab0e2ba34c3606bcc@haskell.org> #10345: Testsuite timeout_multiplier setting does not work as expected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"6e542a62e070b113f95908315c81d01c300d8803/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6e542a62e070b113f95908315c81d01c300d8803" Testsuite: add function compile_timeout_multiplier (#10345) And rename timeout_multiplier to run_timeout_multiplier. timeout_multiplier was added in commit a00389794b839971c7d52ead9e8570bfaa25ac55. The name suggested that it would affect any test, but it actually only affected tests that had a run component, and only that run component (as needed by test T367). Differential Revision: https://phabricator.haskell.org/D982 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 23:02:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 23:02:48 -0000 Subject: [GHC] #10152: Testsuite diffs can be misleading when normalisers are in use In-Reply-To: <045.9e8cc1c7996562f5a21caab577ceef49@haskell.org> References: <045.9e8cc1c7996562f5a21caab577ceef49@haskell.org> Message-ID: <060.02c74e083c05f851b90f31ee4c9faf4f@haskell.org> #10152: Testsuite diffs can be misleading when normalisers are in use -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: closed Priority: low | Milestone: 7.12.1 Component: Test Suite | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 23:06:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 23:06:16 -0000 Subject: [GHC] #10345: Testsuite timeout_multiplier setting does not work as expected In-Reply-To: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> References: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> Message-ID: <063.4f83bbae25cc5cea19e66dba064d0f36@haskell.org> #10345: Testsuite timeout_multiplier setting does not work as expected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D982 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * differential: => Phab:D982 * resolution: => fixed * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 12 23:21:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Jun 2015 23:21:29 -0000 Subject: [GHC] #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.70cdacc72083cd673e05dad7fd826f55@haskell.org> #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D985 -------------------------------------+------------------------------------- Changes (by hsyl20): * cc: simonmar (added) * status: new => patch * differential: => Phab:D985 * component: Compiler => Runtime System -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 07:14:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 07:14:57 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.fbdcefc5a39100af098c3e86748d1845@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): the idea is not to use it for the normal comparison code, but to make it available for those who need suitable supporting primops. *THOUGH* if we can provide suitable instruction level versions of the Ord based min and max, thats a thing we can think about too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 07:20:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 07:20:31 -0000 Subject: [GHC] #10492: rpath & shared libraries in ghc 7.10.1 In-Reply-To: <053.8e0d059d0dcafb8986911d4bd2a6c057@haskell.org> References: <053.8e0d059d0dcafb8986911d4bd2a6c057@haskell.org> Message-ID: <068.48281ce84ebcba554a5592b117fcce16@haskell.org> #10492: rpath & shared libraries in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: trommler Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by artella.coding): Replying to [comment:4 trommler]: > Closing as won't fix. Please reopen if you disagree. Hi yes I agree!. Thanks rwbarton and trommler for your help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 08:44:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 08:44:42 -0000 Subject: [GHC] #9991: runghc shows the value produced by main when its type is a non-() Show instance In-Reply-To: <046.b9f38b4c270b0f9b3352ad5f26fb4a6f@haskell.org> References: <046.b9f38b4c270b0f9b3352ad5f26fb4a6f@haskell.org> Message-ID: <061.73d48a7361bb463e389421e295e46e78@haskell.org> #9991: runghc shows the value produced by main when its type is a non-() Show instance -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9086 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #9086 Comment: I found the commit that fixed this: 55e7ab1210975e6276f3cab3ac0e1f35bcd772f0 {{{ Author: Gintautas Miliauskas <> Date: Sun Jun 8 11:49:29 2014 +0000 Do not print the result of 'main' after invoking ':main' (fixes #9086). }}} Since it has a test already, we don't have to do anything here. Berdes: please have a look at that commit and [wiki:Building/RunningTests] to see how the testsuite works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 10:40:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 10:40:03 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.d6216a5743c409c13910a7025872cfe7@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => new Comment: I am looking into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 10:40:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 10:40:20 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.da31d9bbb7980090936c0bcb3126cb2a@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 11:08:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 11:08:10 -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.075e98312ed9b40a7b6b355a85d07b76@haskell.org> #10512: Generic instances missing for Int32, Word64 etc. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): This'll be incredibly tedious, but it is the right thing to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 15:44:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 15:44:26 -0000 Subject: [GHC] #10516: PolyKinds results in incorrect reporting of type synonym parameter count Message-ID: <055.bec1f97d6a44e1f3f7ecb1a59b83df87@haskell.org> #10516: PolyKinds results in incorrect reporting of type synonym parameter count -------------------------------------+------------------------------------- Reporter: | Owner: benjamin.hodgson | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: None/Unknown Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following program is invalid because the declaration of `f` doesn't fully apply `App` to all of its arguments. {{{#!hs {-# LANGUAGE PolyKinds #-} type App f a = f a newtype X f a = X (f a) f :: f a -> X (App f) a f = X }}} However, with the `PolyKinds` extension, the error reporting is quite weird: {{{ Type synonym ?App? should have 4 arguments, but has been given 3 In the type signature for ?f?: f :: f a -> X (App f) a }}} `App` has ''two'' arguments, and I gave it ''one''! I'm guessing that `PolyKinds` makes GHC supply some implicit parameters during expansion of type synonyms, and that's what gets reported in the error message. The behaviour is correct without `PolyKinds`. I've tested this on GHC 7.8.3 (the Haskell Platform version). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 15:45:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 15:45:18 -0000 Subject: [GHC] #10516: PolyKinds results in incorrect reporting of type synonym parameter count In-Reply-To: <055.bec1f97d6a44e1f3f7ecb1a59b83df87@haskell.org> References: <055.bec1f97d6a44e1f3f7ecb1a59b83df87@haskell.org> Message-ID: <070.1702bc228ff72c8a23a2c56a2bbf80bc@haskell.org> #10516: PolyKinds results in incorrect reporting of type synonym parameter count -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by benjamin.hodgson: Old description: > The following program is invalid because the declaration of `f` doesn't > fully apply `App` to all of its arguments. > > {{{#!hs > {-# LANGUAGE PolyKinds #-} > > type App f a = f a > > newtype X f a = X (f a) > > f :: f a -> X (App f) a > f = X > }}} > > However, with the `PolyKinds` extension, the error reporting is quite > weird: > > {{{ > Type synonym ?App? should have 4 arguments, but has been given 3 > In the type signature for ?f?: f :: f a -> X (App f) a > }}} > > `App` has ''two'' arguments, and I gave it ''one''! I'm guessing that > `PolyKinds` makes GHC supply some implicit parameters during expansion of > type synonyms, and that's what gets reported in the error message. The > behaviour is correct without `PolyKinds`. > > I've tested this on GHC 7.8.3 (the Haskell Platform version). New description: The following program is invalid because the declaration of `f` doesn't fully apply `App` to all of its arguments. {{{#!hs {-# LANGUAGE PolyKinds #-} type App f a = f a newtype X f a = X (f a) f :: f a -> X (App f) a f = X }}} However, with the `PolyKinds` extension, the error reporting is quite weird: {{{ Type synonym ?App? should have 4 arguments, but has been given 3 In the type signature for ?f?: f :: f a -> X (App f) a }}} `App` has ''two'' arguments, and I gave it ''one''! I'm guessing that `PolyKinds` makes GHC supply some implicit parameters during expansion of type synonyms, and that's what gets reported in the error message. The behaviour is correct without `PolyKinds`. I've tested this on GHC 7.8.3 (the Haskell Platform version) on my 64-bit OSX Yosemite system. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 16:26:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 16:26:39 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.dccfaa7e3ad1d6fbf68af31005a7c8af@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------- Reporter: carter | Owner: osa1 Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by osa1): * owner: => osa1 Comment: Just to give a status update: I made some progress on this http://lpaste.net/134455. I'm also assigning this to myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 18:17:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 18:17:24 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.ab9c937c1a5b0e758c05028d8a436c56@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.10.2 => 7.12.1 Comment: Sigh, so unfortunately I've spent some more time futzing around with the patch, and I just don't think it can be merged in a sensible way without even more work. And even though the work seems doable I'm just very averse to the risk of it at this point, I'm afraid. I think I've even got the redundant superclass constraint patch building, but I'm just not sure it's worth it. This is most certainly a regression but realistically I'm not sure how much it will come up. There have been three users who want it (Adam, Adam and Wolfgang) and who have reported it as "please fix" AFAICS, but as Simon originally said it shouldn't affect much code, and we didn't hold the original release up for this bug anyway. Unless there is overwhelming evidence this is a common and game breaking bug that has cropped up in practice (which I'm really not sure of!), I've decided to leave this out of the release candidate, and subsequently, the final release. Wolfgang, I sincerely apologize for this as it is not an easy thing for you to work around in your paper or library, and I understand it's suboptimal (and even frustrating). But I would rather ship the significant improvements we have now for even more users to make things better. I'm sorry this one missed the boat. FTR, I tried merging in the redundant superclass constraints patch (since the improvement patch was dependent on it), which on its own has actually proved to be a bit difficult. But I'm just getting more risk aversive to this - these patches also have tons of knock on changes like error messages (which are merely a hassle), but even worse, further bugfixes of their own in more patches later - which I'd have to track, adopt and make sure are fixed. And even then, _none_ of these patches are in a released compiler - there's been churn here from Simon recently. It's not clear when to _stop_. So it's impossible to tell if I should pick up *just* that patch, or that patch + 10 others because the intermediate states are all variously broken, or that patch + the next 5 'bugfix + refactor' patches are good enough. Once I've pushed these two, I'm just not sure how *many more* I'll have to push. So I'm moving this to 7.12.1 and closing it. Simon, please re-open if you think there's more work to be done here. Again, I apologize for the lead- on with this one, but after getting closer and closer, it simply does not seem worth it I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 18:19:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 18:19:20 -0000 Subject: [GHC] #10340: Type inference regression with Any In-Reply-To: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> References: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> Message-ID: <058.16768a0c63a831fd0f5faa4460fea6c8@haskell.org> #10340: Type inference regression with Any -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.10.2 => 7.12.1 Comment: I'm moving this to 7.12.1 and closing; it's fixed, but won't be making 7.10.2. See #10009:comment:36 for more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 19:20:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 19:20:17 -0000 Subject: [GHC] #10516: PolyKinds results in incorrect reporting of type synonym parameter count In-Reply-To: <055.bec1f97d6a44e1f3f7ecb1a59b83df87@haskell.org> References: <055.bec1f97d6a44e1f3f7ecb1a59b83df87@haskell.org> Message-ID: <070.275c245725d696b16b95773be0125afc@haskell.org> #10516: PolyKinds results in incorrect reporting of type synonym parameter count -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Confirmed reproducible in HEAD and 7.10.1. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 19:20:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 19:20:36 -0000 Subject: [GHC] #10516: PolyKinds results in incorrect reporting of type synonym parameter count In-Reply-To: <055.bec1f97d6a44e1f3f7ecb1a59b83df87@haskell.org> References: <055.bec1f97d6a44e1f3f7ecb1a59b83df87@haskell.org> Message-ID: <070.48e189882448b2ef60fa0d5f15339c81@haskell.org> #10516: PolyKinds results in incorrect reporting of type synonym parameter count -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * version: 7.8.3 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 21:39:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 21:39:36 -0000 Subject: [GHC] #10517: Unexpected behavior of unsafeCoerce converting Word32 to Word8 Message-ID: <044.6c8c1993f3cf45fa7c852faf5a8b459f@haskell.org> #10517: Unexpected behavior of unsafeCoerce converting Word32 to Word8 -------------------------------------+------------------------------------- Reporter: svenk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The function `unsafeCoerce` behaves unexpected if it is used to convert `Word32` to `Word8`: {{{#!hs main = do -- prints 135 print (fromIntegral (1234567 :: Word32) :: Word8) -- prints 1234567 print (unsafeCoerce (1234567 :: Word32) :: Word8) }}} On the other hand coercing `Ptr Word32` to `Ptr Word8` or the other way around works perfectly fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 22:06:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 22:06:17 -0000 Subject: [GHC] #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants Message-ID: <045.444a98a1463923691d1d96d4356e1130@haskell.org> #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants -------------------------------------+------------------------------------- Reporter: slyfox | Owner: slyfox Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- jakzale reports: 21:47:27 < int-e> Oh, nice. Yes, indeed pprHexVal (2^32) W32 (function from cmm/PprC.hs) would result in 0xU. 21:50:29 < jakzale> int-e: yes, truncInt takes module 2^32, then go returns empty string (I guess) Here comes the test: {{{ $ cat a.cmm foo() { bits64 a; a = 0x10000000000000000; // overflows 64 bits return (a); } $ inplace/bin/ghc-stage2 -c a.cmm /tmp/ghc8580_0/ghc_2.hc: In function 'foo': /tmp/ghc8580_0/ghc_2.hc:8:7: error: error: invalid suffix "xUL" on integer constant _c0 = 0xUL; ^ }}} I've broke it with commit:43f1b2ecd1960fa7377cf55a2b97c66059a701ef when introduced truncation that can generate more zeroes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 22:11:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 22:11:22 -0000 Subject: [GHC] #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants In-Reply-To: <045.444a98a1463923691d1d96d4356e1130@haskell.org> References: <045.444a98a1463923691d1d96d4356e1130@haskell.org> Message-ID: <060.80430daf021b37171c202bd3411a8dc9@haskell.org> #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants -------------------------------------+------------------------------------- Reporter: slyfox | Owner: slyfox Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jakzale): * cc: jakzale (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 22:19:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 22:19:49 -0000 Subject: [GHC] #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants In-Reply-To: <045.444a98a1463923691d1d96d4356e1130@haskell.org> References: <045.444a98a1463923691d1d96d4356e1130@haskell.org> Message-ID: <060.c9698bb9157f73d6fbca6421c4dd0e55@haskell.org> #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants -------------------------------------+------------------------------------- Reporter: slyfox | Owner: slyfox Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by int-e: Old description: > jakzale reports: > 21:47:27 < int-e> Oh, nice. Yes, indeed pprHexVal (2^32) W32 (function > from cmm/PprC.hs) would result in 0xU. > 21:50:29 < jakzale> int-e: yes, truncInt takes module 2^32, then go > returns empty string (I guess) > > Here comes the test: > {{{ > $ cat a.cmm > > foo() { > bits64 a; > a = 0x10000000000000000; // overflows 64 bits > return (a); > } > > $ inplace/bin/ghc-stage2 -c a.cmm > /tmp/ghc8580_0/ghc_2.hc: In function 'foo': > > /tmp/ghc8580_0/ghc_2.hc:8:7: error: > error: invalid suffix "xUL" on integer constant > _c0 = 0xUL; > ^ > }}} > I've broke it with commit:43f1b2ecd1960fa7377cf55a2b97c66059a701ef > when introduced truncation that can generate more zeroes. New description: jakzale reports: 21:47:27 < int-e> Oh, nice. Yes, indeed pprHexVal (2^32^) W32 (function from cmm/PprC.hs) would result in 0xU. 21:50:29 < jakzale> int-e: yes, truncInt takes module 2^32^, then go returns empty string (I guess) Here comes the test: {{{ $ cat a.cmm foo() { bits64 a; a = 0x10000000000000000; // overflows 64 bits return (a); } $ inplace/bin/ghc-stage2 -c a.cmm /tmp/ghc8580_0/ghc_2.hc: In function 'foo': /tmp/ghc8580_0/ghc_2.hc:8:7: error: error: invalid suffix "xUL" on integer constant _c0 = 0xUL; ^ }}} I've broke it with commit:43f1b2ecd1960fa7377cf55a2b97c66059a701ef when introduced truncation that can generate more zeroes. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 22:21:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 22:21:43 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.06d0f59c9757b71b9fe74b5e6775adf3@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: terrelln Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | ConstraintKinds, newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by terrelln): * owner: => terrelln Comment: I'll increase the limit to 62 to match the tuple limit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 13 23:02:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 23:02:55 -0000 Subject: [GHC] #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants In-Reply-To: <045.444a98a1463923691d1d96d4356e1130@haskell.org> References: <045.444a98a1463923691d1d96d4356e1130@haskell.org> Message-ID: <060.f350ebefd31a2b694e98f85b01d01755@haskell.org> #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants -------------------------------------+------------------------------------- Reporter: slyfox | Owner: slyfox Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D987 -------------------------------------+------------------------------------- Changes (by slyfox): * differential: => Phab:D987 -- Ticket URL: GHC The Glasgow Haskell Compiler From simonpj at microsoft.com Sat Jun 13 23:07:30 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 13 Jun 2015 23:07:30 +0000 Subject: overlapping instances in 7.10.1 In-Reply-To: <1432415282.2467.15.camel@one.mechvel.pereslavl.ru> References: <1432415282.2467.15.camel@one.mechvel.pereslavl.ru> Message-ID: <3b6fd5fd8dbc4414af8d8e1f3aaae67c@DB4PR30MB030.064d.mgd.msft.net> Sergei I finally found time to look into what is happening here. It's a good illustration of the dangers of overlapping instances. Here is the setup: * Module ResEuc_ * Contains instance (...) => Ring (ResidueE a) <---- (A) instance (..., Ring (ResidueE a)) => Field (ResidueE a) <---- (B) * Module PFact__ * Imports Pgcd_, which imports ResEuc_ * Contains code that needs (Field (ResidueE (UPol (ResidueE Integer)))) <------ (X) * To solve (X) we use instance (B) from ResEuc_ * And hence we need to solve (Ring (ResidueE (UPol (ResidueE Integer)))) which we do using (A) but not (C) * Module RsePol_ * Imports PFact__ * Contains the specialised instance instance (...) => Ring (ResidueE (UPol a)) <------ (C) which overlaps instance (A) * Module Main * Needs an instance for Field (ResidueE (UPol (Residue Integer))) <------ (Y) * Although GHC *could* generate this by instance declarations, which it would do using (B) and then using (C), instead GHC cleverly sees that it has generated it before, in module PFact__, and so uses the one from PFact__. And that is what gives rise to your error So the real problem is that in PFact__, we make an instance (X) that does not see the specialised instance (C). It *cannot* see that instance because RsePol_ imports PFact__. So whatever code uses (X) is not going to see the specialised instance. I bet that this is not what you intend. This may be a latent bug in DoCon. I solved the problem by combining PFact__ and RsePol_ into a single module. Then everything works fine. What are the general lessons here? * GHC generally assumes that if it generates (C T) in one place, then it can use that anywhere in the program that (C T) is needed. That is, there is only one (C T) dictionary. * But suppose you have overlapping instance in different modules; say module A where instance C [a] module B where import A; instance C [Maybe a] If you use (C [Maybe Int]) in A, then of course we won't see the instance in B. So you'll get a different dictionary than if you compute C [Maybe Int] in module B. In short, overlapping instances are OK, but it's best to put them in the same module as the instances they overlap. Could GHC behave as if all instances were calculated afresh in the module being compiled. Yes, of course it could, but at the cost of losing the benefit of cross-module specialisation. An overloaded function specialised at, say, [Int] in one module could not be re-used in another in case the instances changed. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of | Sergei Meshveliani | Sent: 23 May 2015 22:08 | To: glasgow-haskell-users at haskell.org | Cc: glasgow-haskell-bugs at haskell.org | Subject: overlapping instances in 7.10.1 | | Dear GHC developers, | | This request overrides my previous one of "7.10.1-err..." | (it is simpler and more precise). | The archive | | http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport- | may23-2015.zip | | presents a question about ghc-7.10.1. | | Make it, please, with ghc-7.10.1 by | | ghc $doconCpOpt -O --make Main | , | $doconCpOpt = | -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports | -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns | -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances | -XTypeSynonymInstances -XFlexibleInstances -fcontext-stack=30 | | | as it is written there in README.txt. | | README.txt explains which two instances are wrongly resolved | -- as I expect. | | In ghc-7.8.2 they are resolved in a correct way | (and there is a different pragma syntax). | I conclude this from running the test in docon-2.12. | | Am I missing something? | | Please, advise, | | ------ | Sergei | | | | | _______________________________________________ | 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 Sat Jun 13 23:11:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Jun 2015 23:11:00 -0000 Subject: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas In-Reply-To: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> References: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> Message-ID: <059.b96c00b08ee306c9349669c87c491fe2@haskell.org> #4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: terrelln Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by terrelln): * owner: => terrelln Comment: I'll checkout out toArgs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 07:45:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 07:45:30 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.ff43beb7e0d51d920e6fdebc9ad92053@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: terrelln Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | ConstraintKinds, newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D986 -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D986 * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 08:15:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 08:15:48 -0000 Subject: [GHC] #9511: Remove deprecated -fglasgow-exts from NoFib suite In-Reply-To: <045.3f3d2a7f378761f15760d3cbe0670cbf@haskell.org> References: <045.3f3d2a7f378761f15760d3cbe0670cbf@haskell.org> Message-ID: <060.6b9bd3be3b8c1ddd5a3620378eaad109@haskell.org> #9511: Remove deprecated -fglasgow-exts from NoFib suite -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: low | Milestone: Component: NoFib benchmark | Version: 7.8.3 suite | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: nomeata (added) Comment: David: what's the problem you're trying to solve here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 10:48:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 10:48:10 -0000 Subject: [GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files In-Reply-To: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> References: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> Message-ID: <058.b104d0e88df27dab014d73a8b267a8e8@haskell.org> #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files -------------------------------------+------------------------------------- Reporter: janm | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: ghc-pkg Operating System: Unknown/Multiple | race Type of failure: Other | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10205 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * os: FreeBSD => Unknown/Multiple * related: => #10205 Comment: janm: are you installing the packages with cabal or manually? The GHC build system (in ghc.mk) contains the following comment: {{{ # register the boot packages in strict sequence, because running # multiple ghc-pkgs in parallel doesn't work (registrations may get # lost). }}} Presumably `cabal -j` also registers the packages sequentially, or there'd be many more reported issues. Changing just `withFileAtomic` as you propose in comment:2 and comment:5 wouldn't solve the problem. Two concurrent ghc-pkg processes still wouldn't know about each other's modifications to the package database, so the last one to call `withFileAtomic` would still win. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 11:02:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 11:02:25 -0000 Subject: [GHC] #10519: Can't put wildcard behind forall Message-ID: <046.25f8a351d42fe346e193d0c867e5e854@haskell.org> #10519: Can't put wildcard behind forall -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This type signature doesn't compile: {{{ forall v. _ => Acc (Array DIM2 (v Double)) -> Acc (Array DIM2 (v Double)) -> Acc (A.Vector Double) -> Acc (Array DIM2 Double) }}} with "Invalid partial type signature ... An extra-constraints wildcard is only allowed at the top-level of the signature" I need the forall because I use `v` in the body of the function. This occurs with version 7.10.1.20150612 but not 7.10.1.20150519 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 14:59:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 14:59:18 -0000 Subject: [GHC] #9769: User's Guide missing from Windows binary distributions In-Reply-To: <051.92b9ec823fa5402a4972db991a6f829e@haskell.org> References: <051.92b9ec823fa5402a4972db991a6f829e@haskell.org> Message-ID: <066.384b35296ab7fc8ee830b5bf8ee28a9d@haskell.org> #9769: User's Guide missing from Windows binary distributions -------------------------------------+------------------------------------- Reporter: Dangthrimble | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Should be fixed in RC1 and beyond, thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 15:42:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 15:42:55 -0000 Subject: [GHC] #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants In-Reply-To: <045.444a98a1463923691d1d96d4356e1130@haskell.org> References: <045.444a98a1463923691d1d96d4356e1130@haskell.org> Message-ID: <060.b53ff00bf1b3d691b48b2e29f661cc3c@haskell.org> #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants -------------------------------------+------------------------------------- Reporter: slyfox | Owner: slyfox Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D987 -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"a5084557b0b30faf3f89386ee6ee5a308dae51b1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a5084557b0b30faf3f89386ee6ee5a308dae51b1" UNREG: fix pprHexVal to emit zeros (#10518) jakzale on #ghc reported a build failure when ported GHC on a new target. The code 'pprHexVal (2^32) W32' emits '0xU' which is invalid C. I've introduced bug in 43f1b2ecd1960fa7377cf55a2b97c66059a701ef when added literal truncation. That truncation is a new source of zeros. Signed-off-by: Sergei Trofimovich Test Plan: added test and tested on UNREG ghc Reviewers: austin Reviewed By: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D987 GHC Trac Issues: #10518 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 15:45:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 15:45:06 -0000 Subject: [GHC] #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants In-Reply-To: <045.444a98a1463923691d1d96d4356e1130@haskell.org> References: <045.444a98a1463923691d1d96d4356e1130@haskell.org> Message-ID: <060.c7175da95915fdc11bd4bd08b39d13e2@haskell.org> #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants -------------------------------------+------------------------------------- Reporter: slyfox | Owner: slyfox Type: bug | Status: new Priority: normal | Milestone: 7.10.2 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: | codeGen/should_compile/T10518 Related Tickets: | Blocking: | Differential Revisions: Phab:D987 -------------------------------------+------------------------------------- Changes (by slyfox): * testcase: => codeGen/should_compile/T10518 * failure: None/Unknown => Compile-time crash * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 15:46:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 15:46:10 -0000 Subject: [GHC] #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants In-Reply-To: <045.444a98a1463923691d1d96d4356e1130@haskell.org> References: <045.444a98a1463923691d1d96d4356e1130@haskell.org> Message-ID: <060.9923c5192e3f7c3f9b654e5b443fc5db@haskell.org> #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants -------------------------------------+------------------------------------- Reporter: slyfox | Owner: slyfox Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 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: | codeGen/should_compile/T10518 Related Tickets: | Blocking: | Differential Revisions: Phab:D987 -------------------------------------+------------------------------------- Changes (by slyfox): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 15:49:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 15:49:07 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2310520=3A_RecordWildCards_causes_=E2=80=9C?= =?utf-8?q?is_not_a_=28visible=29_field_of_constructor=E2=80=9D_i?= =?utf-8?q?n_ghci?= Message-ID: <043.c857f67e883ef833a204da9e13d91bc2@haskell.org> #10520: RecordWildCards causes ?is not a (visible) field of constructor? in ghci -------------------------------------+------------------------------------- Reporter: ion1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux RecordWildCards | Type of failure: GHC rejects Architecture: x86_64 | valid program (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ % ghc -ignore-dot-ghci -e 'data Foo = Bar { baz :: Integer } deriving Show' -e 'Bar 42' -e '(Bar 42){ baz = 43 }' -e 'Bar { baz = 42 }' Bar {baz = 42} Bar {baz = 43} Bar {baz = 42} }}} {{{ % ghc -ignore-dot-ghci -XRecordWildCards -e 'data Foo = Bar { baz :: Integer } deriving Show' -e 'Bar 42' -e '(Bar 42){ baz = 43 }' -e 'Bar { baz = 42 }' Bar {baz = 42} Bar {baz = 43} :1:7: ?baz? is not a (visible) field of constructor ?Bar? }}} {{{ % ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 18:13:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 18:13:48 -0000 Subject: [GHC] #10517: Unexpected behavior of unsafeCoerce converting Word32 to Word8 In-Reply-To: <044.6c8c1993f3cf45fa7c852faf5a8b459f@haskell.org> References: <044.6c8c1993f3cf45fa7c852faf5a8b459f@haskell.org> Message-ID: <059.4620dfc74e403aa3a4c884b6cab5f713@haskell.org> #10517: Unexpected behavior of unsafeCoerce converting Word32 to Word8 -------------------------------------+------------------------------------- Reporter: svenk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => invalid Comment: GHC gives no guarantees for this case: http://hackage.haskell.org/package /ghc-prim-0.3.1.0/docs/GHC-Prim.html#v:unsafeCoerce-35- since Word32 and Word8 are boxed types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 18:15:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 18:15:02 -0000 Subject: [GHC] #9991: runghc shows the value produced by main when its type is a non-() Show instance In-Reply-To: <046.b9f38b4c270b0f9b3352ad5f26fb4a6f@haskell.org> References: <046.b9f38b4c270b0f9b3352ad5f26fb4a6f@haskell.org> Message-ID: <061.49916cdad1a0ca8562f3245e2e289ef2@haskell.org> #9991: runghc shows the value produced by main when its type is a non-() Show instance -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9086 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Aha, I missed that test because I grepped for runghc and this test is using GHCi interactive to run main. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 19:55:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 19:55:08 -0000 Subject: [GHC] #10521: Wrong results in strict Word8 storage on x64 Message-ID: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> #10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: | Owner: VincentBerthoux2 | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: x86_64 | at runtime (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following snippet produce two different results in function of the compiler platform used: {{{#!hs import Data.Word( Word8 ) -- removing the bang patterns on V definition makes -- the problem go away. data V = V !Word8 !Word8 deriving Show toV :: Float -> V toV d = V (truncate $ d * coeff) (fromIntegral $ exponent d + 128) where coeff = significand d * 255.9999 / d main :: IO () main = print $ map toV [ 3.56158e-2, 0.7415215, 0.5383201, 0.1289829, 0.45520145 ] }}} On GHC 7.10.1 x86 (under windows and Linux) the output is: {{{ [V 145 124,V 189 128,V 137 128,V 132 126,V 233 127] }}} On GHC 7.10.1 x64 (under windows and Linux), the (invalid) output is: {{{ [V 0 124,V 0 128,V 0 128,V 0 126,V 0 127] }}} The bug appear at the following optimisation levels: - {{{-O1}}} - {{{-O2}}} - {{{-O3}}} the results are the same at {{{-O0}}} This bug was discovered in a bug report in the library JuicyPixels [https://github.com/Twinside/Juicy.Pixels/issues/98]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 20:01:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 20:01:27 -0000 Subject: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules In-Reply-To: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> References: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> Message-ID: <066.a578cbc32817a6a101a0df26b21ce8a3@haskell.org> #10487: DeriveGeneric breaks when the same data name is used in different modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dreixel): I'm afraid this is due to the simplistic way in which the names for the helper datatypes of the representation are generated. Should be easy to fix, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 20:05:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 20:05:26 -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.7b6f6857ff9574f4c8a30b364b653a15@haskell.org> #10512: Generic instances missing for Int32, Word64 etc. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dreixel): I'm actually not too sure that this is the right thing to do. In fact, I've wondered if we shouldn't *remove* all the instances for base types altogether. They don't really add much, do they? Generic functions typically require ad-hoc instances for base types, so it doesn't help to have these instances. Perhaps the only reason is the meta-data... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 21:32:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 21:32:52 -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.0841af77fd98b45ce388f1b66342baa3@haskell.org> #10512: Generic instances missing for Int32, Word64 etc. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): > In fact, I've wondered if we shouldn't *remove* all the instances for base types altogether. Actually from talking to Eric Mertens on the topic I now agree. The goal with generics is usually to get down to "leaves" that you know how to handle. This actively gets in the way of handling certain kinds of leaves. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 21:59:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 21:59:51 -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.e25c0e67f2cc2d14c4808672d13d0173@haskell.org> #10512: Generic instances missing for Int32, Word64 etc. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by andreas.abel): All I know is that when I tried to generate the Binary instances for my data types, I got the complaint about missing Generic instances for Int32 and Word64. I might have asked for too superclasses somewhere. At least Binary does not need Generic Int32 or Generic Word64. It is too late today to try to reconstruct my problem... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 14 23:40:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Jun 2015 23:40:11 -0000 Subject: [GHC] #10522: Add UInfixT, like UInfixE or UInfixP but for types Message-ID: <045.117758279834e73fff10891f1400af9d@haskell.org> #10522: Add UInfixT, like UInfixE or UInfixP but for types -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- TemplateHaskell provides [https://hackage.haskell.org/package/template- haskell-2.10.0.0/docs/Language-Haskell-TH-Syntax.html#infix UInfixE and UInfixP] for punting fixity handling of infix operators in expressions and patterns. There doesn't seem to be an equivalent for type operators in TH's [https://hackage.haskell.org/package/template-haskell-2.10.0.0/docs /Language-Haskell-TH-Syntax.html#t:Type type representation], but it would be nice to have one. (In fact, it doesn't appear possible to implement this manually, either, as the TemplateHaskell doesn't expose fixity information at all for type operators, at least as far as I can tell.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 01:33:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 01:33:04 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.e1390e10346aa072edca8d1212273272@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: terrelln Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | ConstraintKinds, newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D986 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"dd3080fe0263082f65bf2570f49189c277b12e28/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dd3080fe0263082f65bf2570f49189c277b12e28" Increase constraint tuple limit to 62 (Trac #10451) * Increase max constraint tuple size to 62 * Modify test case to reflect change Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D986 GHC Trac Issues: #10451 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 04:08:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 04:08:04 -0000 Subject: [GHC] #10523: Add Monoid instance for IO Message-ID: <049.6279cecb8fcd2b294d6df5d83cd891b5@haskell.org> #10523: Add Monoid instance for IO -------------------------------------+------------------------------------- Reporter: Gabriel439 | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is to add the following `Monoid` instance for `IO`: {{{#!hs instance Monoid a => Monoid (IO a) where mempty = pure mempty mappend = liftA2 mappend }}} I originally proposed this instance on the libraries mailing list a while ago: https://mail.haskell.org/pipermail/libraries/2014-November/024310.html ... and the proposal was well-received so I would like to contribute the instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 04:09:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 04:09:12 -0000 Subject: [GHC] #10523: Add Monoid instance for IO In-Reply-To: <049.6279cecb8fcd2b294d6df5d83cd891b5@haskell.org> References: <049.6279cecb8fcd2b294d6df5d83cd891b5@haskell.org> Message-ID: <064.67c022999dcb99d1d1c880ec4b287f1e@haskell.org> #10523: Add Monoid instance for IO -------------------------------------+------------------------------------- Reporter: Gabriel439 | Owner: Gabriel439 Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Gabriel439): * owner: => Gabriel439 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 05:01:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 05:01:00 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor Message-ID: <050.7408f13045aa603e186c148218ece722@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Using {{{PolyKinds}}} and {{{DeriveFunctor}}} in tandem on GHC 7.10.2-rc1 will cause a kind incompatibility in certain cases: {{{ GHCi, version 7.10.1.20150612: http://www.haskell.org/ghc/ :? for help ?> :set -XPolyKinds -XDeriveFunctor -ddump-deriv ?> newtype Compose f g a = Compose (f (g a)) deriving Functor ==================== Derived instances ==================== Derived instances: instance forall (k_axa :: BOX) (f_axb :: k_axa -> *) (g_axc :: * -> k_axa). (GHC.Base.Functor f_axb, GHC.Base.Functor g_axc) => GHC.Base.Functor (Ghci1.Compose f_axb g_axc) where GHC.Base.fmap f_axd (Ghci1.Compose a1_axe) = Ghci1.Compose (GHC.Base.fmap (GHC.Base.fmap f_axd) a1_axe) Generic representation: Generated datatypes for meta-information: Representation types: :3:52: Kind incompatibility when matching types: f0 :: * -> * f :: k -> * Expected type: f (g b) Actual type: f0 (f1 b) Relevant bindings include a1 :: f (g a) (bound at :3:52) fmap :: (a -> b) -> Compose f g a -> Compose f g b (bound at :3:52) In the first argument of ?Compose?, namely ?fmap (fmap f) a1? In the expression: Compose (fmap (fmap f) a1) When typechecking the code for ?fmap? in a derived instance for ?Functor (Compose f g)?: To see the code I am typechecking, use -ddump-deriv }}} A workaround is to use {{{StandaloneDeriving}}}: {{{ ?> :set -XStandaloneDeriving ?> newtype Compose f g a = Compose (f (g a)) ?> deriving instance (Functor f, Functor g) => Functor (Compose f g) ==================== Derived instances ==================== Derived instances: instance (GHC.Base.Functor f_ayO, GHC.Base.Functor g_ayP) => GHC.Base.Functor (Ghci1.Compose f_ayO g_ayP) where GHC.Base.fmap f_ayQ (Ghci1.Compose a1_ayR) = Ghci1.Compose (GHC.Base.fmap (GHC.Base.fmap f_ayQ) a1_ayR) Generic representation: Generated datatypes for meta-information: Representation types: }}} This problem does not seem to occur in GHC HEAD, however: {{{ GHCi, version 7.11.20150608: http://www.haskell.org/ghc/ :? for help ?> :set -XPolyKinds -XDeriveFunctor -ddump-deriv ?> newtype Compose f g a = Compose (f (g a)) deriving Functor ==================== Derived instances ==================== Derived instances: instance forall (k_a148 :: BOX) (f_a149 :: k_a148 -> *) (g_a14a :: * -> k_a148). (GHC.Base.Functor f_a149, GHC.Base.Functor g_a14a) => GHC.Base.Functor (Ghci3.Compose f_a149 g_a14a) where GHC.Base.fmap f_a14b (Ghci3.Compose a1_a14c) = Ghci3.Compose (GHC.Base.fmap (GHC.Base.fmap f_a14b) a1_a14c) Generic representation: Generated datatypes for meta-information: Representation types: }}} Can this fix be backported in time for GHC 7.10.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 07:07:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 07:07:48 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.64eb87bcb0b0e15b4f05f1a30976a570@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 07:27:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 07:27:49 -0000 Subject: [GHC] #10523: Add Monoid instance for IO In-Reply-To: <049.6279cecb8fcd2b294d6df5d83cd891b5@haskell.org> References: <049.6279cecb8fcd2b294d6df5d83cd891b5@haskell.org> Message-ID: <064.f29c8ea1e4c2b78474f064051b087955@haskell.org> #10523: Add Monoid instance for IO -------------------------------------+------------------------------------- Reporter: Gabriel439 | Owner: Gabriel439 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr, ekmett (added) * component: Compiler => libraries/base * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 07:31:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 07:31:06 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.32f258272d4529e65180a73d5656c67c@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Changes (by nomeata): * milestone: => 7.10.2 Comment: What?s the status of this? Can we get it into 7.10.2? The Debian package already carries these patches, they seem to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 07:33:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 07:33:15 -0000 Subject: [GHC] #10525: Enable SMP and GHCI on aarch64 in 7.10.2 Message-ID: <046.92ae317be081596c380955110de1888e@haskell.org> #10525: Enable SMP and GHCI on aarch64 in 7.10.2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Given that the patches from #9673 were merged as well, it would be nice to have https://phabricator.haskell.org/D859 i.e. changeset:1e8c9b81a819da8eb54405a029fc33a9f5220321/ghc included in 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 07:33:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 07:33:34 -0000 Subject: [GHC] #10525: Enable SMP and GHCI on aarch64 in 7.10.2 In-Reply-To: <046.92ae317be081596c380955110de1888e@haskell.org> References: <046.92ae317be081596c380955110de1888e@haskell.org> Message-ID: <061.c019cad1bc2a591fa00ce66c4a326b5e@haskell.org> #10525: Enable SMP and GHCI on aarch64 in 7.10.2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 08:14:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 08:14:42 -0000 Subject: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.5a511a777213f02e1063a25f20865d02@haskell.org> #10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | MonadFail Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #8004, #4384 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I have attempted a precise specification, in [wiki:Design/MethodDeprecations]. See if you agree with it. What about this? (Using the main example in [wiki:Design/MethodDeprecations] {{{ module M where import X import M1 ( C(..) ) x = bar () }}} Do we get a warning here? You might say that since `X` doesn't export `bar` (which is not obvious) that the only way it can be in scope is via `C(..)`. I say yes, and I have articulated that in the wiki page. There is a design alternative described there too; I'm not sure what you want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 08:18:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 08:18:09 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310515=3A_ghc=3A_panic=3A_tyThingTyC?= =?utf-8?b?b24gSWRlbnRpZmllciDigJgkZlN0ZW5jaWw6LmEoLCwsLCk34oCZ?= In-Reply-To: <046.1a69329a1db1e1b89b8b31699fd5aae1@haskell.org> References: <046.1a69329a1db1e1b89b8b31699fd5aae1@haskell.org> Message-ID: <061.ae17cd5195f4c2a66bffe80e37d9cc1a@haskell.org> #10515: ghc: panic: tyThingTyCon Identifier ?$fStencil:.a(,,,,)7? -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I have not see that. GHC has a `Id` in its hand when it is expecting a `TyCon`. I'm not sure how to help, short of having a repro case. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 08:27:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 08:27:42 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.7ec859d1336c423b537fef05ca2034be@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): This tick stuff is clearly interesting and useful, but it is serving several masters, which are expressed by `CoreSyn.Tickish`: * `HpcTick`: HPC code coverage * `ProfNote`: cost-centre profiling * `Breakpoint`: breakpoint debugging * `SourceNote`: do not get in the way of optimisation, but help with debugging via DWARF. They differ in the extent to which they interfere with optimisation. You probably want either `SourceNote` or `HpcTick` here; but I'm not sure which. It depends on the semantics you expect during optimisation. I suspect you want `SourceNote`. I hope you don't need a fifth one! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 08:50:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 08:50:40 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.9ac7ed493a62cd3277598fa32edd86fb@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by simonpj): Responding to Phab here, because the design discussion is less likely to get lost here. 1. Thank you for the user manual update. Can you add a paragraph or two explaining the design choice? After all, if I did `deriving( Eq )` on an empty data type, or standalone deriving, I would expect a static error; the generated code is never useful. But on the contrary, we now propose to give a dynamic error, postponing a crash until runtime. Why is this good? Explain either in the user manual or on a wiki page that discusses. comment:6 seems relevant, but is cryptic. 2. I'm certain that standalone deriving and `deriving(...)` on a data type declaration should behave the same. Imagine trying to explain the difference in the user manual, if they differed! Can you make it so? 3. For Ix, Enum, Bounded, the [https://www.haskell.org/onlinereport/haskell2010/haskellch19.html#x27-22700019.2 2010 report] uses words like "derived instance declarations for the class Ix are only possible for enumerations (i.e. datatypes having only nullary constructors) and single-constructor datatypes". It seems odd to make them fail with a static error if Eq etc fail with a dynamic error. We can interpret the words "having only nullary constructors" as true for an empty data type; after all all the constructors it has are nullary. So let's make `isEnumeration` true for empty types too. (Make a `Note` to explain; and the user manual.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 08:58:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 08:58:24 -0000 Subject: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.150ab0cdfcb5de4bcffcc1e730250e34@haskell.org> #10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | MonadFail Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #8004, #4384, | Test Case: #4879 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * related: #8004, #4384 => #8004, #4384, #4879 Comment: Replying to [comment:10 simonpj]: > I have attempted a precise specification, in [wiki:Design/MethodDeprecations]. See if you agree with it. I think so. However, you added this code example: {{{#!hs module Use where import Def( C( bar ) ) import Def( bar ) x = bar () }}} which should definitely be complained about (if `bar` is deprecated-as- method-of-C), as this code would break as soon as `bar` moved out of `C` for real. > > What about this? (Using the main example in [wiki:Design/MethodDeprecations] > {{{ > module M where > import X > import M1 ( C(..) ) > x = bar () > }}} > Do we get a warning here? You might say that since `X` doesn't export `bar` (which is not obvious) that the only way it can be in scope is via `C(..)`. > I say yes, and I have articulated that in the wiki page. There is a design alternative described there too; I'm not sure what you want. That's indeed a not so clear case, but I'd consider this a case where we need to warn, as the assumed use case for this new deprecation is that such methods will eventually be *moved* outside the class, but with the intent to remain exported (but not belonging to `C` anymore) from that very module that currently exports `bar` as method of `C`. PS: ...and I forgot to mention that this feature should be implemented (and data types refactored) while keeping the related #4879 feature- request in mind -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 09:02:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 09:02:46 -0000 Subject: [GHC] #10348: HEAD: `KnownNat` does not imply `Typeable` any more In-Reply-To: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> References: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> Message-ID: <063.b16b9e17ec6147b11cb731b524f99551@haskell.org> #10348: HEAD: `KnownNat` does not imply `Typeable` any more -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: diatchki Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Gabor Greif ): In [changeset:"a607011dbf522c97c9b6428ffa3203c56ab8dde6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a607011dbf522c97c9b6428ffa3203c56ab8dde6" Test Trac #10348 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 09:03:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 09:03:33 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.86d4d41437d3cf736e573e627d3fc2e2@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by simonpj): I'm afraid Austin is right. It's an area I've been working on hard recently, so short of picking up the current state of play (which would would introduce a lot of new risk to the 7.10 branch, including perhaps API changes) there isn't a lot we can do. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 09:16:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 09:16:55 -0000 Subject: [GHC] #10365: Make Semigroup as a superclass of Monoid In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.bf374f96adb29acc8c5f935e5e595131@haskell.org> #10365: Make Semigroup as a superclass of Monoid -------------------------------------+------------------------------------- Reporter: gidyn | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): This topic just came up again over at http://www.reddit.com/r/haskell/comments/39tumu/make_semigroup_a_superclass_of_monoid/ ...and the associated previous reddit discussion for the proposal referenced in the ticket description can be found at http://www.reddit.com/r/haskell/comments/30s1t2/proposal_make_semigroup_as_a_superclass_of_monoid/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 09:18:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 09:18:51 -0000 Subject: [GHC] #10526: Overlapping instances, incoherence, and optimisation Message-ID: <046.d8af7a5cde4c62b3cfe682b028f2a0df@haskell.org> #10526: Overlapping instances, incoherence, and optimisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Segei Meshveliani reports that his `docon` library has rather unexpected behaviour with GHC 7.10. See [https://mail.haskell.org/pipermail/glasgow- haskell-users/2015-May/025916.html his email]. The effect is that his test module `Main` has different runtime behaviour when compiling with and without `-O`. This sounds pretty bad. The reason is this: * He has overlapping instances for a class, say * `instance ... => C (T a)`, call it (A) * `instance C (T Int)`, call it (B) The actual situation is more complicated of course * The instances are defined in different modules. * In one module `Spec` * instance (B) is not visible * there is a function `f :: C a => a -> a` * `f` is called at type `T Int`. So GHC specialises `f`, to `f_spec :: T Int -> T Int`, and exports a RULE {{{ RULE "SPEC" f = f_spec :: T Int -> T Int }}} The idea is that any other module that calls `f` at type `T Int` can simply re-use the specialised (and presumably much faster) version of `f`. `C (T Int)` but (B) is not visible, so GHC finds a solution using (A). * In another module, `Use`, which ''can'' see (B), we call `f` at type `T Int`. In the absence of the cross-module specialisation rule, or without `-O`, GHC would solve the constraint `C (T Int)`, this time using (B). But because of the rule, with `-O`, it re-uses `f_spec`. Result: different runtime behaviour. There is a more detailed discussion on [https://mail.haskell.org/pipermail /glasgow-haskell-users/2015-June/025970.html this thread]. Files to reproduce. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 09:22:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 09:22:09 -0000 Subject: [GHC] #10526: Overlapping instances, incoherence, and optimisation In-Reply-To: <046.d8af7a5cde4c62b3cfe682b028f2a0df@haskell.org> References: <046.d8af7a5cde4c62b3cfe682b028f2a0df@haskell.org> Message-ID: <061.6e9b7d515bcc488a810b1ae8e804ce18@haskell.org> #10526: Overlapping instances, incoherence, and optimisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Segei Meshveliani reports that his `docon` library has rather unexpected > behaviour with GHC 7.10. See [https://mail.haskell.org/pipermail > /glasgow-haskell-users/2015-May/025916.html his email]. > > The effect is that his test module `Main` has different runtime behaviour > when compiling with and without `-O`. This sounds pretty bad. > > The reason is this: > * He has overlapping instances for a class, say > * `instance ... => C (T a)`, call it (A) > * `instance C (T Int)`, call it (B) > The actual situation is more complicated of course > > * The instances are defined in different modules. > > * In one module `Spec` > * instance (B) is not visible > * there is a function `f :: C a => a -> a` > * `f` is called at type `T Int`. > So GHC specialises `f`, to `f_spec :: T Int -> T Int`, and exports a > RULE > {{{ > RULE "SPEC" f = f_spec :: T Int -> T Int > }}} > The idea is that any other module that calls `f` at type `T Int` can > simply re-use the specialised (and presumably much faster) version of > `f`. > `C (T Int)` but (B) is not visible, so GHC finds a solution using (A). > > * In another module, `Use`, which ''can'' see (B), we call `f` at type > `T Int`. In the absence of the cross-module specialisation rule, or > without `-O`, GHC would solve the constraint `C (T Int)`, this time using > (B). But because of the rule, with `-O`, it re-uses `f_spec`. Result: > different runtime behaviour. > > There is a more detailed discussion on > [https://mail.haskell.org/pipermail/glasgow-haskell- > users/2015-June/025970.html this thread]. > > Files to reproduce. New description: Segei Meshveliani reports that his `docon` library has rather unexpected behaviour with GHC 7.10. See [https://mail.haskell.org/pipermail/glasgow- haskell-users/2015-May/025916.html his email]. The effect is that his test module `Main` has different runtime behaviour when compiling with and without `-O`. This sounds pretty bad. The reason is this: * He has overlapping instances for a class, say * `instance ... => C (T a)`, call it (A) * `instance C (T Int)`, call it (B) The actual situation is more complicated of course * The instances are defined in different modules. * In one module `Spec` * instance (B) is not visible * there is a function `f :: C a => a -> a` * `f` is called at type `T Int`. So GHC specialises `f`, to `f_spec :: T Int -> T Int`, and exports a RULE {{{ RULE "SPEC" f = f_spec :: T Int -> T Int }}} The idea is that any other module that calls `f` at type `T Int` can simply re-use the specialised (and presumably much faster) version of `f`. But note that since (B) is not visible, so GHC finds a solution using (A), and embodies that in `f_spec`. * In another module, `Use`, which ''can'' see (B) and `Spec`, we call `f` at type `T Int`. In the absence of the cross-module specialisation rule, or without `-O`, GHC would solve the constraint `C (T Int)`, this time using (B). But because of the rule, with `-O`, it re-uses `f_spec`. Result: different runtime behaviour. There is a more detailed discussion on [https://mail.haskell.org/pipermail /glasgow-haskell-users/2015-June/025970.html this thread]. Files to reproduce. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 09:22:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 09:22:34 -0000 Subject: [GHC] #10526: Overlapping instances, incoherence, and optimisation In-Reply-To: <046.d8af7a5cde4c62b3cfe682b028f2a0df@haskell.org> References: <046.d8af7a5cde4c62b3cfe682b028f2a0df@haskell.org> Message-ID: <061.b2cccafbb3901f46568af232bc9f0c49@haskell.org> #10526: Overlapping instances, incoherence, and optimisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Segei Meshveliani reports that his `docon` library has rather unexpected > behaviour with GHC 7.10. See [https://mail.haskell.org/pipermail > /glasgow-haskell-users/2015-May/025916.html his email]. > > The effect is that his test module `Main` has different runtime behaviour > when compiling with and without `-O`. This sounds pretty bad. > > The reason is this: > * He has overlapping instances for a class, say > * `instance ... => C (T a)`, call it (A) > * `instance C (T Int)`, call it (B) > The actual situation is more complicated of course > > * The instances are defined in different modules. > > * In one module `Spec` > * instance (B) is not visible > * there is a function `f :: C a => a -> a` > * `f` is called at type `T Int`. > So GHC specialises `f`, to `f_spec :: T Int -> T Int`, and exports a > RULE > {{{ > RULE "SPEC" f = f_spec :: T Int -> T Int > }}} > The idea is that any other module that calls `f` at type `T Int` can > simply re-use the specialised (and presumably much faster) version of > `f`. But note that since (B) is not visible, so GHC finds a solution > using (A), and embodies that in `f_spec`. > > * In another module, `Use`, which ''can'' see (B) and `Spec`, we call > `f` at type `T Int`. In the absence of the cross-module specialisation > rule, or without `-O`, GHC would solve the constraint `C (T Int)`, this > time using (B). But because of the rule, with `-O`, it re-uses `f_spec`. > Result: different runtime behaviour. > > There is a more detailed discussion on > [https://mail.haskell.org/pipermail/glasgow-haskell- > users/2015-June/025970.html this thread]. > > Files to reproduce. New description: Segei Meshveliani reports that his `docon` library has rather unexpected behaviour with GHC 7.10. See [https://mail.haskell.org/pipermail/glasgow- haskell-users/2015-May/025916.html his email]. The effect is that his test module `Main` has different runtime behaviour when compiling with and without `-O`. This sounds pretty bad. The reason is this: * He has overlapping instances for a class, say * `instance ... => C (T a)`, call it (A) * `instance C (T Int)`, call it (B) The actual situation is more complicated of course * The instances are defined in different modules. * In one module `Spec` * instance (B) is not visible * there is a function `f :: C a => a -> a` * `f` is called at type `T Int`. So GHC specialises `f`, to `f_spec :: T Int -> T Int`, and exports a RULE {{{ RULE "SPEC" f = f_spec :: T Int -> T Int }}} The idea is that any other module that calls `f` at type `T Int` can simply re-use the specialised (and presumably much faster) version of `f`. But note that since (B) is not visible, so GHC finds a solution using (A), and embodies that in `f_spec`. * In another module, `Use`, which ''can'' see (B) and `Spec`, we call `f` at type `T Int`. In the absence of the cross-module specialisation rule, or without `-O`, GHC would solve the constraint `C (T Int)`, this time using (B). But because of the rule, with `-O`, it re-uses `f_spec`. Result: different runtime behaviour. There is a more detailed discussion on [https://mail.haskell.org/pipermail /glasgow-haskell-users/2015-June/025970.html this thread]. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 09:33:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 09:33:30 -0000 Subject: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules In-Reply-To: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> References: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> Message-ID: <066.685fc7695d16966ece2249d9d255d9ea@haskell.org> #10487: DeriveGeneric breaks when the same data name is used in different modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => dreixel * priority: normal => highest * milestone: => 7.12.1 Comment: Thanks Pedro -- was that an offer? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 09:42:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 09:42:55 -0000 Subject: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.66b9fa05ba253ede42284fe2b9332f18@haskell.org> #10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | MonadFail Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #8004, #4384, | Test Case: #4879 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Ok, well, please go to the specification and modify it to your satisfaction. Remember that the existing behaviour is that import and export lists never generate deprecations. I think you want them to do so. That's ok but the specification should say so, esp as it's different to the current behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 09:52:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 09:52:56 -0000 Subject: [GHC] #10519: Can't put wildcard behind forall In-Reply-To: <046.25f8a351d42fe346e193d0c867e5e854@haskell.org> References: <046.25f8a351d42fe346e193d0c867e5e854@haskell.org> Message-ID: <061.c82365952b67141cc53714c1636379b5@haskell.org> #10519: Can't put wildcard behind forall -------------------------------------+------------------------------------- Reporter: yongqli | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomasw): * owner: => thomasw -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 09:54:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 09:54:23 -0000 Subject: [GHC] #10519: Can't put wildcard behind forall In-Reply-To: <046.25f8a351d42fe346e193d0c867e5e854@haskell.org> References: <046.25f8a351d42fe346e193d0c867e5e854@haskell.org> Message-ID: <061.450ce80aa31173997bae444b26ab5398@haskell.org> #10519: Can't put wildcard behind forall -------------------------------------+------------------------------------- Reporter: yongqli | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomasw): This must be caused by my recent refactoring (Phab:613). I'll have a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 10:25:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 10:25:36 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.3df800eaff88e5cf4068458efbb88245@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by scpmw): If I understand correctly, this is primarily about inferring type information about the original program from a (ticked) Haskell syntax dump. So it doesn't matter what later stages of GHC do with the ticks, as long as they appear in that particular dump. And it's quite tempting to do, because we are 99% there and the change would be rather trivial. Main "problem" is that there's simply no good reason in the context of the compiler to behave like this. If we change the default behaviour, it would certainly need a guarding comment that says why this special case exists. I think I'll make some kind of patch this week, not quite sure what it will look like though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 10:43:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 10:43:43 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families Message-ID: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've tried to compile my vinyl-like records with 7.10.2-rc1 and got: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150612 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired Class op rreplace To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 225484 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Attached self contained test compiles with 7.10.1, but fails with 7.10.2-rc1 when compiled with optimizations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 11:08:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 11:08:32 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.1dffc88fd5d7e9f04dba1c3e3bb2f997@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => high * milestone: => 7.10.2 Comment: Confirmed regression from 7.10.1. {{{ $ /opt/ghc/7.10.1/bin/ghc -O -fforce-recomp Bug.hs -fsimpl-tick-factor=50 [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) $ /opt/ghc/7.10.2/bin/ghc -O -fforce-recomp Bug.hs -fsimpl-tick- factor=5000 [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150609 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $fFunctorConst_$cfmap To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 11274000 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 11:22:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 11:22:29 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.0987c880e0eaf1808c2d079900216087@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The default `simpl-tick-factor` is 100, so reducing it to 50 will not help. Does increasing it help? How much? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 11:35:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 11:35:08 -0000 Subject: [GHC] #10348: HEAD: `KnownNat` does not imply `Typeable` any more In-Reply-To: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> References: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> Message-ID: <063.7ed67ecf5c394cdd6e34600d60d84e57@haskell.org> #10348: HEAD: `KnownNat` does not imply `Typeable` any more -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: diatchki Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Gabor Greif ): In [changeset:"77e5ec83617fce4cec530c744a435535bf06130b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="77e5ec83617fce4cec530c744a435535bf06130b" Demonstrate that inferring Typeable for type literals works So #10348 is only missing the variable case: Known{Nat,Symbol} lit => Typeable lit }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 11:50:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 11:50:42 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.cbfdfdeba43cb500de5fd9d34f5c7010@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by sopvop): Neither increasing simpl-tick-factor to 5000 nor decreasing it to 10 helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 12:26:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 12:26:18 -0000 Subject: [GHC] #10507: Looping with type level naturals In-Reply-To: <047.5fd95e048f3c3bca89022fe8d424335a@haskell.org> References: <047.5fd95e048f3c3bca89022fe8d424335a@haskell.org> Message-ID: <062.b1ff335bc97d4d701fc2de8cedf493bc@haskell.org> #10507: Looping with type level naturals -------------------------------------+------------------------------------- Reporter: jhendrix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"efa136f7199f9313e91ba2c1724b307aff45c9eb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="efa136f7199f9313e91ba2c1724b307aff45c9eb" Remove derived CFunEqCans after solving givens See Note [The inert set after solving Givens] in TcSMonad. This fixes Trac #10507. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 12:43:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 12:43:33 -0000 Subject: [GHC] #10521: Wrong results in strict Word8 storage on x64 In-Reply-To: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> References: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> Message-ID: <070.38db8a3f90ec929a8908129bcccf63a8@haskell.org> #10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: VincentBerthoux2 | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by VincentBerthoux2): * priority: normal => high * milestone: => 7.10.2 Old description: > The following snippet produce two different results in function of the > compiler platform used: > > {{{#!hs > import Data.Word( Word8 ) > > -- removing the bang patterns on V definition makes > -- the problem go away. > data V = V !Word8 !Word8 deriving Show > > toV :: Float -> V > toV d = V (truncate $ d * coeff) (fromIntegral $ exponent d + 128) where > coeff = significand d * 255.9999 / d > > main :: IO () > main = > print $ map toV [ 3.56158e-2, 0.7415215, 0.5383201, 0.1289829, > 0.45520145 ] > }}} > > On GHC 7.10.1 x86 (under windows and Linux) the output is: > {{{ > [V 145 124,V 189 128,V 137 128,V 132 126,V 233 127] > }}} > > On GHC 7.10.1 x64 (under windows and Linux), the (invalid) output is: > {{{ > [V 0 124,V 0 128,V 0 128,V 0 126,V 0 127] > }}} > > The bug appear at the following optimisation levels: > > - {{{-O1}}} > - {{{-O2}}} > - {{{-O3}}} > > the results are the same at {{{-O0}}} > > This bug was discovered in a bug report in the library JuicyPixels > [https://github.com/Twinside/Juicy.Pixels/issues/98]. New description: The following snippet produce two different results in function of the compiler platform used: {{{#!hs import Data.Word( Word8 ) -- removing the bang patterns on V definition makes -- the problem go away. data V = V !Word8 !Word8 deriving Show toV :: Float -> V toV d = V (truncate $ d * coeff) (fromIntegral $ exponent d + 128) where coeff = significand d * 255.9999 / d main :: IO () main = print $ map toV [ 3.56158e-2, 0.7415215, 0.5383201, 0.1289829, 0.45520145 ] }}} On GHC 7.10.1 x86 (under windows and Linux) the output is: {{{ [V 145 124,V 189 128,V 137 128,V 132 126,V 233 127] }}} On GHC 7.10.1 x64 (under windows and Linux), the (invalid) output is: {{{ [V 0 124,V 0 128,V 0 128,V 0 126,V 0 127] }}} The bug appear at the following optimisation levels: - {{{-O1}}} - {{{-O2}}} - {{{-O3}}} the results are the same at {{{-O0}}} This bug was discovered in a bug report in the library JuicyPixels [https://github.com/Twinside/Juicy.Pixels/issues/98]. The same problem has been seen with GHC 7.10.2 RC1 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 13:23:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 13:23:25 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310520=3A_RecordWildCards_causes_?= =?utf-8?q?=E2=80=9Cis_not_a_=28visible=29_field_of_constructor?= =?utf-8?b?4oCdIGluIGdoY2k=?= In-Reply-To: <043.c857f67e883ef833a204da9e13d91bc2@haskell.org> References: <043.c857f67e883ef833a204da9e13d91bc2@haskell.org> Message-ID: <058.bc6c21e9c117c32aa3417dce389733c4@haskell.org> #10520: RecordWildCards causes ?is not a (visible) field of constructor? in ghci -------------------------------------+------------------------------------- Reporter: ion1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | RecordWildCards Type of failure: GHC rejects | Architecture: x86_64 valid program | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a3f6239d905ad4b8fb597f43bd4ef9947c83362f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a3f6239d905ad4b8fb597f43bd4ef9947c83362f" GHCi: fix scoping for record selectors This fixes Trac #10520. See the "Ugh" note about record selectors in HscTypes.icExtendGblRdrEnv. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 13:37:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 13:37:35 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.9b830830a3b1c2c8bfe2e4347c8dd693@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: normal => highest Comment: Okay, I'm bumping this to high priority, and me and Ben can investigate and talk with Simon about this tomorrow in our meeting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 14:14:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 14:14:29 -0000 Subject: [GHC] #10529: hpc: Improve error messages in readMix Message-ID: <042.190bab483c0a9360715a797a8a3385e1@haskell.org> #10529: hpc: Improve error messages in readMix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Code | Version: 7.10.1 Coverage | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See https://hackage.haskell.org/package/hpc-0.6.0.2/docs/src/Trace-Hpc- Mix.html#readMix The generic `error $ "can not find " ++ modName ++ " in " ++ show dirNames` error message is used for all kinds of cases, for example when `h == tixModuleHash tix` isn't true. It would be very helpful if the error message could be specific for these cases (e.g. "hashes don't agree") instead of being a catch-all for all `Nothing`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 14:18:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 14:18:46 -0000 Subject: [GHC] #10530: Update transformers library Message-ID: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> #10530: Update transformers library -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.10.2 Priority: normal | Version: 7.10.2-rc1 Component: libraries | Operating System: Unknown/Multiple (other) | Type of failure: Other Keywords: | Blocked By: transformers | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As noted in a reply to the RC1 announcement, we should update `transformers` to the latest version (which merely adds some new instances for `Const`). We should also do a once over for the other libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 14:18:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 14:18:55 -0000 Subject: [GHC] #10530: Update transformers library In-Reply-To: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> References: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> Message-ID: <067.e4e5f7c02df05e92b9a7be49c0de2d5d@haskell.org> #10530: Update transformers library -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: libraries | Milestone: 7.10.2 (other) | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | transformers Type of failure: Other | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 14:22:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 14:22:29 -0000 Subject: [GHC] #10525: Enable SMP and GHCI on aarch64 in 7.10.2 In-Reply-To: <046.92ae317be081596c380955110de1888e@haskell.org> References: <046.92ae317be081596c380955110de1888e@haskell.org> Message-ID: <061.66bcb8a2057d1b097bc85a3eab2e7cbc@haskell.org> #10525: Enable SMP and GHCI on aarch64 in 7.10.2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 14:22:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 14:22:45 -0000 Subject: [GHC] #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants In-Reply-To: <045.444a98a1463923691d1d96d4356e1130@haskell.org> References: <045.444a98a1463923691d1d96d4356e1130@haskell.org> Message-ID: <060.acc88ba62cbb3747501af4a025e57032@haskell.org> #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants -------------------------------------+------------------------------------- Reporter: slyfox | Owner: slyfox Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | codeGen/should_compile/T10518 Related Tickets: | Blocking: | Differential Revisions: Phab:D987 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 14:29:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 14:29:15 -0000 Subject: [GHC] #10530: Update transformers library In-Reply-To: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> References: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> Message-ID: <067.43e0360d5b6faa2b46ac4a0c352d114b@haskell.org> #10530: Update transformers library -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: libraries | Milestone: 7.10.2 (other) | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | transformers Type of failure: Other | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 14:29:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 14:29:48 -0000 Subject: [GHC] Batch modify: #10375, #10438, #10053, #10205, #10301, #10506 Message-ID: <20150615142948.91DFD3A2FF@ghc.haskell.org> Batch modification to #10375, #10438, #10053, #10205, #10301, #10506 by thoughtpolice: milestone to 7.10.3 Comment: Moving to 7.10.3 milestone - if you think this is an error (or a showstopping bug), please remilestone it to 7.10.2 and let us know why. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 14:34:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 14:34:10 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.7ff49fb4d35c1b148354424f87f06f4b@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Changes (by thoughtpolice): * cc: slyfox, trommler (added) * status: new => patch Comment: (I deleted the `.swp` file). I think this patch looks fine but to be safe I would prefer it if we could get a code review from Sergei and/or Peter. @cjwatson, thanks for the great patch as usual, and if you don't mind, in the future please at least set these tickets to `patch` status so we don't lose them! (preferably if they could go through Phabricator, we'll also be more attentive and review them in short order). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 16:11:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 16:11:46 -0000 Subject: [GHC] #10521: Wrong results in strict Word8 storage on x64 In-Reply-To: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> References: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> Message-ID: <070.f3e8a7487cab942da283fec672487299@haskell.org> #10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: VincentBerthoux2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by VincentBerthoux2): * priority: high => normal * milestone: 7.10.2 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 16:44:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 16:44:24 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310520=3A_RecordWildCards_causes_?= =?utf-8?q?=E2=80=9Cis_not_a_=28visible=29_field_of_constructor?= =?utf-8?b?4oCdIGluIGdoY2k=?= In-Reply-To: <043.c857f67e883ef833a204da9e13d91bc2@haskell.org> References: <043.c857f67e883ef833a204da9e13d91bc2@haskell.org> Message-ID: <058.7effa7f170ece3a956005fc5a1b6f305@haskell.org> #10520: RecordWildCards causes ?is not a (visible) field of constructor? in ghci -------------------------------------+------------------------------------- Reporter: ion1 | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | RecordWildCards Type of failure: GHC rejects | Architecture: x86_64 valid program | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * milestone: => 7.10.3 Comment: Thanks for the report. Hopefully can merge into 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 17:32:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 17:32:58 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.1c9c82deb7e9da358b7ce84815b10dc5@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: thomie Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D990 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D990 * milestone: 7.10.3 => 7.10.2 Comment: I think we can fix this still for 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 17:37:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 17:37:19 -0000 Subject: [GHC] #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' Message-ID: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: attached | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When compiling a set of 3 modules (in a certain order), linking of the final executable fails because there conflicting symbols in some of the `.o`. When doing the compilation in the same order, but with optimizations, it succeeds. The simple test case: A.hs: {{{#!hs module A where main :: IO () main = putStrLn "A" }}} B.hs: {{{#!hs module B where import A() main :: IO () main = putStrLn "B" }}} C.hs: {{{#!hs import B() main :: IO () main = putStrLn "hi" }}} When I compile it with in the order specified by the attached `./bug- reproduce.sh` and `Makefile`, the following happens: {{{ ./bug-reproduce.sh rm -fv a A.o A.hi removed 'a' removed 'A.o' removed 'A.hi' rm -fv b B.o B.hi removed 'b' removed 'B.o' removed 'B.hi' rm -fv c C.o C.hi removed 'c' removed 'C.o' removed 'C.hi' ghc -Wall A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall B.hs -main-is B.main -o b [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] [2 of 2] Compiling B ( B.hs, B.o ) Linking b ... ghc -Wall C.hs -o c [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] [3 of 3] Compiling Main ( C.hs, C.o ) Linking c ... removed 'A.o' ghc -Wall A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall B.hs -main-is B.main -o b [2 of 2] Compiling B ( B.hs, B.o ) [flags changed] Linking b ... ./A.o: In function `siv_closure': (.data+0x0): multiple definition of `__stginit_ZCMain' B.o:(.data+0x0): first defined here ./A.o: In function `ZCMain_main_srt': (.data+0x70): multiple definition of `ZCMain_main_closure' B.o:(.data+0x70): first defined here ./A.o:(.text+0xb8): multiple definition of `ZCMain_main_info' B.o:(.text+0xb8): first defined here collect2: error: ld returned 1 exit status make: *** [B.o] Error 1 }}} But it succeeds if done as `./bug-reproduce.sh GHC_OPTS=-O1` (probably, the optimizations remove the conflicting symbols): {{{ ./bug-reproduce.sh GHC_OPTS=-O1 rm -fv a A.o A.hi removed 'a' removed 'A.o' removed 'A.hi' rm -fv b B.o B.hi removed 'b' removed 'B.o' removed 'B.hi' rm -fv c C.o C.hi removed 'c' removed 'C.o' removed 'C.hi' ghc -Wall -O1 A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall -O1 B.hs -main-is B.main -o b [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] [2 of 2] Compiling B ( B.hs, B.o ) Linking b ... ghc -Wall -O1 C.hs -o c [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] [3 of 3] Compiling Main ( C.hs, C.o ) Linking c ... removed 'A.o' ghc -Wall -O1 A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall -O1 B.hs -main-is B.main -o b [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] [2 of 2] Compiling B ( B.hs, B.o ) [flags changed] Linking b ... ghc -Wall -O1 C.hs -o c [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] Linking c ... }}} Couldn't the compiler detect and handle such cases? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 17:50:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 17:50:26 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.a9004b13858010af4ae3419e70e6f104@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: thomie Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D990 -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:3 Kludgy]: > EDIT: Not sure if it helps, but certain operations (like renaming a file with a directory) cause the directory modified time to be updated, usually leading to the directory modified time exceeding the file modified time. It was exactly this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 18:08:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 18:08:30 -0000 Subject: [GHC] #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' In-Reply-To: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> References: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> Message-ID: <057.00d4285efb200638a8353624f4eec267@haskell.org> #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: attached Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): The manual suggests that recompilation checking doesn't really work with `-main-is`: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/options- phases.html (the problem being that when you build `B.hs` the second time, it needs to recompile `A.hs` with a DIFFERENT `-main-is` flag.) But it sort of looks like dterei tried to fix this in #437, so maybe this was intended to be fixed, and the manual wasn't updated? In any case, this looks like a fine bug to me. Once fixed the admonition from the manual should be removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 18:32:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 18:32:32 -0000 Subject: [GHC] #9430: implement more arithmetic operations natively in the LLVM backend In-Reply-To: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> References: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> Message-ID: <062.f331ad405831bba47068724c3195c0fb@haskell.org> #9430: implement more arithmetic operations natively in the LLVM backend -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: michalt Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | 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 Revisions: -------------------------------------+------------------------------------- Comment (by michalt): Sent out Phab:D991 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 18:45:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 18:45:18 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.e068a285f8e725bf2398e6266ae6a8e6@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): (1) and (2) are done(will push commits soon). For (3), I think it may break some things. I found this NOTE in compiler/types/TyCon.hs: {{{ Note [Enumeration types] ~~~~~~~~~~~~~~~~~~~~~~~~ We define datatypes with no constructors to *not* be enumerations; this fixes trac #2578, Otherwise we end up generating an empty table for __closure_tbl which is used by tagToEnum# to map Int# to constructors in an enumeration. The empty table apparently upset the linker. Moreover, all the data constructor must be enumerations, meaning they have type (forall abc. T a b c). GADTs are not enumerations. For example consider data T a where T1 :: T Int T2 :: T Bool T3 :: T a What would [T1 ..] be? [T1,T3] :: T Int? Easiest thing is to exclude them. See Trac #4528. }}} See also trac #2578. Relevant commits: {{{ commit 409e4d9f59dece1c21434191459c96b3e355faa9 Author: Ian Lynagh Date: Sat Feb 27 17:24:29 2010 +0000 Add a test for #2578 commit a251cba370c9bfb291159c4deea20226a87eeac3 Author: Simon Marlow Date: Mon Mar 1 09:55:25 2010 +0000 expand comments for #2578 fix commit 09d2b3b2e1f9d0a4c4b938dc6ff6a0b068138445 Author: Ian Lynagh Date: Sat Feb 27 17:39:51 2010 +0000 Fix trac #2578 We define empty datatypes as not being enumerations, which means the empty blocks aren't generated. }}} This is the fix: {{{ - = DataTyCon { data_cons = cons, is_enum = all isNullarySrcDataCon cons } + = DataTyCon { + data_cons = cons, + is_enum = -- We define datatypes with no constructors to not be + -- enumerations; this fixes trac #2578 + not (null cons) && + all isNullarySrcDataCon cons + } }}} `Note [Enumeration types]` mentions some kind of linker failure related with some table(??), but I don't have a lot of ideas about what it's talking about. I don't have a Mac so I can't try with latest linker/GHC. Any ideas about (3)? How should we proceed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 18:54:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 18:54:05 -0000 Subject: [GHC] #10522: Add UInfixT, like UInfixE or UInfixP but for types In-Reply-To: <045.117758279834e73fff10891f1400af9d@haskell.org> References: <045.117758279834e73fff10891f1400af9d@haskell.org> Message-ID: <060.79ef9db1923c001a81617eb948ba7930@haskell.org> #10522: Add UInfixT, like UInfixE or UInfixP but for types -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer Comment: Happy to support a newcomer in addressing this deficiency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 20:58:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 20:58:44 -0000 Subject: [GHC] #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' In-Reply-To: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> References: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> Message-ID: <057.1bb71e9dfdd46048384c883024360f8f@haskell.org> #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: attached Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by imz): One difference is that without `-O1` it doesn't recompile `A.hs` when compiling `B.hs`, whereas with `-O1` it does (although superficially there is no extra reason to do so in the second case, i.e., no change in flags which might cause this: `A.hs` has been compiled with `-O1` already in the second case; it could be understood if `-O1` always caused recompilation, no matter what the previous flags were): {{{ removed 'A.o' ghc -Wall A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall B.hs -main-is B.main -o b [2 of 2] Compiling B ( B.hs, B.o ) [flags changed] Linking b ... ./A.o: In function `siv_closure': (.data+0x0): multiple definition of `__stginit_ZCMain' }}} vs {{{ removed 'A.o' ghc -Wall -O1 A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall -O1 B.hs -main-is B.main -o b [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] [2 of 2] Compiling B ( B.hs, B.o ) [flags changed] Linking b ... }}} (success) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 21:00:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 21:00:28 -0000 Subject: [GHC] #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' In-Reply-To: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> References: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> Message-ID: <057.542d12ecf1d8f815cc7e7d5dd2f90563@haskell.org> #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: attached Blocked By: | Blocking: Related Tickets: 437 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by imz): * related: => 437 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 21:01:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 21:01:36 -0000 Subject: [GHC] #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' In-Reply-To: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> References: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> Message-ID: <057.a856045f879c8b4eb06ca4f99e54d549@haskell.org> #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: attached Blocked By: | Blocking: Related Tickets: 437 | Differential Revisions: -------------------------------------+------------------------------------- Description changed by imz: Old description: > When compiling a set of 3 modules (in a certain order), linking of the > final executable fails because there conflicting symbols in some of the > `.o`. > > When doing the compilation in the same order, but with optimizations, it > succeeds. > > The simple test case: > > A.hs: > > {{{#!hs > module A where > main :: IO () > main = putStrLn "A" > }}} > > B.hs: > > {{{#!hs > module B where > import A() > main :: IO () > main = putStrLn "B" > }}} > > C.hs: > > {{{#!hs > import B() > main :: IO () > main = putStrLn "hi" > }}} > > When I compile it with in the order specified by the attached `./bug- > reproduce.sh` and `Makefile`, the following happens: > > {{{ > ./bug-reproduce.sh > rm -fv a A.o A.hi > removed 'a' > removed 'A.o' > removed 'A.hi' > rm -fv b B.o B.hi > removed 'b' > removed 'B.o' > removed 'B.hi' > rm -fv c C.o C.hi > removed 'c' > removed 'C.o' > removed 'C.hi' > ghc -Wall A.hs -main-is A.main -o a > [1 of 1] Compiling A ( A.hs, A.o ) > Linking a ... > ghc -Wall B.hs -main-is B.main -o b > [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] > [2 of 2] Compiling B ( B.hs, B.o ) > Linking b ... > ghc -Wall C.hs -o c > [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] > [3 of 3] Compiling Main ( C.hs, C.o ) > Linking c ... > removed 'A.o' > ghc -Wall A.hs -main-is A.main -o a > [1 of 1] Compiling A ( A.hs, A.o ) > Linking a ... > ghc -Wall B.hs -main-is B.main -o b > [2 of 2] Compiling B ( B.hs, B.o ) [flags changed] > Linking b ... > ./A.o: In function `siv_closure': > (.data+0x0): multiple definition of `__stginit_ZCMain' > B.o:(.data+0x0): first defined here > ./A.o: In function `ZCMain_main_srt': > (.data+0x70): multiple definition of `ZCMain_main_closure' > B.o:(.data+0x70): first defined here > ./A.o:(.text+0xb8): multiple definition of `ZCMain_main_info' > B.o:(.text+0xb8): first defined here > collect2: error: ld returned 1 exit status > make: *** [B.o] Error 1 > }}} > > But it succeeds if done as `./bug-reproduce.sh GHC_OPTS=-O1` (probably, > the optimizations remove the conflicting symbols): > > {{{ > ./bug-reproduce.sh GHC_OPTS=-O1 > rm -fv a A.o A.hi > removed 'a' > removed 'A.o' > removed 'A.hi' > rm -fv b B.o B.hi > removed 'b' > removed 'B.o' > removed 'B.hi' > rm -fv c C.o C.hi > removed 'c' > removed 'C.o' > removed 'C.hi' > ghc -Wall -O1 A.hs -main-is A.main -o a > [1 of 1] Compiling A ( A.hs, A.o ) > Linking a ... > ghc -Wall -O1 B.hs -main-is B.main -o b > [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] > [2 of 2] Compiling B ( B.hs, B.o ) > Linking b ... > ghc -Wall -O1 C.hs -o c > [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] > [3 of 3] Compiling Main ( C.hs, C.o ) > Linking c ... > removed 'A.o' > ghc -Wall -O1 A.hs -main-is A.main -o a > [1 of 1] Compiling A ( A.hs, A.o ) > Linking a ... > ghc -Wall -O1 B.hs -main-is B.main -o b > [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] > [2 of 2] Compiling B ( B.hs, B.o ) [flags changed] > Linking b ... > ghc -Wall -O1 C.hs -o c > [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] > Linking c ... > }}} > > Couldn't the compiler detect and handle such cases? New description: When compiling a set of 3 modules (in a certain order), linking of the final executable fails because there are conflicting symbols in some of the `.o`. When doing the compilation in the same order, but with optimizations, it succeeds. The simple test case: A.hs: {{{#!hs module A where main :: IO () main = putStrLn "A" }}} B.hs: {{{#!hs module B where import A() main :: IO () main = putStrLn "B" }}} C.hs: {{{#!hs import B() main :: IO () main = putStrLn "hi" }}} When I compile it with in the order specified by the attached `./bug- reproduce.sh` and `Makefile`, the following happens: {{{ ./bug-reproduce.sh rm -fv a A.o A.hi removed 'a' removed 'A.o' removed 'A.hi' rm -fv b B.o B.hi removed 'b' removed 'B.o' removed 'B.hi' rm -fv c C.o C.hi removed 'c' removed 'C.o' removed 'C.hi' ghc -Wall A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall B.hs -main-is B.main -o b [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] [2 of 2] Compiling B ( B.hs, B.o ) Linking b ... ghc -Wall C.hs -o c [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] [3 of 3] Compiling Main ( C.hs, C.o ) Linking c ... removed 'A.o' ghc -Wall A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall B.hs -main-is B.main -o b [2 of 2] Compiling B ( B.hs, B.o ) [flags changed] Linking b ... ./A.o: In function `siv_closure': (.data+0x0): multiple definition of `__stginit_ZCMain' B.o:(.data+0x0): first defined here ./A.o: In function `ZCMain_main_srt': (.data+0x70): multiple definition of `ZCMain_main_closure' B.o:(.data+0x70): first defined here ./A.o:(.text+0xb8): multiple definition of `ZCMain_main_info' B.o:(.text+0xb8): first defined here collect2: error: ld returned 1 exit status make: *** [B.o] Error 1 }}} But it succeeds if done as `./bug-reproduce.sh GHC_OPTS=-O1` (probably, the optimizations remove the conflicting symbols): {{{ ./bug-reproduce.sh GHC_OPTS=-O1 rm -fv a A.o A.hi removed 'a' removed 'A.o' removed 'A.hi' rm -fv b B.o B.hi removed 'b' removed 'B.o' removed 'B.hi' rm -fv c C.o C.hi removed 'c' removed 'C.o' removed 'C.hi' ghc -Wall -O1 A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall -O1 B.hs -main-is B.main -o b [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] [2 of 2] Compiling B ( B.hs, B.o ) Linking b ... ghc -Wall -O1 C.hs -o c [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] [3 of 3] Compiling Main ( C.hs, C.o ) Linking c ... removed 'A.o' ghc -Wall -O1 A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall -O1 B.hs -main-is B.main -o b [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] [2 of 2] Compiling B ( B.hs, B.o ) [flags changed] Linking b ... ghc -Wall -O1 C.hs -o c [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] Linking c ... }}} Couldn't the compiler detect and handle such cases? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 21:05:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 21:05:57 -0000 Subject: [GHC] #9351: add ability to version symbols .c for packages with C code In-Reply-To: <045.80bb3346a6b02dbb6a22b16b99e4840e@haskell.org> References: <045.80bb3346a6b02dbb6a22b16b99e4840e@haskell.org> Message-ID: <060.0da56ce6818451ffe868ee5de97866fb@haskell.org> #9351: add ability to version symbols .c for packages with C code -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): duncan: the problem with a more magic approach is that mangling the symbols could break uses of `dlopen` in the compiled objects, since you have no idea if a string is referring to a specific symbol. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 22:22:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 22:22:15 -0000 Subject: [GHC] #10532: Unnecessary constraints when using overlapping instances Message-ID: <050.526817581fb74feaa1e19955b3232905@haskell.org> #10532: Unnecessary constraints when using overlapping instances -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following code compiles just fine: {{{ class Foo a where foo :: a -> Int instance Foo a where foo _ = 5 f :: a -> Int f = foo }}} But if we modify the code to use overlapping instances like so: {{{ class Foo a where foo :: a -> Int instance {-# OVERLAPS #-} Foo Int where foo = id instance {-# OVERLAPPABLE #-} Foo a where foo _ = 5 f:: a -> Int f = foo }}} We get the following compiler message: {{{ Overlapping instances for Foo a arising from a use of ?foo? Matching instances: instance [overlappable] Foo a -- Defined at ... instance [overlap ok] Foo Int -- Defined at ... (The choice depends on the instantiation of ?a? To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) }}} Including the constraint in the type signature makes the problem go away, but the constraint shouldn't be needed. In most use cases this wouldn't be a big deal, but it's making my type signatures much messier looking than they actually are. Adding IncoherentInstances as the error message suggests gives the instance I don't want. Weirdly, I get different instances depending on whether the constraint is in the type signature or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 22:26:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 22:26:50 -0000 Subject: [GHC] #10532: Unnecessary constraints when using overlapping instances In-Reply-To: <050.526817581fb74feaa1e19955b3232905@haskell.org> References: <050.526817581fb74feaa1e19955b3232905@haskell.org> Message-ID: <065.ebb2d4153eec8b0cfed62605f585ab10@haskell.org> #10532: Unnecessary constraints when using overlapping instances -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by MikeIzbicki: Old description: > The following code compiles just fine: > > {{{ > class Foo a where foo :: a -> Int > instance Foo a where foo _ = 5 > > f :: a -> Int > f = foo > }}} > > But if we modify the code to use overlapping instances like so: > > {{{ > class Foo a where foo :: a -> Int > instance {-# OVERLAPS #-} Foo Int where foo = id > instance {-# OVERLAPPABLE #-} Foo a where foo _ = 5 > > f:: a -> Int > f = foo > }}} > > We get the following compiler message: > {{{ > Overlapping instances for Foo a arising from a use of ?foo? > Matching instances: > instance [overlappable] Foo a > -- Defined at ... > instance [overlap ok] Foo Int > -- Defined at ... > (The choice depends on the instantiation of ?a? > To pick the first instance above, use IncoherentInstances > when compiling the other instance declarations) > }}} > > Including the constraint in the type signature makes the problem go away, > but the constraint shouldn't be needed. In most use cases this wouldn't > be a big deal, but it's making my type signatures much messier looking > than they actually are. > > Adding IncoherentInstances as the error message suggests gives the > instance I don't want. Weirdly, I get different instances depending on > whether the constraint is in the type signature or not. New description: The following code compiles just fine: {{{ class Foo a where foo :: a -> Int instance Foo a where foo _ = 5 f :: a -> Int f = foo }}} But if we modify the code to use overlapping instances like so: {{{ class Foo a where foo :: a -> Int instance {-# OVERLAPS #-} Foo Int where foo = id instance {-# OVERLAPPABLE #-} Foo a where foo _ = 5 f:: a -> Int f = foo }}} We get the following error message: {{{ Overlapping instances for Foo a arising from a use of ?foo? Matching instances: instance [overlappable] Foo a -- Defined at ... instance [overlap ok] Foo Int -- Defined at ... (The choice depends on the instantiation of ?a? To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) }}} Including the constraint in the type signature makes the problem go away, but the constraint shouldn't be needed. In most use cases this wouldn't be a big deal, but it's making my type signatures much messier looking than they actually are. Adding IncoherentInstances as the error message suggests gives the instance I don't want. Weirdly, I get different instances depending on whether the constraint is in the type signature or not. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 22:58:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 22:58:15 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.172b9623cb2ae10f5dd6f94ef9f80bf1@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by slyfox): I think the source of new relocations is GHC itself: a93ab43ab5f40cadbedea2f6342b93c245e91434 It started generating proper PIC files for all (including .c) code recently. {{{ [sf] /tmp:powerpc64-unknown-linux-gnu-gcc -c -m32 -O2 a.c && objdump -d -r a.o a.o: file format elf32-powerpc Disassembly of section .text: 00000000 : 0: 94 21 ff f0 stwu r1,-16(r1) 4: 38 21 00 10 addi r1,r1,16 8: 48 00 00 00 b 8 8: R_PPC_REL24 f [sf] /tmp:powerpc64-unknown-linux-gnu-gcc -fPIC -c -m32 -O2 a.c && objdump -d -r a.o a.o: file format elf32-powerpc Disassembly of section .text: 00000000 : 0: 94 21 ff e0 stwu r1,-32(r1) 4: 7c 08 02 a6 mflr r0 8: 42 9f 00 05 bcl 20,4*cr7+so,c c: 93 c1 00 18 stw r30,24(r1) 10: 90 01 00 24 stw r0,36(r1) 14: 7f c8 02 a6 mflr r30 18: 3f de 00 00 addis r30,r30,0 1a: R_PPC_REL16_HA .got2+0x800e 1c: 3b de 00 00 addi r30,r30,0 1e: R_PPC_REL16_LO .got2+0x8012 20: 48 00 00 01 bl 20 20: R_PPC_PLTREL24 f+0x8000 24: 80 01 00 24 lwz r0,36(r1) 28: 83 c1 00 18 lwz r30,24(r1) 2c: 38 21 00 20 addi r1,r1,32 30: 7c 08 03 a6 mtlr r0 34: 4e 80 00 20 blr }}} What bothers me is why ghci tries o load .a/.o file manually at all. It should use system linker. by creating/dlopen()ing temp .so object. Does debian disable dynamic GHC by default as DYNAMIC_GHC_PROGRAMS = NO ? From the above I suspect '''R_PPC_PLTREL24''' might require +0x8000 offset and should be PLT relative. I'll try to look at it tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 23:29:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 23:29:56 -0000 Subject: [GHC] #7428: GHC compile times are seriously non-linear in program size In-Reply-To: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> References: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> Message-ID: <060.e05fb5fa85a29649f66fc2a83c6d6aa6@haskell.org> #7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I may be missing something obvious here but I'm not convinced that the problem is in `CorePrep` or `TidyCore`. If one looks at the `hi` file or `-ddump-simpl` output from even a relatively shallow four-layer transformer stack one finds quite large types that appear to be growing quadratically in the depth. This is supported by the fact that `Type` and `IfaceType` show up strongly in the heap profiles as well as the fact that, in my runs, `core2core` shows up about as strongly in the profiles as `addFingerprints`. Looking at the types in the Core, it seems that the inliner may be over- zealous in its work. Due to the CPS style of the example, the types snowball extremely quickly. Most of the damage comes in the first two simplifier iterations. Many of the larger of these types are coercions and their signatures. I'm not sure I see what is failing here. The question then is what measure is supposed to prevent this snow-balling and why is it not working? I'll have another look tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 00:27:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 00:27:04 -0000 Subject: [GHC] #10533: Typechecker behaves differently on Phab and on Mac Message-ID: <047.47efed1788c080f7defb630451503765@haskell.org> #10533: Typechecker behaves differently on Phab and on Mac -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- On my Mac, commit 61b96a86c5342fb1c850361177d60fe855d948f6 causes test `typecheck/should_compile/FD3` to fail. But Phab succeeded in validating this commit, as seen [https://phabricator.haskell.org/B4297 here]. (I don't believe that commit has anything to do with the failure -- it's just the snapshot I looked at.) This leads to two questions: 1. Why does this test fail on a Mac? 2. Why does the typechecker behave differently, at all, on two different platforms? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 00:54:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 00:54:50 -0000 Subject: [GHC] #10532: Unnecessary constraints when using overlapping instances In-Reply-To: <050.526817581fb74feaa1e19955b3232905@haskell.org> References: <050.526817581fb74feaa1e19955b3232905@haskell.org> Message-ID: <065.f88476221927b1bbd62fe071c40da82d@haskell.org> #10532: Unnecessary constraints when using overlapping instances -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): This looks like expected behavior to me. In the overlapping instances case, GHC can't know which instance to choose when calling `foo` from `f`. If you want GHC to decide based on whether `a` is `Int` at a particular call site, then that's exactly what adding the constraint to `f`'s type signature means. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 01:20:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 01:20:16 -0000 Subject: [GHC] #10534: Data families + Coercible = unsafeCoerce Message-ID: <047.8223986df67095beb90c9b80050632fc@haskell.org> #10534: Data families + Coercible = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts #-} module A where import Data.Coerce data family DF a silly :: Coercible (DF a) (DF b) => a -> b silly = coerce }}} {{{ {-# LANGUAGE TypeFamilies #-} module B where import A newtype instance DF a = MkDF () unsafeCoerce :: a -> b unsafeCoerce = silly }}} I get {{{ [1 of 2] Compiling A ( A.hs, interpreted ) [2 of 2] Compiling B ( B.hs, interpreted ) Ok, modules loaded: A, B. }}} Eep! Happily, the fix is very very simple: `TyCon.isDistinctAlgRhs` should return `False` for `DataFamilyTyCon`s. This fix is already in-flight for HEAD in Phab:D968, but this ticket serves to correct this problem in 7.10.2 before the release. Patch coming very shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 01:26:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 01:26:02 -0000 Subject: [GHC] #10532: Unnecessary constraints when using overlapping instances In-Reply-To: <050.526817581fb74feaa1e19955b3232905@haskell.org> References: <050.526817581fb74feaa1e19955b3232905@haskell.org> Message-ID: <065.f19bd2fd87912dd541585164b85ccc8f@haskell.org> #10532: Unnecessary constraints when using overlapping instances -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by MikeIzbicki): I don't understand why this would be expected behavior. GHC lets me remove the constraint when overlapping instances are not involved, but requires the constraint when overlapping instances are involved. Why should there be a difference when overlapping instances gets involved? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 01:57:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 01:57:37 -0000 Subject: [GHC] #10534: Data families + Coercible = unsafeCoerce In-Reply-To: <047.8223986df67095beb90c9b80050632fc@haskell.org> References: <047.8223986df67095beb90c9b80050632fc@haskell.org> Message-ID: <062.992e56eaed192d207dc47d0cc889a091@haskell.org> #10534: Data families + Coercible = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D992 -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D992 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 02:00:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 02:00:17 -0000 Subject: [GHC] #10532: Unnecessary constraints when using overlapping instances In-Reply-To: <050.526817581fb74feaa1e19955b3232905@haskell.org> References: <050.526817581fb74feaa1e19955b3232905@haskell.org> Message-ID: <065.34860af888c00a032d627fc5851d372e@haskell.org> #10532: Unnecessary constraints when using overlapping instances -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Because, without overlapping instances, GHC can make a unique correct choice about what instance of `Foo` to use. With the overlapping instances, there is ambiguity which must be resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 02:12:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 02:12:17 -0000 Subject: [GHC] #10532: Unnecessary constraints when using overlapping instances In-Reply-To: <050.526817581fb74feaa1e19955b3232905@haskell.org> References: <050.526817581fb74feaa1e19955b3232905@haskell.org> Message-ID: <065.65aeade49ece15f6364eee11d032f861@haskell.org> #10532: Unnecessary constraints when using overlapping instances -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): In any event, what you seem to want is impossible: `f :: a -> Int` can never dispatch on the type of `a`, even with IncoherentInstances or any other language extension. You really must have the constraint if you want to use it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 04:52:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 04:52:16 -0000 Subject: [GHC] #10532: Unnecessary constraints when using overlapping instances In-Reply-To: <050.526817581fb74feaa1e19955b3232905@haskell.org> References: <050.526817581fb74feaa1e19955b3232905@haskell.org> Message-ID: <065.acbfa22396a1ccd7317c02fef16325e4@haskell.org> #10532: Unnecessary constraints when using overlapping instances -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by MikeIzbicki): Would something bad happen if GHC had the behavior I expected of automatically inferring the constraint? @rwbarton I don't understand what you mean. If I open the code in ghci I can evaluate the function f on any input whenever ghc actually compiles the code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 07:00:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 07:00:11 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.fcd1fd6700de26db062d9ac55bb71fb2@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by nomeata): > Does debian disable dynamic GHC by default as `DYNAMIC_GHC_PROGRAMS = NO`? No (`ldd /usr/lib/ghc/bin/ghc` lists various `libHS...` libraries). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 07:18:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 07:18:10 -0000 Subject: [GHC] #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' In-Reply-To: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> References: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> Message-ID: <057.68fb94f966209b07e609d88d1add8ec3@haskell.org> #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: attached Blocked By: | Blocking: Related Tickets: 437 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by imz): Strangely, this happens only on the second pass, after removing `A.o`. Although the sequence of actions is the same in the first pass, there are no errors in the first pass. (I've noticed a field named "Test Case" in the description. Should I write it according to https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding and request a pull? Or what am I supposed to submit a test-case? I'm not sure that the repeating the compilation commands can be described easily in that format...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 07:48:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 07:48:58 -0000 Subject: [GHC] #10532: Unnecessary constraints when using overlapping instances In-Reply-To: <050.526817581fb74feaa1e19955b3232905@haskell.org> References: <050.526817581fb74feaa1e19955b3232905@haskell.org> Message-ID: <065.6b4b4eb7545313153325d8cf2e34f836@haskell.org> #10532: Unnecessary constraints when using overlapping instances -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Consider what happens, in your modified code with overlapping instances, when you call `f` thus: `f (4::Int)`. What result do you expect? You might say: 1. The instance `Foo Int` clearly says that `foo` is the identity function on `Int`. I'm giving it an `Int` so `f 4` should return `4`. 2. Or you might say: when I compiled the code for `f`, GHC had to choose which instance to use, of the two available. Since the constraint is `Foo a`, and GHC knows nothing about `a` it must choose the `Foo a` instance. Result, `f 4` returns 5. This incoherence is what GHC is complaining about. If it can't make a unique choice, it decides not to decide, and rejects the program instead. If it silently chose (2), which I think you intend, then if you replaced the call `(f 4)` with the result of inlining `f`, thus `(foo 4)`, the result of the program would change. This has been GHC's behaviour (and Hugs) ever since we introduced overlapping instances. The flag `-XIncoherentInstances` switches off this behaviour, and does (2). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 08:01:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 08:01:09 -0000 Subject: [GHC] #10533: Typechecker behaves differently on Phab and on Mac In-Reply-To: <047.47efed1788c080f7defb630451503765@haskell.org> References: <047.47efed1788c080f7defb630451503765@haskell.org> Message-ID: <062.35a033a8e6d223c794e629dde4bd6d14@haskell.org> #10533: Typechecker behaves differently on Phab and on Mac -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Bizarre. This is with HEAD? Can you compile FD3 with `-ddump-tc-trace` on your Mac and attach the results? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 08:41:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 08:41:58 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.825eb5ff4be67afe83acacf152cc8db4@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by trommler): Replying to [comment:7 slyfox]: > From the above I suspect '''R_PPC_PLTREL24''' might require +0x8000 offset > and should be PLT relative. I'll try to look at it tomorrow. From the specs: ''This relocation indicates that reference to a symbol should be resolved through a call to the symbol?s Procedure Linkage Table entry. Additionally it instructs the link editor to build a procedure linkage table for the executable or shared object if one is not created.'' and under heading '''ATR-BSS-PLT''': ''Under the BSS-PLT ABI this relocation type may be implemented as a direct branch and link into the executable PLT slot which holds the absolute address (after resolution) of the specified symbol. There is an implicit assumption that the Procedure Linkage Table for a shared object or executable will be within ? 32 MB of an instruction that branches to it.'' I guess that debian is doing the latter so no PLT entry needs to be generated by the linker which would be {{{rts/Linker.c}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 08:47:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 08:47:14 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.6a650c60fa8f849ed8d66d99ab719c28@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by trommler): Replying to [comment:8 nomeata]: > > Does debian disable dynamic GHC by default as `DYNAMIC_GHC_PROGRAMS = NO`? > > No (`ldd /usr/lib/ghc/bin/ghc` lists various `libHS...` libraries). Are you using secure PLT? This might be done as part of hardening. In the ABI specs p 108 relocations {{{R_PPC_REL16*}}}: ''These relocation types are used to compute the distance between a symbol address and the current address. These relocations types are used under the '''Secure-PLT ABI''' to compute the address of the .got section because the link editor knows the fixed distance between the _GLOBAL_OFFSET_TABLE_ symbol and an address in the .text section.'' The specs referred to above is: Power Architecture? 32-bit Application Binary Interface Supplement 1.0 - Linux? & Embedded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 08:58:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 08:58:52 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.5dc252dc44c7baa088cf5a007911aad7@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by trommler): Replying to [comment:6 thoughtpolice]: > (I deleted the `.swp` file). > > I think this patch looks fine but to be safe I would prefer it if we could get a code review from Sergei and/or Peter. The code looks fine to me. I think it is safe to commit the code. The code in the patch will be called only if those relocations are actually present in an ELF object which is apparently the case on debian. If you like me to double check I could apply the patch to my local ghc package on openSUSE's build service and report back here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 11:59:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 11:59:59 -0000 Subject: [GHC] #10533: Typechecker behaves differently on Phab and on Mac In-Reply-To: <047.47efed1788c080f7defb630451503765@haskell.org> References: <047.47efed1788c080f7defb630451503765@haskell.org> Message-ID: <062.c6a244f10da76b899a730cdc90b6cf62@haskell.org> #10533: Typechecker behaves differently on Phab and on Mac -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): FWIW that commit validates on my Linux laptop also. Let me know if you want me to run any tests here. But first I'd rule out explanation like: are you starting from a dirty build tree possibly? For example, if you run validate does the test still fail? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 12:48:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 12:48:09 -0000 Subject: [GHC] #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' In-Reply-To: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> References: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> Message-ID: <057.036012c7953d08b33b396799707a3832@haskell.org> #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: attached Blocked By: | Blocking: Related Tickets: #437 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * related: 437 => #437 Comment: So the problem here is that while the interface file contains a hash of flags like `-main-is`, that hash isn't incorporated into the top-level interface hash. When you remove `A.o` (but ''not'' `A.hi`) and then rebuild `a`, GHC builds a new `A.o` with the symbols like `ZCMain_main_info` but doesn't update the interface file `A.hi` on disk accordingly, because it thinks it hasn't changed (the interface hash didn't change because it doesn't include the flag hash). Then when building `b` GHC sees that the interface file claims that main was not A.main when A was built, so GHC sees no need to recompile A. Relevant code starts at https://github.com/ghc/ghc/blob/bac927b9770ff769128b66d13a3e72bf5a9bc514/compiler/iface/MkIface.hs#L597. This looks like an easy fix except there are a few comments there I don't understand, like the one about two hashes being returned for the flag hash and the one that claims that the ABI hash depends on "flag abi hash". (Perhaps they apply to a version of the patch for #437 from before it was committed?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 13:02:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 13:02:32 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.4a89158aa48ead4452b4c0dc9dc85acc@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): FWIW this isn't a regression, 7.8 fails with the same error and 7.6 bails out even earlier. And isn't 7.10's behavior in fact the correct one? The instance produced by 7.11 is ill-kinded: {{{ instance [safe] forall (k :: BOX) (f :: k -> *) (g :: * -> k). (Functor f, Functor g) => Functor (Compose f g) }}} `Functor`'s argument must really be of kind `* -> *`. (Though I don't know if this will cause any harm beyond confusing error messages down the line.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 13:12:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 13:12:47 -0000 Subject: [GHC] #10529: hpc: Improve error messages in readMix In-Reply-To: <042.190bab483c0a9360715a797a8a3385e1@haskell.org> References: <042.190bab483c0a9360715a797a8a3385e1@haskell.org> Message-ID: <057.8b5b188fd73154c73283f5526d509d4d@haskell.org> #10529: hpc: Improve error messages in readMix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Code Coverage | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch Comment: I have a patch here: https://github.com/ghc/packages- hpc/commit/eaf1906f4456765becd3b52dee0188750feab2bf The error messages would look like this now: {{{ hpc: can not parse ./.hpc/NoParse.mix hpc: hash in .tix file does not match hash in ./.hpc/Main.mix hpc: can not find NonExistingModule in ["./.hpc"] }}} nh2: does that look alright to you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 13:19:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 13:19:39 -0000 Subject: [GHC] #10521: Wrong results in strict Word8 storage on x64 In-Reply-To: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> References: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> Message-ID: <070.e410b1f6dd53ebc3741d909a2e826919@haskell.org> #10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: VincentBerthoux2 | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => highest * milestone: => 7.10.2 Comment: Regression relative to 7.8, investigating... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 13:30:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 13:30:13 -0000 Subject: [GHC] #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' In-Reply-To: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> References: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> Message-ID: <057.1d07c4e8dff07fecf5b4a03060041b5f@haskell.org> #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: attached Blocked By: | Blocking: Related Tickets: #437 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by imz): But somehow if `-O1` is added everywhere, it sees the need to recompile A when building `b`. Isn't that a disturbing inconsistency? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 13:36:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 13:36:59 -0000 Subject: [GHC] #10535: Float out causes major space leak Message-ID: <045.805dcb016f0fb85535fb7bc68c72dcaf@haskell.org> #10535: Float out causes major space leak -------------------------------------+------------------------------------- Reporter: AlexET | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This issue originally was on haskell-cafe https://mail.haskell.org/pipermail/haskell-cafe/2015-June/120113.html The following code has a space leak {{{ #!hs numbers = [1..200] replicateM' :: Monad m => Int -> m a -> m [a] replicateM' 0 xs = return [] replicateM' n xs = do a <- xs b <- replicateM' (n-1) xs return (a:b) test :: [[Int]] test = replicateM' 4 numbers main = print test }}} The recursive call in replicateM' gets floated out. This then causes a very large (200^3 elements) list to be kept in memory instead of being lazily produced and consumed each time. A similar thing happens to the replicateM in Control.Monad but it is harder to spot as a lot of specialisation and fusion goes on before the float-out happens This is similar to #7367 but in this case we have a huge space-leak instead of just adding allocations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 13:37:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 13:37:47 -0000 Subject: [GHC] #10535: Float out causes major space leak In-Reply-To: <045.805dcb016f0fb85535fb7bc68c72dcaf@haskell.org> References: <045.805dcb016f0fb85535fb7bc68c72dcaf@haskell.org> Message-ID: <060.4e1dec47618bf83e5b9f57742b97c490@haskell.org> #10535: Float out causes major space leak -------------------------------------+------------------------------------- Reporter: AlexET | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by AlexET: Old description: > This issue originally was on haskell-cafe > https://mail.haskell.org/pipermail/haskell-cafe/2015-June/120113.html > > The following code has a space leak > > {{{ > #!hs > numbers = [1..200] > > replicateM' :: Monad m => Int -> m a -> m [a] > replicateM' 0 xs = return [] > replicateM' n xs = do > a <- xs > b <- replicateM' (n-1) xs > return (a:b) > > test :: [[Int]] > test = replicateM' 4 numbers > > main = print test > }}} > > The recursive call in replicateM' gets floated out. This then causes a > very large (200^3 elements) list to be kept in memory instead of being > lazily produced and consumed each time. > > A similar thing happens to the replicateM in Control.Monad but it is > harder to spot as a lot of specialisation and fusion goes on before the > float-out happens > > This is similar to #7367 but in this case we have a huge space-leak > instead of just adding allocations. New description: This issue originally was on haskell-cafe https://mail.haskell.org/pipermail/haskell-cafe/2015-June/120113.html The following code has a space leak {{{ #!hs numbers = [1..200] replicateM' :: Monad m => Int -> m a -> m [a] replicateM' 0 xs = return [] replicateM' n xs = do a <- xs b <- replicateM' (n-1) xs return (a:b) test :: [[Int]] test = replicateM' 4 numbers main = print test }}} The recursive call in replicateM' gets floated out. This then causes a very large (200^3^ elements) list to be kept in memory instead of being lazily produced and consumed each time. A similar thing happens to the replicateM in Control.Monad but it is harder to spot as a lot of specialisation and fusion goes on before the float-out happens This is similar to #7367 but in this case we have a huge space-leak instead of just adding allocations. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:07:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:07:44 -0000 Subject: [GHC] #10521: Wrong results in strict Word8 storage on x64 In-Reply-To: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> References: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> Message-ID: <070.c1a588b8408f9a4e5061c720edfab3ba@haskell.org> #10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: VincentBerthoux2 | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I suggest generating removing just one bang (which apparently is enough to provoke the difference) and compare output of `-ddump-simpl` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:10:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:10:55 -0000 Subject: [GHC] #10535: Float out causes major space leak In-Reply-To: <045.805dcb016f0fb85535fb7bc68c72dcaf@haskell.org> References: <045.805dcb016f0fb85535fb7bc68c72dcaf@haskell.org> Message-ID: <060.4e6da186385282d74f7086e996d2b31c@haskell.org> #10535: Float out causes major space leak -------------------------------------+------------------------------------- Reporter: AlexET | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Can you tell whether this is related to the state hack? I.e., does `-fno- state-hack` make a difference? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:19:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:19:13 -0000 Subject: [GHC] #8785: Replace hooks API in the RTS with something better In-Reply-To: <047.cfaec68e96673ab1544c0369207069d6@haskell.org> References: <047.cfaec68e96673ab1544c0369207069d6@haskell.org> Message-ID: <062.deaaa9859f96fe766d87e2648a4ab83f@haskell.org> #8785: Replace hooks API in the RTS with something better -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D8 -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:19:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:19:45 -0000 Subject: [GHC] #10535: Float out causes major space leak In-Reply-To: <045.805dcb016f0fb85535fb7bc68c72dcaf@haskell.org> References: <045.805dcb016f0fb85535fb7bc68c72dcaf@haskell.org> Message-ID: <060.eb9146509a1e5305c121e4043818ebf6@haskell.org> #10535: Float out causes major space leak -------------------------------------+------------------------------------- Reporter: AlexET | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by AlexET): {{{-fno-state-hack}}} makes no difference {{{-fno-full-laziness}}} does fix the problem. In many ways the float out pass is doing what it is supposed to (floating out a shared value though a lambda) as it now does less work. However the list which is floated out is produced and consumed lazily and hence the floating out causes a major space leak (space leak may be the wrong term as the extra is constant but very large (1GB)). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:19:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:19:46 -0000 Subject: [GHC] #10529: hpc: Improve error messages in readMix In-Reply-To: <042.190bab483c0a9360715a797a8a3385e1@haskell.org> References: <042.190bab483c0a9360715a797a8a3385e1@haskell.org> Message-ID: <057.83a388127100b4ad40e7e85f756c5b65@haskell.org> #10529: hpc: Improve error messages in readMix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Code Coverage | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nh2): @thomie, yes that looks good to me. The only thing I'd change is adding more detail to the error message, e.g. mentioning the `modName` and what the values of the two hashes are that aren't matching - that makes it much easier to debug what's wrong when something is wrong. I'll also add a comment on Github for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:26:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:26:26 -0000 Subject: [GHC] #10534: Data families + Coercible = unsafeCoerce In-Reply-To: <047.8223986df67095beb90c9b80050632fc@haskell.org> References: <047.8223986df67095beb90c9b80050632fc@haskell.org> Message-ID: <062.2900cdbe71b066a7c63426a59a5ab550@haskell.org> #10534: Data families + Coercible = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D992 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"89c7168c150ccc38a2e6dd4a3aea555616722260/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="89c7168c150ccc38a2e6dd4a3aea555616722260" Fix #10534 Test case: typecheck/should_fail/T10534 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:27:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:27:33 -0000 Subject: [GHC] #10534: Data families + Coercible = unsafeCoerce In-Reply-To: <047.8223986df67095beb90c9b80050632fc@haskell.org> References: <047.8223986df67095beb90c9b80050632fc@haskell.org> Message-ID: <062.1565cde3e29e5a725f4819faa568b0a2@haskell.org> #10534: Data families + Coercible = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T10534 | Blocking: | Differential Revisions: Phab:D992 -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => merge * testcase: => typecheck/should_fail/T10534 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:27:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:27:50 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.1f94051be91ab85f75e4e0e758c1702f@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: high => highest Comment: Promoting as a regression over 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:28:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:28:24 -0000 Subject: [GHC] #10535: Float out causes major space leak In-Reply-To: <045.805dcb016f0fb85535fb7bc68c72dcaf@haskell.org> References: <045.805dcb016f0fb85535fb7bc68c72dcaf@haskell.org> Message-ID: <060.5f9fa68b9d3597ac6d2af43753717619@haskell.org> #10535: Float out causes major space leak -------------------------------------+------------------------------------- Reporter: AlexET | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #7367 #7206 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * related: => #7367 #7206 Comment: Ah, right. Sounds like a case for http://arxiv.org/abs/1207.2017 :-]. Anyways, this is a tricky problem; how could the compiler detect things that are cheaper to recalculate than to share? #7206 is also related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:29:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:29:27 -0000 Subject: [GHC] #8648: Initialization of C statics broken in threaded runtime In-Reply-To: <044.f1cfb611748ab32509135bb2aba15bfa@haskell.org> References: <044.f1cfb611748ab32509135bb2aba15bfa@haskell.org> Message-ID: <059.4b01bd74495deae69cb6be2db85f3b5b@haskell.org> #8648: Initialization of C statics broken in threaded runtime -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): I *think* this bug is fixed by Phab:D975. There were bugs in the way we were allocating the BSS segment for dynamically linked code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:37:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:37:34 -0000 Subject: [GHC] #7428: GHC compile times are seriously non-linear in program size In-Reply-To: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> References: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> Message-ID: <060.03d25862813d0f17d9ec0239007e6a38@haskell.org> #7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): See [http://research.microsoft.com/en- us/um/people/simonpj/papers/variant-f/index.htm Scrap your type applications] Section 2.3, for why types can (legitimately I fear) blow up. I'm not say that is what is happening here, but it might be similar. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:43:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:43:21 -0000 Subject: [GHC] #10533: Typechecker behaves differently on Phab and on Mac In-Reply-To: <047.47efed1788c080f7defb630451503765@haskell.org> References: <047.47efed1788c080f7defb630451503765@haskell.org> Message-ID: <062.73ae44aef88ca711eddb49b582c67157@haskell.org> #10533: Typechecker behaves differently on Phab and on Mac -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Just rebuilt on a different Mac (both with MacOS 10.8.5) from scratch with the same behavior. Here is an excerpt: {{{ 10:40:42 ~/Documents/Programming/ghc- cur/testsuite/tests/typecheck/should_compile> git log -n 1 commit 61b96a86c5342fb1c850361177d60fe855d948f6 Author: Richard Eisenberg Date: Fri Jun 5 09:56:21 2015 -0400 Fix #10489 Dang, roles are annoying. Test case: typecheck/should_compile/T10489 10:40:45 ~/Documents/Programming/ghc- cur/testsuite/tests/typecheck/should_compile> ~/Documents/Programming/ghc- cur/inplace/bin/ghc-stage2 --version The Glorious Glasgow Haskell Compilation System, version 7.11.20150605 10:40:53 ~/Documents/Programming/ghc- cur/testsuite/tests/typecheck/should_compile> ~/Documents/Programming/ghc- cur/inplace/bin/ghc-stage2 -ddump-tc-trace FD3.hs > ~/temp/FD3.log 2>&1 10:41:26 ~/Documents/Programming/ghc- cur/testsuite/tests/typecheck/should_compile> }}} The trace is attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:45:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:45:21 -0000 Subject: [GHC] #10533: Typechecker behaves differently on Phab and on Mac In-Reply-To: <047.47efed1788c080f7defb630451503765@haskell.org> References: <047.47efed1788c080f7defb630451503765@haskell.org> Message-ID: <062.3c362d6ff31302da1e0870ae46318311@haskell.org> #10533: Typechecker behaves differently on Phab and on Mac -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Happy to help with further debugging, but it's hard to know where to begin without seeing what the correct behavior is, which I can't seem to get on my machine. @rwbarton, could you perhaps post your `-ddump-tc-trace` as well for comparison? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:55:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:55:44 -0000 Subject: [GHC] #10533: Typechecker behaves differently on Phab and on Mac In-Reply-To: <047.47efed1788c080f7defb630451503765@haskell.org> References: <047.47efed1788c080f7defb630451503765@haskell.org> Message-ID: <062.4862db5501915f9196ad9d60cb5231bd@haskell.org> #10533: Typechecker behaves differently on Phab and on Mac -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Attached. Your output seems to have additional messages that are enabled when `debugIsOn`, so maybe some other debugging output or assertion is panicking for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 14:58:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 14:58:41 -0000 Subject: [GHC] #10348: HEAD: `KnownNat` does not imply `Typeable` any more In-Reply-To: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> References: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> Message-ID: <063.9caac89dea981fb2b42d0113faed1632@haskell.org> #10348: HEAD: `KnownNat` does not imply `Typeable` any more -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: diatchki Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by heisenbug): I changed the test case thus: {{{ diff --git a/testsuite/tests/typecheck/should_compile/T10348.hs b/testsuite/tests/typecheck/should_compile/T10348.hs index 213079b..14fc085 100644 --- a/testsuite/tests/typecheck/should_compile/T10348.hs +++ b/testsuite/tests/typecheck/should_compile/T10348.hs @@ -15,8 +15,7 @@ data T t where deriving instance Show (T n) -hey :: (Typeable n, KnownNat n) => T (Foo n) --- SHOULD BE: hey :: KnownNat n => T (Foo n) +hey :: KnownNat n => T (Foo n) hey = T Hey ho :: T (Foo 42) }}} Then this code (I just added a panic for visibility) is triggered: {{{ diff --git a/compiler/typecheck/TcInteract.hs b/compiler/typecheck/TcInteract.hs index 01b0ba1..bf5f237 100644 --- a/compiler/typecheck/TcInteract.hs +++ b/compiler/typecheck/TcInteract.hs @@ -48,6 +48,7 @@ import Pair (Pair(..)) import Unique( hasKey ) import DynFlags import Util +import TypeRep( Type(..) ) {- ********************************************************************** @@ -1852,6 +1853,8 @@ matchTypeableClass clas _k t | Just (f,kt) <- splitAppTy_maybe t = doTyApp f kt | Just _ <- isNumLitTy t = mkSimpEv (EvTypeableTyLit t) | Just _ <- isStrLitTy t = mkSimpEv (EvTypeableTyLit t) + | TyConApp con [] <- _k + , Just tcon <- isPromotedTyCon_maybe con = pprPanic "matchTypeableClass" $ ppr tcon | otherwise = return NoInstance where }}} I guess code must be generated that creates the Typeable hash on the fly (at runtime) by appealing to the KnownNat's method. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 15:08:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 15:08:01 -0000 Subject: [GHC] #10533: Typechecker behaves differently on Phab and on Mac In-Reply-To: <047.47efed1788c080f7defb630451503765@haskell.org> References: <047.47efed1788c080f7defb630451503765@haskell.org> Message-ID: <062.3d83cede507ca42f2df492ba454bbdf7@haskell.org> #10533: Typechecker behaves differently on Phab and on Mac -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:5 rwbarton]: > Attached. Your output seems to have additional messages that are enabled when `debugIsOn`, so maybe some other debugging output or assertion is panicking for you? Of course. The panic is an `ASSERT`ion failure. So perhaps the problem is happening on all platforms, but only caught in a `DEBUG` build. Indeed, your log contains the problematic derived constraint at the end of `tryReporters`. It just doesn't bail out. So, weirdness resolved, I believe... but now we need to figure out why that assertion is failing. Modifying ticket accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 15:11:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 15:11:23 -0000 Subject: [GHC] #10533: Assertion failure on FD3 test in TcErrors (was: Typechecker behaves differently on Phab and on Mac) In-Reply-To: <047.47efed1788c080f7defb630451503765@haskell.org> References: <047.47efed1788c080f7defb630451503765@haskell.org> Message-ID: <062.5be550b60d6bd5681b85db4fdd00beb2@haskell.org> #10533: Assertion failure on FD3 test in TcErrors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * os: MacOS X => Unknown/Multiple * component: Compiler => Compiler (Type checker) Old description: > On my Mac, commit 61b96a86c5342fb1c850361177d60fe855d948f6 causes test > `typecheck/should_compile/FD3` to fail. But Phab succeeded in validating > this commit, as seen [https://phabricator.haskell.org/B4297 here]. (I > don't believe that commit has anything to do with the failure -- it's > just the snapshot I looked at.) > > This leads to two questions: > > 1. Why does this test fail on a Mac? > > 2. Why does the typechecker behave differently, at all, on two different > platforms? New description: Test case `typecheck/should_compile/FD3` leads to an `ASSERT`ion error: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150605 for x86_64-apple-darwin): ASSERT failed! file compiler/typecheck/TcErrors.hs line 321 [[D] _ :: a_amP[sk] ~ (String, a_amP[sk]) (CNonCanonical)] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} FD3.log (attached) shows the error happening. (When originally posting this ticket, I was very confused. The first several comments, through comment:6, are now bogus. Please ignore.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 15:29:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 15:29:26 -0000 Subject: [GHC] #10521: Wrong results in strict Word8 storage on x64 In-Reply-To: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> References: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> Message-ID: <070.916983eed44a1100789d1e64034fbf02@haskell.org> #10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: VincentBerthoux2 | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I reduced the test case further to {{{ import Data.Word( Word8 ) toV :: Float -> Word8 toV d = let coeff = significand d * 255.9999 / d a = truncate $ d * coeff b = exponent d in a `seq` (b `seq` a) -- just b `seq` a is not enough to reproduce the bug main :: IO () main = print $ map toV [ 3.56158e-2, 0.7415215, 0.5383201, 0.1289829, 0.45520145 ] }}} It's looking like an issue in the backend where it doesn't understand that F1 and D1 are the same physical register (%xmm1) on x86_64. Possibly an old issue that was uncovered by 7.10's new implementation of `significand :: Float -> Float` going through Double. Specifically for the (correct) Core {{{ Main.main14 = \ (d_aC5 [OS=ProbOneShot] :: Float) -> case d_aC5 of _ [Occ=Dead] { GHC.Types.F# x_a22N -> case GHC.Prim.decodeFloat_Int# x_a22N of _ [Occ=Dead] { (# ipv_a1Gg, ipv1_a1Gh #) -> case integer-gmp-1.0.0.0:GHC.Integer.Type.encodeDoubleInteger (integer-gmp-1.0.0.0:GHC.Integer.Type.smallInteger ipv_a1Gg) (-24) of wild1_a1Gj { __DEFAULT -> case GHC.Float.$w$cexponent1 x_a22N of _ [Occ=Dead] { __DEFAULT -> case GHC.Prim.divideFloat# (GHC.Prim.timesFloat# (GHC.Prim.double2Float# wild1_a1Gj) (__float 255.9999)) x_a22N of wild2_a234 { __DEFAULT -> GHC.Word.W8# (GHC.Prim.narrow8Word# (GHC.Prim.int2Word# (GHC.Prim.float2Int# (GHC.Prim.timesFloat# x_a22N wild2_a234)))) } } } } } }}} we generate Cmm like {{{ ... c3MY: I64[Sp] = c3N2; R3 = (-24); R2 = R1; call GHC.Integer.Type.encodeDoubleInteger_info(R3, R2) returns to c3N2, args: 8, res: 8, upd: 8; c3N2: I64[Sp - 8] = c3N6; F1 = F32[Sp + 8]; F64[Sp] = D1; Sp = Sp - 8; call GHC.Float.$w$cexponent1_info(F1) returns to c3N6, args: 8, res: 8, upd: 8; ... }}} The assignment to F1 is to set up the arguments for `$w$cexponent1` from `x_a22N` which has been saved on the stack, and the read from D1 is to save the return value `wild1_a1Gj` from `encodeDoubleInteger`. Technically the program became incorrect in the "Sink assignments" pass when the read from D1 was moved past the store to F1, but maybe it just doesn't make sense to cater to the possibility of multiple STG global registers being aliases of one another. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 15:54:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 15:54:40 -0000 Subject: [GHC] #10521: Wrong results in strict Word8 storage on x64 In-Reply-To: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> References: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> Message-ID: <070.4bf6f9693efa7c36b3c717b5660459f9@haskell.org> #10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: VincentBerthoux2 | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): The commit that merged F1 and D1 was e2f6bbd3a27685bc667655fdb093734cb565b4cf which is in 7.8 but not 7.6. Here is a reproducer for 7.8 too: {{{ {-# LANGUAGE MagicHash #-} import GHC.Exts f :: Float# -> Float# f x = x {-# NOINLINE f #-} g :: Double# -> Double# g x = x {-# NOINLINE g #-} h :: Float -> Float h (F# x) = let a = F# (f x) b = D# (g (2.0##)) in a `seq` (b `seq` a) main = print (h 1.0) -- with ghc -O, prints 0.0 }}} Not sure yet whether it is better to revert (parts of) that commit or to try to account for STG global registers overlapping in the cmmSink pass and wherever else it might be necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 16:57:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 16:57:28 -0000 Subject: [GHC] #10534: Data families + Coercible = unsafeCoerce In-Reply-To: <047.8223986df67095beb90c9b80050632fc@haskell.org> References: <047.8223986df67095beb90c9b80050632fc@haskell.org> Message-ID: <062.7f427142c0eecb7421567a01e8059477@haskell.org> #10534: Data families + Coercible = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T10534 | Blocking: | Differential Revisions: Phab:D992 -------------------------------------+------------------------------------- Comment (by simonpj): This pne-line change _really_ needs more comments. But once the next patch lands it'll have them, and we can do without on the 7.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 17:03:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 17:03:23 -0000 Subject: [GHC] #10534: Data families + Coercible = unsafeCoerce In-Reply-To: <047.8223986df67095beb90c9b80050632fc@haskell.org> References: <047.8223986df67095beb90c9b80050632fc@haskell.org> Message-ID: <062.9ad25cf6dbae501f945a6894bc4828e9@haskell.org> #10534: Data families + Coercible = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T10534 | Blocking: | Differential Revisions: Phab:D992 -------------------------------------+------------------------------------- Comment (by goldfire): Yes, of course. The bigger patch has run into a few validation problems that I'm working through. I fully expect to land today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 17:06:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 17:06:43 -0000 Subject: [GHC] #10521: Wrong results in strict Word8 storage on x64 In-Reply-To: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> References: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> Message-ID: <070.bd635bbc615645671ef069e2ae9779ec@haskell.org> #10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: VincentBerthoux2 | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Reid you are a marvel, thank you. My instinct is to "account for registers" overlapping. After all, if Cmm optimisations don't know that two registers are the same, all manner of bad things can happen, perhaps not limited to `CmmSink`. Is this just the Eq instance for `CmmReg`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 17:20:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 17:20:21 -0000 Subject: [GHC] #8131: T7571 with WAY=llvm fails, but not WAY=optllvm In-Reply-To: <052.22eb4f882263987206e929bacae5db28@haskell.org> References: <052.22eb4f882263987206e929bacae5db28@haskell.org> Message-ID: <067.c825d31a13c524bc383ae2c15a4465f8@haskell.org> #8131: T7571 with WAY=llvm fails, but not WAY=optllvm -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: rwbarton Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | llvm/should_compile/T8131 | Blocking: | Differential Revisions: Phab:D624 -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 17:25:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 17:25:26 -0000 Subject: [GHC] #10521: Wrong results in strict Word8 storage on x64 In-Reply-To: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> References: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> Message-ID: <070.1f645ca82e18f2fe598f5f0268d14aa8@haskell.org> #10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: VincentBerthoux2 | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => rwbarton Comment: In fact I did try just changing GlobalReg's Eq instance (and Ord instance) to treat `FloatReg i` and `DoubleReg i` as the same, and that did fix this issue. Doing this properly will require a bit more refactoring than that, since whether these registers overlap depends on the DynFlags, but it looks like it will be nothing too serious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 18:06:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 18:06:53 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.fd4ee3f9a68afef1d513ca01022d19f6@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D767 -------------------------------------+------------------------------------- Changes (by goldfire): * owner: javran => * status: closed => new * resolution: fixed => Comment: The T9579 tests are all failing during validation on my Mac. For example: {{{ Actual stdout output differs from expected: --- ./T9579_outofheap_rtsall.stdout.normalised 2015-06-16 14:06:15.000000000 -0400 +++ ./T9579_outofheap_rtsall.run.stdout.normalised 2015-06-16 14:06:15.000000000 -0400 @@ -1,4 +1,4 @@ T9579_outofheap_rtsall: Heap exhausted; -T9579_outofheap_rtsall: Current maximum heap size is NUM bytes (1 MB). +T9579_outofheap_rtsall: Current maximum heap size is 1048576 bytes (1 MB). T9579_outofheap_rtsall: Use `+RTS -M' to increase it. 251 \ No newline at end of file *** unexpected failure for T9579_outofheap_rtsall(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 18:15:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 18:15:51 -0000 Subject: [GHC] #8131: T7571 with WAY=llvm fails, but not WAY=optllvm In-Reply-To: <052.22eb4f882263987206e929bacae5db28@haskell.org> References: <052.22eb4f882263987206e929bacae5db28@haskell.org> Message-ID: <067.b05dc9f9a07a93924ce0a4982e81e91a@haskell.org> #8131: T7571 with WAY=llvm fails, but not WAY=optllvm -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: rwbarton Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | llvm/should_compile/T8131 | Blocking: | Differential Revisions: Phab:D624 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"681973c31c614185229bdae4f6b7ab4f6e64753d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="681973c31c614185229bdae4f6b7ab4f6e64753d" Encode alignment in MO_Memcpy and friends Summary: Alignment needs to be a compile-time constant. Previously the code generators had to jump through hoops to ensure this was the case as the alignment was passed as a CmmExpr in the arguments list. Now we take care of this up front. This fixes #8131. Authored-by: Reid Barton Dusted-off-by: Ben Gamari Tests for T8131 Test Plan: Validate Reviewers: rwbarton, austin Reviewed By: rwbarton, austin Subscribers: bgamari, carter, thomie Differential Revision: https://phabricator.haskell.org/D624 GHC Trac Issues: #8131 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 18:15:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 18:15:51 -0000 Subject: [GHC] #8131: T7571 with WAY=llvm fails, but not WAY=optllvm In-Reply-To: <052.22eb4f882263987206e929bacae5db28@haskell.org> References: <052.22eb4f882263987206e929bacae5db28@haskell.org> Message-ID: <067.a0551e4b4c9aabf2b47f8b4967c75061@haskell.org> #8131: T7571 with WAY=llvm fails, but not WAY=optllvm -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: rwbarton Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | llvm/should_compile/T8131 | Blocking: | Differential Revisions: Phab:D624 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a0d158fdd1db6b8f586bcbc1acd317d9836fb9dc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a0d158fdd1db6b8f586bcbc1acd317d9836fb9dc" Encode alignment in MO_Memcpy and friends Summary: Alignment needs to be a compile-time constant. Previously the code generators had to jump through hoops to ensure this was the case as the alignment was passed as a CmmExpr in the arguments list. Now we take care of this up front. This fixes #8131. Authored-by: Reid Barton Dusted-off-by: Ben Gamari Tests for T8131 Test Plan: Validate Reviewers: rwbarton, austin Reviewed By: rwbarton, austin Subscribers: bgamari, carter, thomie Differential Revision: https://phabricator.haskell.org/D624 GHC Trac Issues: #8131 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 18:22:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 18:22:37 -0000 Subject: [GHC] #10494: Representational equalities over AppTys are not hard failures In-Reply-To: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> References: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> Message-ID: <062.0f8e34a6d4343fd063459be55a8ccb62@haskell.org> #10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c772f57e128e04415949f91f299ec9bcc60c4caf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c772f57e128e04415949f91f299ec9bcc60c4caf" Fix #10494 Now representational AppTys are just IrredEvCans, as they should be. Test case: typecheck/should_compile/T10494 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 18:22:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 18:22:37 -0000 Subject: [GHC] #10495: Total inability to infer type for coerce In-Reply-To: <047.88be9b06528fbf6e5c30196ecacf3fe5@haskell.org> References: <047.88be9b06528fbf6e5c30196ecacf3fe5@haskell.org> Message-ID: <062.b4ceec6abf8266e7efcb8773fb36de8f@haskell.org> #10495: Total inability to infer type for coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"0de0b14691e0b0789988332ad5addc2a31b09ba6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0de0b14691e0b0789988332ad5addc2a31b09ba6" Fix #10495. This change means that the intricate reasoning in TcErrors around getting messages just right for nominal equalities is skipped for representational equalities. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 18:22:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 18:22:37 -0000 Subject: [GHC] #10493: Inaccessible code might be accessible with newtypes and Coercible In-Reply-To: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> References: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> Message-ID: <062.61a463f8500edc2ba704a50882144d68@haskell.org> #10493: Inaccessible code might be accessible with newtypes and Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"ace8d4fcfd798b70c34e325c562878b0a8f5e2cb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ace8d4fcfd798b70c34e325c562878b0a8f5e2cb" Fix #10493. Now, a Coercible (T1 ...) (T2 ...) constraint is insoluble only when both T1 and T2 say "yes" to isDistinctTyCon. Several comments also updated in this patch. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 18:22:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 18:22:37 -0000 Subject: [GHC] #10428: GHC cannot match representations using Coercible constraint In-Reply-To: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> References: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> Message-ID: <062.79e0dbbc7c2644822d860b628f0f2ae4@haskell.org> #10428: GHC cannot match representations using Coercible constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_compile/T10428 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"66440396bef30e5d6c7b536b552cc4f557d70691/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="66440396bef30e5d6c7b536b552cc4f557d70691" Test case for #10428. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 18:24:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 18:24:31 -0000 Subject: [GHC] #10523: Add Monoid instance for IO In-Reply-To: <049.6279cecb8fcd2b294d6df5d83cd891b5@haskell.org> References: <049.6279cecb8fcd2b294d6df5d83cd891b5@haskell.org> Message-ID: <064.78ee71fd71a0a69fc8f1048fc52ba225@haskell.org> #10523: Add Monoid instance for IO -------------------------------------+------------------------------------- Reporter: Gabriel439 | Owner: Gabriel439 Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D988 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D988 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 18:26:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 18:26:31 -0000 Subject: [GHC] #10495: Poor error message for Coercible constraint unsatisfiability (was: Total inability to infer type for coerce) In-Reply-To: <047.88be9b06528fbf6e5c30196ecacf3fe5@haskell.org> References: <047.88be9b06528fbf6e5c30196ecacf3fe5@haskell.org> Message-ID: <062.2fdc0ecb8eb07b2c32e2fb08e8dbefc0@haskell.org> #10495: Poor error message for Coercible constraint unsatisfiability -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T10495 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_fail/T10495 * milestone: => 7.10.3 Comment: Merge (into 7.10.3) if convenient. This is just about error messages, so not very important. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 18:29:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 18:29:20 -0000 Subject: [GHC] #10493: Inaccessible code might be accessible with newtypes and Coercible In-Reply-To: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> References: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> Message-ID: <062.688a7740e6fd9d98ffd57915b35ba260@haskell.org> #10493: Inaccessible code might be accessible with newtypes and Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_compile/T10493 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_compile/T10493 * milestone: => 7.10.3 Old description: > If I say > > {{{ > module A (Age, ageCo) where > > import Data.Type.Coercion > > newtype Age = MkAge Int > > ageCo :: Coercion Age Int > ageCo = Coercion > }}} > > {{{ > {-# LANGUAGE FlexibleContexts #-} > > module B where > > import Data.Coerce > import A > > foo :: Coercible Age Int => () > foo = () > }}} > > I get > > {{{ > B.hs:8:8: error: > Couldn't match representation of type ?Age? with that of ?Int? > Inaccessible code in > the type signature for: foo :: Coercible Age Int => () > In the ambiguity check for the type signature for ?foo?: > foo :: Coercible Age Int => () > To defer the ambiguity check to use sites, enable AllowAmbiguousTypes > In the type signature for ?foo?: foo :: Coercible Age Int => () > }}} > > I agree that module `B` can't directly prove `Coercible Age Int`. But > `ageCo` is in scope which proves exactly this! So it is provable, albeit > directly. GHC should not claim that the code is inaccessible. > > Proposed fix: in `canDecomposableTyConApp`, only call `canEqHardFailure` > for a representational equality when both tycons involved say `True` to > `isDistinctTyCon`. > > I'm happy to put the fix in, once someone seconds this idea. Getting this > right has proved harder than I thought! New description: If I say {{{ module A (Age, ageCo) where import Data.Type.Coercion newtype Age = MkAge Int ageCo :: Coercion Age Int ageCo = Coercion }}} {{{ {-# LANGUAGE FlexibleContexts #-} module B where import Data.Coerce import A foo :: Coercible Age Int => () foo = () }}} I get {{{ B.hs:8:8: error: Couldn't match representation of type ?Age? with that of ?Int? Inaccessible code in the type signature for: foo :: Coercible Age Int => () In the ambiguity check for the type signature for ?foo?: foo :: Coercible Age Int => () To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ?foo?: foo :: Coercible Age Int => () }}} I agree that module `B` can't directly prove `Coercible Age Int`. But `ageCo` is in scope which proves exactly this! So it is provable, albeit indirectly. GHC should not claim that the code is inaccessible. Proposed fix: in `canDecomposableTyConApp`, only call `canEqHardFailure` for a representational equality when both tycons involved say `True` to `isDistinctTyCon`. I'm happy to put the fix in, once someone seconds this idea. Getting this right has proved harder than I thought! -- Comment: Merge if convenient. This is a real bug, but it's somewhat obscure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 18:30:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 18:30:51 -0000 Subject: [GHC] #10494: Representational equalities over AppTys are not hard failures In-Reply-To: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> References: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> Message-ID: <062.f900d52771f90c0b0022a7033dcaf656@haskell.org> #10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_compile/T10494 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_compile/T10494 * milestone: => 7.10.3 Comment: Merge if convenient. Another real bug, but I doubt it's ruining anyone's day. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 18:51:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 18:51:56 -0000 Subject: [GHC] #10529: hpc: Improve error messages in readMix In-Reply-To: <042.190bab483c0a9360715a797a8a3385e1@haskell.org> References: <042.190bab483c0a9360715a797a8a3385e1@haskell.org> Message-ID: <057.ef8bf826f716d31d75ee8a47db4a4770@haskell.org> #10529: hpc: Improve error messages in readMix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Code Coverage | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Updated patch: https://github.com/ghc/packages- hpc/commit/6b88e91c8a0e7806d44d999616983c60a0b8eb78 Now you'll get something like this: {{{ hpc: hash in tix file for module Main (1234567890) does not match hash in ./.hpc/Main.mix (2454134535) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 18:57:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 18:57:06 -0000 Subject: [GHC] #10532: Unnecessary constraints when using overlapping instances In-Reply-To: <050.526817581fb74feaa1e19955b3232905@haskell.org> References: <050.526817581fb74feaa1e19955b3232905@haskell.org> Message-ID: <065.2db8cfa85c528b5b0f777e49af39dd1b@haskell.org> #10532: Unnecessary constraints when using overlapping instances -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by MikeIzbicki): I understand the differences between `-XOverlappingInstances` and `-XIncoherentInstances`, and my question is not about that. My question is just about syntax. Without `-XOverlappingInstances`, GHC interprets the types `a -> Int` and `Foo a => a -> Int` as the same thing. Whenever you can use one, you can also use the other (at least in all the cases I tried). But without overlapping instances, GHC no longer interprets these types the same way. Only the second type is valid for `f`, but I would rather write the first type because I know GHC can find an instance `Foo` for all `a`. The particular instance will depend on the weird interactions caused by overlapping instances, but there's guaranteed to be an instance available. My question is: Why is this syntactic difference useful? Maybe parametricity would be broken without it? ---- Even if this syntactic difference is useful, I still think there is a GHC bug. Consider what happens in the overlapping instances case when you omit the type signature for `f = foo`. GHC infers the type `a -> Int`, but then complains that the class constraint `Foo` can't be found. GHC should instead infer the type `Foo a => a -> Int`, which would let us omit the type signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 19:01:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 19:01:46 -0000 Subject: [GHC] #10508: comipleExpr or :def in GHCi rejects valid multiline expr or accepts invalid expr In-Reply-To: <046.c1b1b2bc0314b9941dba83381f0b0248@haskell.org> References: <046.c1b1b2bc0314b9941dba83381f0b0248@haskell.org> Message-ID: <061.f746f47174bd84962e3419ff2634061b@haskell.org> #10508: comipleExpr or :def in GHCi rejects valid multiline expr or accepts invalid expr -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: GHC API | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | ghci/scripts/T10508 ghc- Blocked By: | api/T10508_api Related Tickets: | Blocking: | Differential Revisions: Phab:D974 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * testcase: => ghci/scripts/T10508 ghc-api/T10508_api * resolution: => fixed * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 19:06:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 19:06:43 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.d693dd2276ce5e7facfa46a9b95273d9@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: terrelln Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | ConstraintKinds, newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | polykinds/T10451 | Blocking: | Differential Revisions: Phab:D986 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * testcase: => polykinds/T10451 * resolution: => fixed Comment: > increase the size limit on constraint tuples to be the same as normal tuples (62) Done, thanks to a patch by Nick Terrell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 19:09:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 19:09:26 -0000 Subject: [GHC] #10532: Unnecessary constraints when using overlapping instances In-Reply-To: <050.526817581fb74feaa1e19955b3232905@haskell.org> References: <050.526817581fb74feaa1e19955b3232905@haskell.org> Message-ID: <065.f1d1ef4c53947fe4345125a29a9df582@haskell.org> #10532: Unnecessary constraints when using overlapping instances -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): What would you like to happen when GHC sees `(f (3 :: Int))`? My guess is that you expect GHC to notice that there is an instance for `Foo Int` around and to use it. But if `f` had the type `a -> Int`, then there is nothing to tell GHC to go out and look for the instance. When we have `f :: Foo a => a -> Int`, it tells GHC to look for a `Foo` instance at call sites. If, on the other hand, you want `f` always to use the `Foo a` instance, then `IncoherentInstances` is the way to go. I don't see this as an issue of parametricity, but just one of a misunderstanding about what the type signature means. As for what happens when you omit the signature: You're hitting the monomorphism restriction. When I load this into GHCi: {{{ {-# LANGUAGE FlexibleInstances, NoMonomorphismRestriction #-} class Foo a where foo :: a -> Int instance {-# OVERLAPS #-} Foo Int where foo = id instance {-# OVERLAPPABLE #-} Foo a where foo _ = 5 f = foo }}} I get an inferred type for `f` of `Foo a => a -> Int`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 19:28:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 19:28:24 -0000 Subject: [GHC] #10532: Unnecessary constraints when using overlapping instances In-Reply-To: <050.526817581fb74feaa1e19955b3232905@haskell.org> References: <050.526817581fb74feaa1e19955b3232905@haskell.org> Message-ID: <065.ea07cbf1ad977c35594c39b90762cfca@haskell.org> #10532: Unnecessary constraints when using overlapping instances -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by MikeIzbicki): Ok. I think I understand. Thanks for all the help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 19:41:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 19:41:51 -0000 Subject: [GHC] #10536: Clear up how to turn off dynamic linking in build.mk Message-ID: <045.541a8a1a6994293a5767d3af2bef8566@haskell.org> #10536: Clear up how to turn off dynamic linking in build.mk -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See https://mail.haskell.org/pipermail/ghc-devs/2014-December/007725.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 20:09:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 20:09:57 -0000 Subject: [GHC] #9978: DEBUG is always replaced as 1 when CPP pragma is on In-Reply-To: <046.1e158369b154425aa800b189096e6147@haskell.org> References: <046.1e158369b154425aa800b189096e6147@haskell.org> Message-ID: <061.cabbdb479f0330d6907363780626f2cd@haskell.org> #9978: DEBUG is always replaced as 1 when CPP pragma is on -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: cpp Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: I can not reproduce your problem. Can you paste the output of the following command with your program above: `ghc-7.8.4 -E T9978.hs -fforce-recomp -v`. Check if it contains `-DDEBUG`, and why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 20:18:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 20:18:09 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.e097479104ddb8c0ac2097b20f667180@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 20:43:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 20:43:47 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.5f76b0ddbb36af46ef1385e5afb50df9@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): It appears that since {{{f :: k -> *}}} and {{{g :: * -> k}}} in 7.10's {{{Functor}}} instance, and since the kind of {{{Compose}}} is {{{(k -> *) -> (k1 -> k) -> k1 -> *}}}, it would follow that {{{Compose f g}}} is of kind {{{* -> *}}} (unless I'm reading that wrong). I raised this issue since at the moment, 7.10 can handle certain poly- kinded derived {{{Functor}}} instances (e.g., {{{newtype Alt f a = Alt (f a) deriving Functor}}}), but throwing more than one poly-kinded type constructor into the mix causes things to go haywire. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 20:49:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 20:49:10 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.028029af15b22cec9b005dd7aafe59bf@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by slyfox): Replying to [comment:8 nomeata]: > > Does debian disable dynamic GHC by default as `DYNAMIC_GHC_PROGRAMS = NO`? > > No (`ldd /usr/lib/ghc/bin/ghc` lists various `libHS...` libraries). Do I do something incorrectly? (or the test was on non-powerpc?) {{{ # debootstrap --arch=powerpc --include=ghc unstable . # chroot . # ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 # ldd /usr/lib/ghc/bin/ghc linux-vdso32.so.1 (0x00100000) libtinfo.so.5 => /lib/powerpc-linux-gnu/libtinfo.so.5 (0x0ffaf000) librt.so.1 => /lib/powerpc-linux-gnu/librt.so.1 (0x0ff86000) libutil.so.1 => /lib/powerpc-linux-gnu/libutil.so.1 (0x0ff63000) libdl.so.2 => /lib/powerpc-linux-gnu/libdl.so.2 (0x0ff3f000) libpthread.so.0 => /lib/powerpc-linux-gnu/libpthread.so.0 (0x0ff04000) libgmp.so.10 => /usr/lib/powerpc-linux-gnu/libgmp.so.10 (0x0fe69000) libm.so.6 => /lib/powerpc-linux-gnu/libm.so.6 (0x0fd93000) libffi.so.6 => /usr/lib/powerpc-linux-gnu/libffi.so.6 (0x0fd6a000) libc.so.6 => /lib/powerpc-linux-gnu/libc.so.6 (0x0fbcb000) /lib/ld.so.1 (0x2052a000) # ghc --info | grep -i dyn ,("Support dynamic-too","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") }}} It's not able to handle PIC: {{{ // cat a.c #include void ffi_a_hello (int i) { fprintf (stderr, "WEEEEEEEE: i=%d\n", i); } -- cat A.hs {-# LANGUAGE ForeignFunctionInterface #-} module A where import Foreign.C foreign import ccall "ffi_a_hello" a :: CInt -> IO () # ghc -fPIC -c a.c -fforce-recomp # ghc -fPIC -c A.hs -fforce-recomp # ghci --interactive ./a.o A GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) a.o ... done final link ... done [1 of 1] Compiling A ( A.hs, interpreted ) [flags changed] Ok, modules loaded: A. *A> a 42 Segmentation fault }}} Non-PIC is fine, but it does not contain PLT-style relocations: {{{ # ghc -c a.c -fforce-recomp # ghc -c A.hs -fforce-recomp # ghci --interactive ./a.o A GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) a.o ... done final link ... done [1 of 1] Compiling A ( A.hs, interpreted ) [flags changed] Ok, modules loaded: A. *A> a 42 WEEEEEEEE: i=42 *A> Leaving GHCi. # objdump -d -r a.o | grep PLT # objdump -d -r A.o | grep PLT }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 20:53:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 20:53:55 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.ff09047ff014e5b48e0501f2a13d3c5b@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by nomeata): > Do I do something incorrectly? (or the test was on non-powerpc?) Sorry, was on non-powerpc. I only checked on arm64 and checked that we did not change any settings per architecture here, but it seems that ghc by default builds GHC without dynamic libraries? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 20:57:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 20:57:53 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.d9e7c53496aa8c1d1e559b5880fb6667@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by slyfox): Having written that I wondered who forces '''-fPIC''' on you and the answer is obvious! Rogue package: {{{ $ cabal unpack unix-time Unpacking to unix-time-0.3.5/ $ grep -R -C4 -i fPIC unix-time-0.3.5/ unix-time-0.3.5/unix-time.cabal- if impl(ghc >= 7.8) unix-time-0.3.5/unix-time.cabal: CC-Options: -fPIC }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 21:12:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 21:12:38 -0000 Subject: [GHC] #10521: Wrong results in strict Word8 storage on x64 In-Reply-To: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> References: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> Message-ID: <070.ad3e836efcf6d7eb6befe5d7aac6c77f@haskell.org> #10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: VincentBerthoux2 | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D993 -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D993 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 21:14:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 21:14:39 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.3bcd0e22ec108585d5ce156f90d76df7@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by rwbarton): While it would doubtless be better to build with `-fPIC` only when building a shared library, we ought to support the configuration of unix- time too, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 21:16:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 21:16:15 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.386fa22e0a9b1abc6998f989a9128003@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by slyfox): Replying to [comment:13 nomeata]: > > Do I do something incorrectly? (or the test was on non-powerpc?) > > Sorry, was on non-powerpc. I only checked on arm64 and checked that we did not change any settings per architecture here, but it seems that ghc by default builds GHC without dynamic libraries? Yeah, there is a blacklist of bad platforms: {{{ # apt-get source ghc # grep -A10 NoSharedLibsPlatformList ghc-7.8.4/mk/config.mk.in NoSharedLibsPlatformList = powerpc-unknown-linux \ x86_64-unknown-mingw32 \ i386-unknown-mingw32 \ sparc-sun-solaris2 \ sparc-unknown-linux \ mips-unknown-linux \ mipsel-unknown-linux }}} On 7.10 it does not contain linux targets. I've completely forgot that upstream ghc was released before PPC -fPIC fix went upstream fa31e8f4a0f853848d96549a429083941877bf8d after 7.8.4 release :( You might like to apply this as well 78863edbb0751f5c9694ea10c6132a87cfd0ee10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 21:17:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 21:17:39 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.92721be7f627171f9e4460660aad87c7@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): The instance head `Functor (Compose f g)` is well-kinded, but the context `(Functor f, Functor g)` is not unless `k = *`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 21:35:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 21:35:55 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.9e540949ceae5bcde358924bae8e9834@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by slyfox): Replying to [comment:15 rwbarton]: > While it would doubtless be better to build with `-fPIC` only when building a shared library, we ought to support the configuration of unix- time too, right? Correct. 1. ghc-7.10/HEAD/DYNAMIC_GHC_PROGRAMS=YES on PPC32 fully supports it by using dynamic linker 2. ghc-7.10/HEAD/DYNAMIC_GHC_PROGRAMS=NO on PPC32 does not support it and attached patch needs to be adjusted a bit to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 21:40:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 21:40:25 -0000 Subject: [GHC] #10523: Add Monoid instance for IO In-Reply-To: <049.6279cecb8fcd2b294d6df5d83cd891b5@haskell.org> References: <049.6279cecb8fcd2b294d6df5d83cd891b5@haskell.org> Message-ID: <064.916e84a111acdc5f6ae384739ae9ad49@haskell.org> #10523: Add Monoid instance for IO -------------------------------------+------------------------------------- Reporter: Gabriel439 | Owner: Gabriel439 Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D988 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"65d4b895d8331ff9e7df6aaf0a0de898c857201c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="65d4b895d8331ff9e7df6aaf0a0de898c857201c" Add `Monoid` instance for `IO` See original proposal at https://mail.haskell.org/pipermail/libraries/2014-November/024310.html for more details Reviewed By: hvr, austin Differential Revision: https://phabricator.haskell.org/D988 GHC Trac Issues: #10523 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 21:40:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 21:40:25 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.8b67741c79fddff92608172af19df5d0@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: thomie Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D990 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"f0636562908236f6ce9bf91796bc952534074a61/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f0636562908236f6ce9bf91796bc952534074a61" Fix ghc-pkg reports cache out date (#10205) See Note [writeAtomic leaky abstraction]. GHC on Linux already received a patch for this bug in e0801a0fb342eea9a312906eab72874d631271cf. On Windows several cabal tests were hitting the bug, causing validate failures, but we never noticed because of all the other tests that were failing on Windows. And it didn't start happening till `getModificationTime` received sub-second resolution support on Windows in 5cf76186d373842bf64d49cecb09e0a9ddce3203. Since there are regression tests already, I am not adding another one. But for good measure, here is a script that shows the bug without needing to do a full validate run: DB=/tmp/package.conf.d.test GHC_PKG=ghc-pkg #utils/ghc-pkg/dist/build/tmp/ghc-pkg LOCAL_GHC_PKG="${GHC_PKG} --no-user-package-db --global-package- db=${DB}" while true; do rm -rf ${DB} ${LOCAL_GHC_PKG} init "${DB}" ${LOCAL_GHC_PKG} list done If you see "WARNING: cache is out of date" after a few seconds, the bug is not fixed. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D990 GHC Trac Issues: #10205 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 21:40:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 21:40:25 -0000 Subject: [GHC] #10467: user's guide description of "foreign export" is out of date In-Reply-To: <047.ce62d536f877089b14fe11348144e797@haskell.org> References: <047.ce62d536f877089b14fe11348144e797@haskell.org> Message-ID: <062.f20461f234094020a3039aba093b01dc@haskell.org> #10467: user's guide description of "foreign export" is out of date -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D951 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"0760b84e62d216cbd0ba08a46331bed7c45c88bb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0760b84e62d216cbd0ba08a46331bed7c45c88bb" Update foreign export docs, fixes #10467 Signed-off-by: Edward Z. Yang Reviewed By: rwbarton, austin Differential Revision: https://phabricator.haskell.org/D951 GHC Trac Issues: #10467 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 21:40:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 21:40:25 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.8ffd8f9024de6b06e7a18a1446ca8146@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: enum01.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D957 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"b98ca17e12c7efdc906f4901f25e6263a5399be1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b98ca17e12c7efdc906f4901f25e6263a5399be1" Make enum01/enum02/enum03 tests clang-compatible ... by entirely replacing the use of CPP by a custom preprocessor; clang -E -traditional has no stringification mechanism at all. Reviewed By: thomie, austin Differential Revision: https://phabricator.haskell.org/D957 GHC Trac Issues: #9399 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 21:44:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 21:44:44 -0000 Subject: [GHC] #10534: Data families + Coercible = unsafeCoerce In-Reply-To: <047.8223986df67095beb90c9b80050632fc@haskell.org> References: <047.8223986df67095beb90c9b80050632fc@haskell.org> Message-ID: <062.49510ec7e3f119f40befbcda0c3ae7b1@haskell.org> #10534: Data families + Coercible = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T10534 | Blocking: | Differential Revisions: Phab:D992 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`, thanks Richard! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 21:45:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 21:45:01 -0000 Subject: [GHC] #10521: Wrong results in strict Word8 storage on x64 In-Reply-To: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> References: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> Message-ID: <070.a80fd57e7c1e3aa1f06e3a83020a6fa2@haskell.org> #10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: VincentBerthoux2 | Owner: rwbarton Type: bug | Status: patch Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D993 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 22:48:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 22:48:12 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.02e9bfac1a7f9fab8aae5fb347389486@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): Oh, right. So in both GHC 7.10 and 7.11, the derived kinds for the type variables in {{{(Functor f, Functor g) => Functor (Compose f g)}}} are incorrect, but GHC 7.11 defers the errors until later. In that case, can this can of problem be fixed? Would {{{deriving}}} clauses always be able to infer the correct kinds, or would it be necessary in some cases to specify the kinds in a standalone {{{deriving}}} statement, e.g., {{{#!hs deriving instance (Functor (f :: * -> *), Functor (g :: * -> *)) => Functor (Compose f g) }}} (The kind signatures wouldn't be needed here due to the explicit {{{Functor}}} constraint, but you get the idea.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 16 23:25:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Jun 2015 23:25:51 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.036efb43d908e231e3908a43ffb064ec@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: thomie Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D990 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 00:13:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 00:13:24 -0000 Subject: [GHC] #10367: "ghc: panic! (the 'impossible' happened)" In-Reply-To: <046.238a760b2e418cfdcf3889e9cb306409@haskell.org> References: <046.238a760b2e418cfdcf3889e9cb306409@haskell.org> Message-ID: <061.aa7292200fa66c0345d3cf08eb1186c5@haskell.org> #10367: "ghc: panic! (the 'impossible' happened)" -------------------------------------+------------------------------------- Reporter: bgwines | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.1 Resolution: | Keywords: panic Operating System: MacOS X | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Code Coverage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 00:24:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 00:24:37 -0000 Subject: [GHC] #10504: GHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabled In-Reply-To: <042.80c23fb36e07186e80db084dbbf4d79a@haskell.org> References: <042.80c23fb36e07186e80db084dbbf4d79a@haskell.org> Message-ID: <057.df6ee7f77e5f101e3737e8d43b40146b@haskell.org> #10504: GHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | 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: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Code Coverage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 02:40:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 02:40:57 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.336d198eee20c40959df072f611b042b@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): I think in the worst case we should be able to consider empty types as enums and fix #2578 in a later stage -- e.g. while generating the "table". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 02:59:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 02:59:38 -0000 Subject: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function In-Reply-To: <047.d854a286f40f24efedada1697ad637ee@haskell.org> References: <047.d854a286f40f24efedada1697ad637ee@haskell.org> Message-ID: <062.6a724ec9a198b320b46e2fa9280b8b01@haskell.org> #1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: 4258 | Blocking: Related Tickets: 8326 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by osa1): * cc: omeragacan@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 07:27:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 07:27:01 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.d18dadab9c077515d5ffda963308cdb8@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by jpbernardy): I just read the proposed documentation on Phabricator. There is something that I think is dissatisfying with the implementation. As I understand it, the contract expressed by an empty data type is that there should be no value inhabiting it. So, if a piece of program ever builds one, the blame should be assigned to that piece of code. However, it does not appear that the current implementation does this. Eg: (error "oops" :: Foo) `compare` (error "oops" :: Foo) should fail with "oops", not ?"compare on empty data type Foo" Similarly, a Read instance makes no sense imho. Please, consider forcing the arguments in all these instances, before failing. Finally, I realise that my original report was misleading. I am sorry for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 08:40:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 08:40:50 -0000 Subject: [GHC] #10519: Can't put wildcard behind forall In-Reply-To: <046.25f8a351d42fe346e193d0c867e5e854@haskell.org> References: <046.25f8a351d42fe346e193d0c867e5e854@haskell.org> Message-ID: <061.82265882136cc5b0b980a01659758eb5@haskell.org> #10519: Can't put wildcard behind forall -------------------------------------+------------------------------------- Reporter: yongqli | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D994 -------------------------------------+------------------------------------- Changes (by thomasw): * differential: => Phab:D994 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 10:25:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 10:25:25 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.4823e762e4b84f367f6c0eee7351ff29@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by simonpj): I'm losing the will to live on this one! > Please, consider forcing the arguments in all these instances, before failing. Not necessarily easy, if the argument is `[a]`, say rather than `a`. This is so much a corner case that what osa1 has implemented seems fine to me. On (3) I suppose that either you can make the `TcDeriv` code check for `isEnumerationOrEmpty` (simplest), or fix the table-generation stuff. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 11:34:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 11:34:32 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.d153abce95d02b194921133ef365329d@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by jpbernardy): simonpj: I'm not sure we're talking about the same thing. The whole point of my request was that, for any class C a where all methods have an `a` argument, it is trivial to implement a meaningful instance C Foo for any empty type Foo. In fact, I am guessing that the instance generator for Eq and Ord generate case statements. So, one could just let the normal instance generator run, to get function definitions with empty case statements. I see now that the instance for Read is fine (because failure is the only option), but that is more than I was asking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 11:43:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 11:43:51 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.c215ecf12e3be712c1d17eeb7ea3afe1@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by simonpj): What if the method does not have an `a` argument? `Read` is one example, but there are probably others. `Ix` perhaps. Still, I really don't care myself. What I want is for someone to be able to look in the user manual and correctly predict what derived instance you'll get for an empty data type. If you and osa1 agree, I bet everyone else will too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 13:13:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 13:13:02 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.757fee16a8837d4672456e5bd6c5ca1e@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T10194 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by refold): Apparently this fix means that some programs that compiled with 7.10.1 now fail with 7.10.2. One reported example is `xmonad-contrib`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 13:22:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 13:22:09 -0000 Subject: [GHC] #10537: Parser: commas_tup_tail returns spurious "Missing" value Message-ID: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> #10537: Parser: commas_tup_tail returns spurious "Missing" value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Parsing {{{#!hs {-# LANGUAGE TupleSections #-} baz = (1, "hello", 6.5,,) 'a' (Just ()) }}} Results in the following AST fragment {{{ (L tests/examples/Tuple.hs:3:7-25 (ExplicitTuple [ L tests/examples/Tuple.hs:3:8 (Present (L tests/examples/Tuple.hs:3:8 (HsOverLit (OverLit (HsIntegral [ '1' ] 1) PlaceHolder (HsLit (HsString [] {abstract:FastString})) PlaceHolder)))) , L tests/examples/Tuple.hs:3:11-17 (Present (L tests/examples/Tuple.hs:3:11-17 (HsLit (HsString [ '"' , 'h' , 'e' , 'l' , 'l' , 'o' , '"' ] {abstract:FastString})))) , L tests/examples/Tuple.hs:3:20-22 (Present (L tests/examples/Tuple.hs:3:20-22 (HsOverLit (OverLit (HsFractional (FL [ '6' , '.' , '5' ] (:% 13 2))) PlaceHolder (HsLit (HsString [] {abstract:FastString})) PlaceHolder)))) , L tests/examples/Tuple.hs:3:24 (Missing PlaceHolder) , L tests/examples/Tuple.hs:3:24 (Missing PlaceHolder) ] }}} The final `Missing PlaceHolder` is duplicated -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 13:54:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 13:54:14 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.85bae2e72a86a81a73c1e6819153c471@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): @jpbernardy, I think there are couple of different issues involved here; 1. This patch doesn't change anything about GHC-derived method implementations. Standalone deriving was already generating this code, but the documentation isn't talking about this explicitly. (It's saying "GHC does not restrict the form of the data type. Instead, GHC simply generates the appropriate boilerplate code for the specified class, and typechecks it" https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/deriving.html) Generated methods are always well-typed, and it's using `error` this way. We merely made non-standalone deriving to work similarly on empty data types, which shouldn't be a problem for anyone, IMO. So the thing you're complaining about was already there for a long time now. We just change some things for consistency and document it. (Also, this patch improves the error message which is always good) 2. I feel like if we force arguments, someone will come here and complain about it too. For example, currently this code works fine: `let g = g in g == g` where type of `g` is empty. If we force it in a non-threaded runtime it'd just loop. (I don't fully understand types-as-contract argument, can you point me to some resources about that?) I also don't care myself, but I feel like we should make this working same as standalone deriving, and document how it is working. Changing standalone deriving for empty types can potentially break existing code, so this may be our only option forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 14:11:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 14:11:10 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.70673dbb71043eeba38c9b1c99747ba1@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by jpbernardy): Ok, I am just pointing out that the implementation is weird from my point of view. I don't want to make a big fuss about this, but I feel that it's something that should be considered. I suppose in a few years someone may raise the issue again :) Regarding blame: The point is that if you get a value of an empty type in your context, it is the caller which is to blame. The proper way to report this blame at runtime is force the caller to produce the value, by forcing it. If you raise an exception yourself you get the blame instead, and so it is harder to track which code is really wrong. I think that a good entry point to the concept of blame is "Well-typed programs can't be blamed" http://homepages.inf.ed.ac.uk/wadler/topics/blame.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 14:43:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 14:43:01 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.0caed6be166fd5caac81e01839f855d2@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T10194 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => merge Comment: OK, Ben can you try to merge this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 14:48:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 14:48:13 -0000 Subject: [GHC] #10537: Parser: commas_tup_tail returns spurious "Missing" value In-Reply-To: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> References: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> Message-ID: <059.009daef6d31aaa54728934f5399da171@haskell.org> #10537: Parser: commas_tup_tail returns spurious "Missing" value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): It doesn't look duplicated to me. There are indeed two missing elements in the tuple. Do you have a program that goes wrong? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 15:14:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 15:14:23 -0000 Subject: [GHC] #10537: Parser: commas_tup_tail returns spurious "Missing" value In-Reply-To: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> References: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> Message-ID: <059.12600e7b810f52907141c17a650847a2@haskell.org> #10537: Parser: commas_tup_tail returns spurious "Missing" value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mpickering): I think you're right Simon. There is something wrong with the annotations though, firstly both the Missing elements have the same SrcSpan `L tests/examples/Tuple.hs:3:24`. {{{ ((tests/examples/Tuple.hs:3:8, AnnComma), [tests/examples/Tuple.hs:3:9]), ((tests/examples/Tuple.hs:3:11-17, AnnComma), [tests/examples/Tuple.hs:3:18]), ((tests/examples/Tuple.hs:3:20-22, AnnComma), [tests/examples/Tuple.hs:3:23]), ((tests/examples/Tuple.hs:3:24, AnnComma), [tests/examples/Tuple.hs:3:24]), }}} Here are the relevant annotations. Notice how the first three commas are associated with the preceding item (much like they are for lists) but the last one is associated directly with the `Missing`. As both `Missing`s have the same SrcSpan then this is causing duplicated output in `ghc- exactprint`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 15:45:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 15:45:57 -0000 Subject: [GHC] #10538: Simpilifier produces empty case in core, segfaults at runtime. Message-ID: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> #10538: Simpilifier produces empty case in core, segfaults at runtime. -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In attachment is a cabal project which builds program producing segfault. Bug is affected by inlining, so test had to be split into modules. Otherwise bug did not occur, and NOINLINE pragmas didn't seem to help. Can probably be simplified much more, right now it requires some basic packages. Inspecting the core I've found that code for `r` in `main` ends with empty `case`, but should end with match on Either constructors with `show`. It fails on 7.10.1 and 7.10.2-rc1. Works on 7.8.3. It seems to be affected by inlining. For example inlining validateJson from Validator/Aeson.hs helps. Is also seems to be affected by specializing functions in Main.hs to Indentity monad. For convenience I've also put test case to https://github.com/sopvop/failidator failit.sh will init sandbox, install deps, build executable and run it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 16:02:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 16:02:13 -0000 Subject: [GHC] #10538: Simpilifier produces empty case in core, segfaults at runtime. In-Reply-To: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> References: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> Message-ID: <060.aa6d0f7e197fb1bb8f446312f2753730@haskell.org> #10538: Simpilifier produces empty case in core, segfaults at runtime. -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari * failure: None/Unknown => Runtime crash * priority: normal => high * milestone: => 7.10.2 Comment: Oh dear. This does look like quite a bad regression. Indeed I can reproduce it here. I'll dig in a bit tonight. I'm going to milestone this for 7.10.2 as it's a crash in pure code which worked in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 16:29:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 16:29:30 -0000 Subject: [GHC] #10539: ghc internal error compiling simple template haskell + lens program Message-ID: <049.325e9961b4964885fc9c66aa2a848ba4@haskell.org> #10539: ghc internal error compiling simple template haskell + lens program -------------------------------------+------------------------------------- Reporter: andrew.wja | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: lens | Operating System: Linux template-haskell | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following happens when compiling a piece of Haskell code with GHC 7.10.1 (code at the bottom of this report). Compilation is successful with GHC 7.8.4 -- both using lens-4.11, which makes this seem like a TH issue. {{{#!sh Building language-arithmetic-0.1.0.0... Preprocessing library language-arithmetic-0.1.0.0... [1 of 2] Compiling Language.Arithmetic.Syntax ( src/Language/Arithmetic/Syntax.hs, dist/build/Language/Arithmetic/Syntax.o ) ghc: internal error: stg_ap_v_ret (GHC version 7.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} {{{#!hs module Language.Arithmetic.Syntax where import Control.Applicative hiding (Const) import Control.Lens hiding (Const) import Control.Lens.Plated import Prelude hiding (const) import Data.Data data Arith a b c = Plus { _left :: (Arith a b c), _right :: (Arith a b c) } | Minus { _left :: (Arith a b c), _right :: (Arith a b c) } | Times { _left :: (Arith a b c), _right :: (Arith a b c) } | Divide { _left :: (Arith a b c), _right :: (Arith a b c) } | Modulo { _left :: (Arith a b c), _right :: (Arith a b c) } | Parens { _subexp :: (Arith a b c) } | FunCall{ _name :: String, _subexp :: (Arith a b c) } | Const { _const :: a} | Var { _var :: b } | Embed { _embed :: c } deriving (Show, Eq, Ord, Data, Typeable) makeLenses ''Arith instance Plated (Arith a b c) where plate = uniplate }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 17:04:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 17:04:13 -0000 Subject: [GHC] #10529: hpc: Improve error messages in readMix In-Reply-To: <042.190bab483c0a9360715a797a8a3385e1@haskell.org> References: <042.190bab483c0a9360715a797a8a3385e1@haskell.org> Message-ID: <057.ebdd241c8994d7c085f72a123386f734@haskell.org> #10529: hpc: Improve error messages in readMix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Code Coverage | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nh2): Yes that looks great to me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 17:57:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 17:57:01 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.780a9f4cf914ce1413fcfe69d641a352@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T10194 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): But it's already merged; should we un-merge it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 18:16:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 18:16:56 -0000 Subject: [GHC] #10537: Parser: commas_tup_tail duplicate SrcSpan on "Missing" value (was: Parser: commas_tup_tail returns spurious "Missing" value) In-Reply-To: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> References: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> Message-ID: <059.be573e924930ac08a1509c1a766b45eb@haskell.org> #10537: Parser: commas_tup_tail duplicate SrcSpan on "Missing" value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by alanz: Old description: > Parsing > > {{{#!hs > {-# LANGUAGE TupleSections #-} > > baz = (1, "hello", 6.5,,) 'a' (Just ()) > }}} > > Results in the following AST fragment > > {{{ > (L tests/examples/Tuple.hs:3:7-25 > (ExplicitTuple > [ L tests/examples/Tuple.hs:3:8 > (Present > (L tests/examples/Tuple.hs:3:8 > (HsOverLit > (OverLit > (HsIntegral [ '1' ] 1) > PlaceHolder > (HsLit > (HsString > [] > {abstract:FastString})) > PlaceHolder)))) > , L tests/examples/Tuple.hs:3:11-17 > (Present > (L tests/examples/Tuple.hs:3:11-17 > (HsLit > (HsString > [ '"' > , 'h' > , 'e' > , 'l' > , 'l' > , 'o' > , '"' > ] > {abstract:FastString})))) > , L tests/examples/Tuple.hs:3:20-22 > (Present > (L tests/examples/Tuple.hs:3:20-22 > (HsOverLit > (OverLit > (HsFractional > (FL > [ '6' , '.' , '5' ] > (:% 13 2))) > PlaceHolder > (HsLit > (HsString > [] > {abstract:FastString})) > PlaceHolder)))) > , L tests/examples/Tuple.hs:3:24 > (Missing PlaceHolder) > , L tests/examples/Tuple.hs:3:24 > (Missing PlaceHolder) > ] > }}} > > The final `Missing PlaceHolder` is duplicated New description: Parsing {{{#!hs {-# LANGUAGE TupleSections #-} baz = (1, "hello", 6.5,,) 'a' (Just ()) }}} Results in the following AST fragment {{{ (L tests/examples/Tuple.hs:3:7-25 (ExplicitTuple [ L tests/examples/Tuple.hs:3:8 (Present (L tests/examples/Tuple.hs:3:8 (HsOverLit (OverLit (HsIntegral [ '1' ] 1) PlaceHolder (HsLit (HsString [] {abstract:FastString})) PlaceHolder)))) , L tests/examples/Tuple.hs:3:11-17 (Present (L tests/examples/Tuple.hs:3:11-17 (HsLit (HsString [ '"' , 'h' , 'e' , 'l' , 'l' , 'o' , '"' ] {abstract:FastString})))) , L tests/examples/Tuple.hs:3:20-22 (Present (L tests/examples/Tuple.hs:3:20-22 (HsOverLit (OverLit (HsFractional (FL [ '6' , '.' , '5' ] (:% 13 2))) PlaceHolder (HsLit (HsString [] {abstract:FastString})) PlaceHolder)))) , L tests/examples/Tuple.hs:3:24 (Missing PlaceHolder) , L tests/examples/Tuple.hs:3:24 (Missing PlaceHolder) ] }}} The final `Missing PlaceHolder` has a duplicated SrcSpan -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 18:37:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 18:37:40 -0000 Subject: [GHC] #10538: Simpilifier produces empty case in core, segfaults at runtime. In-Reply-To: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> References: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> Message-ID: <060.467b73b1060d1bfa31e5e469a1308ef4@haskell.org> #10538: Simpilifier produces empty case in core, segfaults at runtime. -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-e): Sorry, I meant to add a description to that file: It reproduces the same bug with a bit less code and a single file (note the strategically placed `NOINLINE`). Interestingly, the `Applicative` constraint on `reqField` is essential. I've looked a bit at the resulting traces, but I'm not sure what to look for. Here are two excerpts that I found interesting: http://lpaste.net/raw/2270642354903842816 looks like an inlining step going horribly wrong, and http://lpaste.net/6349604574378065920 shows how the odd duplicated `a1_X9lA` is introduced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 19:00:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 19:00:35 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.f218825ef978220814638a3769e43084@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T10194 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by adamgundry): @refold can you be more specific about what breaks? One would expect some programs that were previously (erroneously) accepted to now require `-XImpredicativeTypes`. That's not necessarily a reason to revert this patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 19:18:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 19:18:12 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.aaa5be5309c8f1ef1199fd24da9519c8@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T10194 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by refold): Replying to [comment:10 adamgundry]: > One would expect some programs that were previously (erroneously) accepted to now require `-XImpredicativeTypes`. Yes, that's what seems to happen in the `xmonad-contrib` case: {{{ XMonad/Layout/Groups/Helpers.hs:181:8: Cannot instantiate unification variable `a0' with a type involving foralls: G.ModifySpec Perhaps you want ImpredicativeTypes In the expression: sendMessage . G.Modify In an equation for `wrap': wrap = sendMessage . G.Modify XMonad/Layout/Groups/Helpers.hs:181:22: Cannot instantiate unification variable `a0' with a type involving foralls: G.ModifySpec Perhaps you want ImpredicativeTypes In the second argument of `(.)', namely `G.Modify' In the expression: sendMessage . G.Modify }}} > That's not necessarily a reason to revert this patch. The issue doesn't affect me personally, so I'm not going to argue. My comment was JFYI. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 19:35:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 19:35:17 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.4c574dd3d6bf3d6a30daf9fcd34feee0@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T10194 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by adamgundry): Thanks! Indeed, those look like impredicative instantiations of `(.)` that should require `ImpredicativeTypes`. I think we should keep the patch, and flag up this issue in the release notes, although the error message makes it fairly obvious how to fix the problem. :-) Or should we be more concerned about maintaining support for existing programs, given that this is a bugfix release? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 20:17:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 20:17:56 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.dfe1c510c1a4cea86687fade1121412d@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T10194 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Well this _is_ a bugfix! It's just that fixing the bug makes some programs be rejected that should be rejected. I propose that we keep it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 20:19:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 20:19:04 -0000 Subject: [GHC] #10539: ghc internal error compiling simple template haskell + lens program In-Reply-To: <049.325e9961b4964885fc9c66aa2a848ba4@haskell.org> References: <049.325e9961b4964885fc9c66aa2a848ba4@haskell.org> Message-ID: <064.07ce90dc6aa4b6aca632cca7c274f63c@haskell.org> #10539: ghc internal error compiling simple template haskell + lens program -------------------------------------+------------------------------------- Reporter: andrew.wja | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: lens Operating System: Linux | template-haskell Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Can others reproduce this? Please use `-dcore-lint`. Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 21:07:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 21:07:24 -0000 Subject: [GHC] #10537: Parser: commas_tup_tail duplicate SrcSpan on "Missing" value In-Reply-To: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> References: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> Message-ID: <059.b88378048fe67d3306e064ab13618600@haskell.org> #10537: Parser: commas_tup_tail duplicate SrcSpan on "Missing" value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 21:08:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 21:08:29 -0000 Subject: [GHC] #10537: Parser: commas_tup_tail duplicate SrcSpan on "Missing" value In-Reply-To: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> References: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> Message-ID: <059.d3663df87b4952c51bd086057459abce@haskell.org> #10537: Parser: commas_tup_tail duplicate SrcSpan on "Missing" value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D995 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D995 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 21:43:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 21:43:32 -0000 Subject: [GHC] #10131: improve error message for build on noexec-mounted device In-Reply-To: <048.a5bb5888aa48566235342f4aa1be6ede@haskell.org> References: <048.a5bb5888aa48566235342f4aa1be6ede@haskell.org> Message-ID: <063.b5e9937d959cb5717f9b515e461c5b56@haskell.org> #10131: improve error message for build on noexec-mounted device -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: That message is coming from your OS (or maybe the linker, I'm not sure). Not from GHC. vector uses some fancy GHC optimization which requires loading a module using the GHCi machinery, which by default means loading its dependencies as shared libraries. And loading a shared library from a noexec mounted disk is not permitted. I made a pull request to let vector not use GHCi during compilation, which would have prevented your issue (at least `cabal install vector` on noexec mounted drive works now): https://github.com/haskell/vector/pull/83 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 21:49:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 21:49:10 -0000 Subject: [GHC] #10131: improve error message for build on noexec-mounted device In-Reply-To: <048.a5bb5888aa48566235342f4aa1be6ede@haskell.org> References: <048.a5bb5888aa48566235342f4aa1be6ede@haskell.org> Message-ID: <063.5c90ec649c4755e3f29b2836d8cdc99a@haskell.org> #10131: improve error message for build on noexec-mounted device -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by lspitzner): hmm ok; thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 21:50:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 21:50:27 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.7799f161cebf91e5ab6f9e2598eb833b@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T10194 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > Or should we be more concerned about maintaining support for existing programs, given that this is a bugfix release? As a user, I would be upset if a bugfix release of a compiler suddenly stops compiling programs that it was compiling previously (unless the compilation was producing bogus results before, but that is not the case here, I believe). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 22:52:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 22:52:41 -0000 Subject: [GHC] #10540: Showing type synonym isn't exported by Hoopl Message-ID: <045.568b20c4b6f46120dd716a4e54f79d74@haskell.org> #10540: Showing type synonym isn't exported by Hoopl -------------------------------------+------------------------------------- Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/hoopl | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: | warning at compile-time Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hoopl exports {{{#!hs showGraph :: Showing n -> Graph n e x -> String }}} But it doesn't export `Showing`. This doesn't make sense, as it's a user- supplied function. So to know what I should pass to `showGraph` I can only look at the source. `:i Showing` doesn't work. Below is a patch to export the innocent type synonym: {{{#!patch diff --git a/src/Compiler/Hoopl/Show.hs b/src/Compiler/Hoopl/Show.hs index 8a8b35f..66172b0 100644 --- a/src/Compiler/Hoopl/Show.hs +++ b/src/Compiler/Hoopl/Show.hs @@ -4,7 +4,7 @@ #endif module Compiler.Hoopl.Show - ( showGraph, showFactBase + ( showGraph, showFactBase, Showing ) where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 23:25:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 23:25:49 -0000 Subject: [GHC] #10538: Simpilifier produces empty case in core, segfaults at runtime. In-Reply-To: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> References: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> Message-ID: <060.9dd50ad89e1d6ec00d3f8cf2602bcab4@haskell.org> #10538: Simpilifier produces empty case in core, segfaults at runtime. -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Ah! I have nailed this. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 17 23:40:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Jun 2015 23:40:50 -0000 Subject: [GHC] #10538: Simpilifier produces empty case in core, segfaults at runtime. In-Reply-To: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> References: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> Message-ID: <060.367d53185a963d379afaea52b7698b19@haskell.org> #10538: Simpilifier produces empty case in core, segfaults at runtime. -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): This is very good news as the Rackspace machine that I was using to bisect this just inexplicably vanished, along with my bisection state. Thanks Simon! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 00:56:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 00:56:37 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.bb48faa84a11322e0fc78402d417be4c@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T10194 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Though I am not at all affected by this, I agree with Joachim (nomeata). I think this sort of wibble in a patch release just makes users groan, and for no great reason beyond pedantry. (I'm not using ''pedantry'' negatively there, as doing so would be quite hypocritical, but that really is the only reason for this change.) I propose unmerging but surely keeping the fix in master. It ''is'' a bugfix, but just not one that needs to be released at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 01:11:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 01:11:15 -0000 Subject: [GHC] #10541: Expose kind information for type variables with reify Message-ID: <045.f61f8e7682823a4edaec414f800b149e@haskell.org> #10541: Expose kind information for type variables with reify -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The comment on [https://hackage.haskell.org/package/template- haskell-2.10.0.0/docs/Language-Haskell-TH-Syntax.html#v:TyVarI TyVarI] notes that the attached Type is always {{{VarT theName}}}, and that this could potentially be extended. Currently, there isn't a way to access kind information for a type variable through the Template Haskell API. It would be useful (at least for me) to have this ability here. The limitation on the returned Type comes from the [https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcSplice.hs#L1060 ATyVar clause of reifyThing], which zonks the TyVar to a GHC type and then uses reifyType to convert it to a TH type. For a TyVarTy, [https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcSplice.hs#L1281 reifyType] always returns {{{VarT theName}}}. I can see a few possible ways of exposing kind information here: (a) Fill the Type argument to TyVarI with {{{SigT (VarT theName) theKind}}}. This could be done either as a special case in place of the call to reifyType in reifyThing, or as a modification to reifyType's behavior. The question of when SigT should be included is open: all the time? when the kind isn't {{{*}}}? when the kind is something that involves more than {{{*}}} and {{{->}}}? (b) Change TyVarI from {{{TyVarI Name Type}}} to {{{TyVarI Name TyVarBndr}}}. This seems like the most straightforward, stable way of exposing kind information, but it requires a breaking API change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 02:15:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 02:15:54 -0000 Subject: [GHC] #10541: Expose kind information for type variables with reify In-Reply-To: <045.f61f8e7682823a4edaec414f800b149e@haskell.org> References: <045.f61f8e7682823a4edaec414f800b149e@haskell.org> Message-ID: <060.f89bb0a9dae4493562dfe5f0cbabad5d@haskell.org> #10541: Expose kind information for type variables with reify -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Could you post your use-case? One thing I'm worried about here is the possibility that the result of a TH splice could affect a type variable's kind. For example: {{{ foo :: forall a. Proxy a -> $( ... ) }}} where the splice produces `a -> a`. If the code running in the splice needs the kind of `a`, we have a loop. Unless I'm missing something... which is entirely possible, as something smells wrong to me in my comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 03:04:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 03:04:21 -0000 Subject: [GHC] #10541: Expose kind information for type variables with reify In-Reply-To: <045.f61f8e7682823a4edaec414f800b149e@haskell.org> References: <045.f61f8e7682823a4edaec414f800b149e@haskell.org> Message-ID: <060.bef96ee6e4274ab9aa6acc0bfcbdc72b@haskell.org> #10541: Expose kind information for type variables with reify -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): That sounds right to me. If the splice produced {{{a b c}}} then that would change the kind. My use case is reading the kind in type synonyms with explicit kind signatures on certain type variables. What about possibility (b), with {{{KindedTV}}} where the kind is known and {{{PlainTV}}} where it isn't set? Or perhaps an additional {{{Maybe Kind}}} on {{{TyVarI}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 03:06:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 03:06:33 -0000 Subject: [GHC] #10541: Expose kind information for type variables with reify In-Reply-To: <045.f61f8e7682823a4edaec414f800b149e@haskell.org> References: <045.f61f8e7682823a4edaec414f800b149e@haskell.org> Message-ID: <060.05909cef3d4409fcb9b3ad49a00c053c@haskell.org> #10541: Expose kind information for type variables with reify -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): The {{{KindedTV}}}/{{{PlainTV}}} solution matches up with {{{ForallTy}}}? which seems appropriate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 07:30:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 07:30:47 -0000 Subject: [GHC] #10542: Incorrect Unicode input on Windows Console Message-ID: <045.3387c3cc5f6c1e19d58646a0ead1675d@haskell.org> #10542: Incorrect Unicode input on Windows Console -------------------------------------+------------------------------------- Reporter: ptroev | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Keywords: windows | Operating System: Windows stdin utf-8 cmd chcp 65001 | Type of failure: Incorrect result getLine | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: 4471 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- To reproduce: - start a windows console - change the console's font to a ttf unicode font, like "Lucida Console". - type "chcp 65001" to set it to the UTF-8 code page. - start ghci (same error appears when running compiled executable) - > import System.IO (or GHC.IO.Handle) - > enc <- mkTextEncoding "UTF8" - > hSetEncoding stdin enc - > getLine - > ?????? (or any international unicode sequence) *** Exception: : hGetLine: end of file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 07:57:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 07:57:52 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.f51f2b6d6328dd18470fef0ff0e29380@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T10194 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest Comment: OK fair enough. Un-merging is fine with me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 10:35:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 10:35:54 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.21ae58cd4ac669c8a421757123a01c8c@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): George, if I understand correctly you were able to compile `Slice.hs` with GHC 7.10.1 if passed `-fsimpl-tick-factor=150`. Is this correct? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 10:50:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 10:50:12 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.1c9a9c2aa778cd523840e36542d5ecc1@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): For the record, my notes on this bug can be found here, https://github.com/bgamari/ghc-T10491/blob/master/notes.mkd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 10:59:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 10:59:11 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.c5615f3e85bed5c0f65178301c3cc7ce@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): Replying to [comment:14 bgamari]: I was able to compile it with -fsimpl-tick-factor=150, not sure if memory use was reasonable, cpu usage was close to 100%. As I wrote above: when I do ghc -O2 -fsimpl-tick-factor=150 Slice.hs it quickly uses over 11G of memory. I'm not sure what the peak memory use is or how long it took to compile as I let it run overnight (I have 12G of RAM on my Mac). The resulting binary of the 321 line source file is 51 MB -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 11:22:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 11:22:31 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.85255113a13310d683ac4bab62c1e69c@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:16 George]: > > I was able to compile it with -fsimpl-tick-factor=150, not sure if memory use was reasonable, cpu usage was close to 100%. As I wrote above: > > when I do > > ghc -O2 -fsimpl-tick-factor=150 Slice.hs > > it quickly uses over 11G of memory. I'm not sure what the peak memory use is or how long it took to compile as I let it run overnight (I have 12G of RAM on my Mac). The resulting binary of the 321 line source file is 51 MB What I'm a bit unclear on is that the bug description seems to suggest this behavior began at some point since the release of 7.10.1, > This has only happened since the release of 7.10.1 and it appears to still be happening in the ghc-7.10 branch. However I am finding that the commits prior to the 7.10.1 release also exhibit the behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 11:33:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 11:33:57 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.7872948c7e82c62dd913f47aa62dbb9a@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by robertce): Replying to [comment:17 bgamari]: > What I'm a bit unclear on is that the bug description seems to suggest this behavior began at some point since the release of 7.10.1, > > > This has only happened since the release of 7.10.1 and it appears to still be happening in the ghc-7.10 branch. > > However I am finding that the commits prior to the 7.10.1 release also exhibit the behavior. I'm not surprised it's also happening with commits prior to 7.10.1. By saying it's only happened since the release of 7.10.1, I was speaking in release terms. It works with 7.8.4, but not 7.10.1 or the current 7.10 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 11:35:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 11:35:08 -0000 Subject: [GHC] #10504: GHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabled In-Reply-To: <042.80c23fb36e07186e80db084dbbf4d79a@haskell.org> References: <042.80c23fb36e07186e80db084dbbf4d79a@haskell.org> Message-ID: <057.339f18bed08a314cc8aabdca685a91a7@haskell.org> #10504: GHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nh2): Some more info, contributed by a colleague: In the minimal example provided: {{{ ghc --show-iface A.hi ... ef7b9ac4dd27cad757d7fad8ecd0592a myfun :: a {- Strictness: b, Inline: INLINABLE[ALWAYS] -} # actual end of file }}} The myfun function doesn't actually have an unfolding in the .hi interface file (there's no "Unfolding: ..." line). The seeming inconsistency with an import being marked INLINABLE but not having an unfolding is the root cause of the bug (see https://github.com/ghc/ghc/blob/45d9a15c4b85a2ed89579106bdafd84accf2cb39/compiler/deSugar/DsBinds.hs#L479). The hyper-strictness (ie ?Strictness: b?, b for bottom a la undefined) is probably why the unfolding isn't retained in this minimal example. Anothere example of when the unfolding isn't retained is if you use `-fomit-inerface-pragmas`. My colleague's conclusion: These are two ways to trigger the same bug: GHC should not crash on a SPECIALIZE for an imported function that has no unfolding, regardless of why it has no unfolding. It would always be better to warn about the missing unfolding/useless SPECIALISE pragma and then ignore the SPECIALISE. Perhaps GHC should also warn about marking a hyperstrict definition as INLINABLE. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 11:46:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 11:46:34 -0000 Subject: [GHC] #10541: Expose kind information for type variables with reify In-Reply-To: <045.f61f8e7682823a4edaec414f800b149e@haskell.org> References: <045.f61f8e7682823a4edaec414f800b149e@haskell.org> Message-ID: <060.86e888bae06f2e81edba2f2768feb91c@haskell.org> #10541: Expose kind information for type variables with reify -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I think we can actually do a bit better. It should be possible to tell whether we fully know a type variable's kind, by looking through the (zonked) kind for any `MetaTv`s. If there aren't any, then the kind is fully known and can be reported. Otherwise, don't report. The problem with my approach here is that it's fragile, depending delicately on the order that GHC reads through a type. Perhaps your solution is better: report the kind only when it is robustly known, either through a kind annotation or other means. (For "other means", I mean, for example, when a type variable is in scope in a term, via !ScopedTypeVariables. These type variables are generally fully known.) But how do we know when the tyvar's kind is robustly known... or even just annotated? By the time `reify` is called, we've lost a lot of that information. There's ''something'' we can do for you in this space, but I'm not sure exactly what yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 11:47:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 11:47:32 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.261586ed21b58314eba409f96aba3017@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:18 robertce]: > I'm not surprised it's also happening with commits prior to 7.10.1. By saying it's only happened since the release of 7.10.1, I was speaking in release terms. It works with 7.8.4, but not 7.10.1 or the current 7.10 branch. Ahh, I see. English can be a frustratingly ambiguous language at times. In other news, it appears that 7.10's behavior begins to diverge from that of 7.8.3 at float out, * after the initial simplifier phase both 7.8 and 7.10 have roughly 3000 terms, 7000 types * after float out the program has 3000 terms, 8000 types in 7.8 whereas it has 12000 terms and 60000 types in 029a296a770addbd096bbfd6de0936327ee620d4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 13:14:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 13:14:47 -0000 Subject: [GHC] #10538: Simpilifier produces empty case in core, segfaults at runtime. In-Reply-To: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> References: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> Message-ID: <060.88d5762f34709cc25c9f85df3ab24c14@haskell.org> #10538: Simpilifier produces empty case in core, segfaults at runtime. -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"023a0ba938b69bbb89cb2ce48a07459b07783391/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="023a0ba938b69bbb89cb2ce48a07459b07783391" Care with impossible-cons in combineIdenticalAlts This was a nasty, long-standing bug exposed in Trac #10538. Symptoms were that we had an empty case case (x :: Either a) of {} Core Lint correctly picked this bogus code up. Here is what happened * In SimplUtils.prepareAlts, we call filterAlts then combineIdenticalAlts * We had case x of { Left _ -> e1; Right _ -> e1 } * filterAlts did nothing, but correctly retuned imposs_deflt_cons saying that 'x' cannot be {Left, Right} in the DEFAULT branch, if any (there isn't one.) * combineIdentialAlts correctly combines the identical alts, to give case x of { DEFAULT -> e1 } * BUT combineIdenticalAlts did no adjust imposs_deft_cons * Result: when compiling e1 we did so in the belief that 'x' could not be {Left,Right}. Disaster. Easily fixed. (It is hard to trigger; I can't construct a simple test case.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 13:14:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 13:14:47 -0000 Subject: [GHC] #10516: PolyKinds results in incorrect reporting of type synonym parameter count In-Reply-To: <055.bec1f97d6a44e1f3f7ecb1a59b83df87@haskell.org> References: <055.bec1f97d6a44e1f3f7ecb1a59b83df87@haskell.org> Message-ID: <070.748dc35eb20c7898c128490a874a4795@haskell.org> #10516: PolyKinds results in incorrect reporting of type synonym parameter count -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5879d5aab929e9959d48e03dad456b824160b3bf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5879d5aab929e9959d48e03dad456b824160b3bf" Report arity errors correctly despite kinds Trac #10516 pointed out that when reporting arity errors (like "T needs 2 arguments but has been given 1"), we should not count kind arguments, since they are implicit. If we include kind args in the count, we get very confusing error messages indeed. I did a little bit of refactoring which make some error messages wobble around. But the payload of this fix is in TcValidity.tyConArityErr }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 13:20:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 13:20:25 -0000 Subject: [GHC] #10516: PolyKinds results in incorrect reporting of type synonym parameter count In-Reply-To: <055.bec1f97d6a44e1f3f7ecb1a59b83df87@haskell.org> References: <055.bec1f97d6a44e1f3f7ecb1a59b83df87@haskell.org> Message-ID: <070.66000f945e3cc6e4a46cc13723ce0609@haskell.org> #10516: PolyKinds results in incorrect reporting of type synonym parameter count -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: Related Tickets: | polykinds/T10516 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high * status: new => merge * testcase: => polykinds/T10516 * milestone: => 7.10.3 Comment: I believe I have fixed this. Could merge to the branch if convenient. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 14:18:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 14:18:06 -0000 Subject: [GHC] #4945: Another SpecConstr infelicity In-Reply-To: <053.dd99f570cc6450886c16aa213467aa21@haskell.org> References: <053.dd99f570cc6450886c16aa213467aa21@haskell.org> Message-ID: <068.349eef37b05b5ce18e1f8a61abc1b851@haskell.org> #4945: Another SpecConstr infelicity -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | simplCore/should_compile/T4945 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5d98b6828f65ce6eea45e93880928b7031955d38/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5d98b6828f65ce6eea45e93880928b7031955d38" Trac #4945 is working again This test greps in the ouput of -ddump-simpl, so it's fragile. It stopped working for a while, but now works again. I don't know why, but I don't have time to investigate, so I'll just mark it as ok. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 14:19:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 14:19:27 -0000 Subject: [GHC] #10537: Parser: commas_tup_tail duplicate SrcSpan on "Missing" value In-Reply-To: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> References: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> Message-ID: <059.ae0a63ed024c9273c5749693eb6e2bd4@haskell.org> #10537: Parser: commas_tup_tail duplicate SrcSpan on "Missing" value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D995 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"72b21c393831b49867a296f19a2d039e48bb8dcd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="72b21c393831b49867a296f19a2d039e48bb8dcd" Parser: commas_tup_tail duplicate SrcSpan on "Missing" value Summary: Parsing {-# LANGUAGE TupleSections #-} baz = (1, "hello", 6.5,,) 'a' (Just ()) Results in the following AST fragment (L tests/examples/Tuple.hs:3:7-25 (ExplicitTuple [ L tests/examples/Tuple.hs:3:8 (Present (L tests/examples/Tuple.hs:3:8 (HsOverLit (OverLit (HsIntegral [ '1' ] 1) PlaceHolder (HsLit (HsString [] {abstract:FastString})) PlaceHolder)))) , L tests/examples/Tuple.hs:3:11-17 (Present (L tests/examples/Tuple.hs:3:11-17 (HsLit (HsString [ '"' , 'h' , 'e' , 'l' , 'l' , 'o' , '"' ] {abstract:FastString})))) , L tests/examples/Tuple.hs:3:20-22 (Present (L tests/examples/Tuple.hs:3:20-22 (HsOverLit (OverLit (HsFractional (FL [ '6' , '.' , '5' ] (:% 13 2))) PlaceHolder (HsLit (HsString [] {abstract:FastString})) PlaceHolder)))) , L tests/examples/Tuple.hs:3:24 (Missing PlaceHolder) , L tests/examples/Tuple.hs:3:24 (Missing PlaceHolder) ] The final `Missing PlaceHolder` has a duplicated `SrcSpan` Test Plan: ./validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie, bgamari, mpickering Differential Revision: https://phabricator.haskell.org/D995 GHC Trac Issues: #10537 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 14:19:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 14:19:27 -0000 Subject: [GHC] #4945: Another SpecConstr infelicity In-Reply-To: <053.dd99f570cc6450886c16aa213467aa21@haskell.org> References: <053.dd99f570cc6450886c16aa213467aa21@haskell.org> Message-ID: <068.420686e205fcf3a21a0ec4d857efdd4a@haskell.org> #4945: Another SpecConstr infelicity -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | simplCore/should_compile/T4945 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I'm closing this again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 14:21:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 14:21:06 -0000 Subject: [GHC] #10533: Assertion failure on FD3 test in TcErrors In-Reply-To: <047.47efed1788c080f7defb630451503765@haskell.org> References: <047.47efed1788c080f7defb630451503765@haskell.org> Message-ID: <062.219d6c0b488f9c2d6b82f4aed550423a@haskell.org> #10533: Assertion failure on FD3 test in TcErrors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I looked at this and fixed it, but failed to make a separate patch. I think it is somewhere in {{{ commit 02bac0254182def11029e2f7373ba8d2ba9ebe44 Author: Simon Peyton Jones Date: Thu Jun 18 14:12:54 2015 +0100 Remove some horrible munging of origins for Coercible I just didn't think it was buying enough for all the cruft it caused. We can put some back if people start complaining about poor error messages. I forget quite how I tripped over this but I got sucked in. * Lots of tidying up in TcErrors * Rename pprArisingAt to pprCtLoc, by analogy with pprCtOrigin * Remove CoercibleOrigin data constructor from CtOrigin * Make relevantBindings return a Ct with a zonked and tidied CtOrigin * Add to TcRnTypes ctOrigin :: Ct -> CtOrigin ctEvOrigin :: CtEvidence -> CtOrigin setCtLoc :: Ct -> CtLoc -> Ct }}} But in any case it doesn't matter much. No need to merge etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 14:22:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 14:22:23 -0000 Subject: [GHC] #10538: Simpilifier produces empty case in core, segfaults at runtime. In-Reply-To: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> References: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> Message-ID: <060.81bad71ec4048e1befc0f64988bcbdc5@haskell.org> #10538: Simpilifier produces empty case in core, segfaults at runtime. -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * priority: high => highest * status: new => merge Comment: Let's merge this to 7.10.2 if possible. It is a hard error. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 14:27:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 14:27:08 -0000 Subject: [GHC] #10507: Looping with type level naturals In-Reply-To: <047.5fd95e048f3c3bca89022fe8d424335a@haskell.org> References: <047.5fd95e048f3c3bca89022fe8d424335a@haskell.org> Message-ID: <062.5a2e0d3c5f2ffc9ef3e1de49f489bffe@haskell.org> #10507: Looping with type level naturals -------------------------------------+------------------------------------- Reporter: jhendrix | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.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 Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 7.12.1 Comment: Sadly the fix in HEAD does not apply straightforwardly to 7.10. I'm a bit reluctant to do a separate fix for 7.10. Is this a show-stopper for you, or can we leave it for 7.12? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 14:45:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 14:45:20 -0000 Subject: [GHC] #10503: The impossible happened (no skolem info) - untouchable kind variable In-Reply-To: <052.5d02a2c16ec59101e0384598dc01335f@haskell.org> References: <052.5d02a2c16ec59101e0384598dc01335f@haskell.org> Message-ID: <067.124bf36f216cd3b01e7f26a154c6d474@haskell.org> #10503: The impossible happened (no skolem info) - untouchable kind variable -------------------------------------+------------------------------------- Reporter: AlekseyKliger | Owner: Type: bug | Status: new 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ba7c8e5919411f84bdc84caa60317b0cb6c5cdc5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ba7c8e5919411f84bdc84caa60317b0cb6c5cdc5" Test Trac #10503 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 14:45:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 14:45:55 -0000 Subject: [GHC] #10503: The impossible happened (no skolem info) - untouchable kind variable In-Reply-To: <052.5d02a2c16ec59101e0384598dc01335f@haskell.org> References: <052.5d02a2c16ec59101e0384598dc01335f@haskell.org> Message-ID: <067.acc38b910be09469d2ff9a4d68f442be@haskell.org> #10503: The impossible happened (no skolem info) - untouchable kind variable -------------------------------------+------------------------------------- Reporter: AlekseyKliger | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | polykinds/T10503 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T10503 * resolution: => fixed Comment: Well this too is fixed in HEAD, but I'm not sure when. It's only a crash when displaying an error message, so I propose not to fix separately in 7.10. Yell if that's a problem. I'll add it as a regression test though, thank you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 14:47:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 14:47:29 -0000 Subject: [GHC] #8353: Easy way to defer type errors In-Reply-To: <047.34842edf8c636f9b11361128b151d960@haskell.org> References: <047.34842edf8c636f9b11361128b151d960@haskell.org> Message-ID: <062.54473f30896db12ec5af52595bbae917@haskell.org> #8353: Easy way to defer type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D960 -------------------------------------+------------------------------------- Comment (by simonpj): It'd be good to get this one finished. I have no strong feelings. The user manual should document whatever happens though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 15:35:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 15:35:11 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.3591caf6977de0e1319bf443636a50ef@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T10194 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * milestone: 7.10.2 => 7.12.1 Comment: Reverted in 8fb101e49b86c0f8bb8931620c9c3cd3e6c57228 on `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 15:35:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 15:35:20 -0000 Subject: [GHC] #10538: Simpilifier produces empty case in core, segfaults at runtime. In-Reply-To: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> References: <045.19e9a265279566c63d9130f6da1babb4@haskell.org> Message-ID: <060.f5957a5e26c5a8c109cebf484b14cc71@haskell.org> #10538: Simpilifier produces empty case in core, segfaults at runtime. -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 15:35:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 15:35:27 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.15bae22072f0fd254659c2483d9c6e4a@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D990 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 16:31:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 16:31:10 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.2b1fffb5eaa7b8ce9018a265b3ac7c1a@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I've just compiled `Slice.hs` with HEAD quite easily {{{ bash$ ghc-stage2 -dshow-passes Slice.hs -package accelerate -O2 -fforce- recomp .... 4,168,610,960 bytes allocated in the heap 973,775,616 bytes copied during GC 67,207,400 bytes maximum residency (14 sample(s)) 2,684,880 bytes maximum slop 185 MB total memory in use (0 MB lost due to fragmentation) }}} The program never ets vast {{{ [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, Slice.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 2,214, types: 3,698, coercions: 26} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 2,183, types: 3,841, coercions: 20} Result size of Simplifier iteration=2 = {terms: 2,182, types: 3,835, coercions: 20} Result size of Simplifier = {terms: 2,182, types: 3,835, coercions: 20} *** Specialise: Result size of Specialise = {terms: 6,196, types: 26,056, coercions: 470} *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 7,738, types: 35,962, coercions: 470} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 9,756, types: 45,944, coercions: 10,471} Result size of Simplifier iteration=2 = {terms: 10,295, types: 49,489, coercions: 21,914} Result size of Simplifier iteration=3 = {terms: 9,724, types: 46,649, coercions: 14,825} Result size of Simplifier iteration=4 = {terms: 9,694, types: 46,444, coercions: 14,376} Result size of Simplifier = {terms: 9,694, types: 46,444, coercions: 14,376} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 9,301, types: 45,776, coercions: 13,996} Result size of Simplifier iteration=2 = {terms: 9,267, types: 45,696, coercions: 13,846} Result size of Simplifier iteration=3 = {terms: 9,268, types: 45,686, coercions: 13,744} Result size of Simplifier iteration=4 = {terms: 9,268, types: 45,681, coercions: 13,682} Result size of Simplifier = {terms: 9,268, types: 45,681, coercions: 13,682} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 21,154, types: 76,735, coercions: 30,042} Result size of Simplifier iteration=2 = {terms: 18,674, types: 69,540, coercions: 22,805} Result size of Simplifier iteration=3 = {terms: 18,479, types: 67,598, coercions: 19,578} Result size of Simplifier iteration=4 = {terms: 17,773, types: 64,887, coercions: 16,920} Result size of Simplifier = {terms: 17,773, types: 64,887, coercions: 16,920} *** Float inwards: Result size of Float inwards = {terms: 17,773, types: 64,887, coercions: 16,920} *** Called arity analysis: Result size of Called arity analysis = {terms: 17,773, types: 64,887, coercions: 16,920} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 17,458, types: 63,723, coercions: 15,764} Result size of Simplifier iteration=2 = {terms: 17,528, types: 63,751, coercions: 15,458} Result size of Simplifier iteration=3 = {terms: 17,560, types: 63,758, coercions: 15,272} Result size of Simplifier iteration=4 = {terms: 17,551, types: 63,748, coercions: 15,182} Result size of Simplifier = {terms: 17,551, types: 63,748, coercions: 15,182} *** Demand analysis: Result size of Demand analysis = {terms: 17,551, types: 63,748, coercions: 15,182} *** Worker Wrapper binds: Result size of Worker Wrapper binds = {terms: 21,047, types: 77,338, coercions: 15,182} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 19,533, types: 69,686, coercions: 15,210} Result size of Simplifier iteration=2 = {terms: 18,528, types: 67,708, coercions: 15,346} Result size of Simplifier iteration=3 = {terms: 18,293, types: 67,029, coercions: 15,164} Result size of Simplifier = {terms: 18,293, types: 67,029, coercions: 15,164} *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) = {terms: 19,134, types: 72,375, coercions: 15,164} *** Common sub-expression: Result size of Common sub-expression = {terms: 17,353, types: 61,395, coercions: 5,875} *** Float inwards: Result size of Float inwards = {terms: 17,353, types: 61,395, coercions: 5,875} *** Liberate case: Result size of Liberate case = {terms: 17,353, types: 61,395, coercions: 5,875} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 15,872, types: 53,291, coercions: 6,049} Result size of Simplifier = {terms: 15,745, types: 52,388, coercions: 5,875} *** SpecConstr: Result size of SpecConstr = {terms: 16,083, types: 52,968, coercions: 5,875} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 16,074, types: 52,968, coercions: 5,875} Result size of Simplifier iteration=2 = {terms: 16,075, types: 53,003, coercions: 5,875} Result size of Simplifier = {terms: 16,075, types: 53,003, coercions: 5,875} *** Tidy Core: Result size of Tidy Core = {terms: 10,807, types: 36,367, coercions: 5,684} *** CorePrep: Result size of CorePrep = {terms: 13,102, types: 39,418, coercions: 5,688} *** Stg2Stg: *** CodeGen: *** Assembler: }}} The -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 20:05:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 20:05:11 -0000 Subject: [GHC] #10348: HEAD: `KnownNat` does not imply `Typeable` any more In-Reply-To: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> References: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> Message-ID: <063.9a65687dc8afe7012794d5c8f07a5668@haskell.org> #10348: HEAD: `KnownNat` does not imply `Typeable` any more -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: diatchki Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Iavor says he'll do this over the weekend. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 22:26:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 22:26:41 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.5898977de209bd3c015166c002e5c722@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c45f8ceb0de0f83d374909f4cb8dd411154e2bce/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c45f8ceb0de0f83d374909f4cb8dd411154e2bce" Elaborate test for Trac #10403 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 22:28:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 22:28:18 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.ca7d590199605aa8c293f6bac572e537@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: partial- Blocked By: | sigs/should_compile/T10403 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => partial-sigs/should_compile/T10403 * resolution: => fixed Comment: I've elaborate the test to check both `h :: _` and `h :: _ => _`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 18 23:01:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Jun 2015 23:01:53 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.6f69ff9399507c3b2100de0b379fa74a@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+------------------------------------ Reporter: cjwatson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D996 -----------------------------------+------------------------------------ Changes (by slyfox): * differential: => Phab:D996 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 02:06:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 02:06:17 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.b349886c362308618255de18eddb19b7@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: None/Unknown | Architecture: Blocked By: 5144 | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by cactus): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 07:51:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 07:51:35 -0000 Subject: [GHC] #10543: MacOS: validate fails on \u Message-ID: <047.a887440a0df817cb06caf9fc53c8c2c9@haskell.org> #10543: MacOS: validate fails on \u -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Operating System: MacOS X Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Running validate on MacOS fails with this error (due to `-Werror`): {{{ libraries/Cabal/Cabal/Distribution/Simple/BuildTarget.hs:392:24: error: \u used with no following hex digits; treating as '\' followed by identifier [-Werror,-Wunicode] matchBuildTarget pkg = \utarget fexists -> ^ 1 error generated. make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 }}} I am using ghc from homebrew to bootstrap on OS X 10.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 08:51:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 08:51:23 -0000 Subject: [GHC] #10507: Looping with type level naturals In-Reply-To: <047.5fd95e048f3c3bca89022fe8d424335a@haskell.org> References: <047.5fd95e048f3c3bca89022fe8d424335a@haskell.org> Message-ID: <062.45f44b198278d687cd864142df44ae56@haskell.org> #10507: Looping with type level naturals -------------------------------------+------------------------------------- Reporter: jhendrix | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.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 Revisions: -------------------------------------+------------------------------------- Comment (by jhendrix): I noticed the patch didn't apply cleanly either. I found a work around by introducing an auxiliary function, so I think this isn't a show stopper for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 09:26:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 09:26:29 -0000 Subject: [GHC] #10537: Parser: commas_tup_tail duplicate SrcSpan on "Missing" value In-Reply-To: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> References: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> Message-ID: <059.fc3a0b04fe1903b66569139634c84af4@haskell.org> #10537: Parser: commas_tup_tail duplicate SrcSpan on "Missing" value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D995 -------------------------------------+------------------------------------- Changes (by alanz): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 09:35:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 09:35:35 -0000 Subject: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.d626b210d897e3160f6592ae89815d07@haskell.org> #10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | MonadFail deprecate warning Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #8004, #4384, | Test Case: #4879, #2119 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * keywords: AMP MonadFail => AMP MonadFail deprecate warning * related: #8004, #4384, #4879 => #8004, #4384, #4879, #2119 Comment: (turns out there's yet another deprecation/warning related ticket...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 09:36:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 09:36:35 -0000 Subject: [GHC] #4879: Deprecate exports In-Reply-To: <049.ea1fa273b308c2a35269907288b50645@haskell.org> References: <049.ea1fa273b308c2a35269907288b50645@haskell.org> Message-ID: <064.a66ad6a1dcb8207ec080a8ff4291ebd8@haskell.org> #4879: Deprecate exports -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: deprecate Operating System: Unknown/Multiple | warning Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10071 #2119 | Test Case: | Blocking: | Differential Revisions: Phab:D638 -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => deprecate warning * related: => #10071 #2119 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 09:38:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 09:38:07 -0000 Subject: [GHC] #2119: explicitly importing deprecated symbols should elicit the deprecation warning In-Reply-To: <045.affc63bba10af8681f58c8409e4aaf99@haskell.org> References: <045.affc63bba10af8681f58c8409e4aaf99@haskell.org> Message-ID: <060.fc93494a86f9abf258182c2fd84995c4@haskell.org> #2119: explicitly importing deprecated symbols should elicit the deprecation warning -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: deprecate Operating System: Unknown/Multiple | warning Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4879 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => deprecate warning * failure: => None/Unknown * related: => #4879 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 09:42:42 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 09:42:42 -0000 Subject: [GHC] #10544: Schneller und effektiver als alles andere zuvor Message-ID: <046.973326fe19961145e0228902f66f7d13@haskell.org> #10544: Schneller und effektiver als alles andere zuvor -------------------------------------+------------------------------------- Reporter: pfeffsa | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Sedumoxal und Petoximol Sedumoxal und Petoximol sind die absoluten Fett-Killer und bei Weitem die wirkungsvollsten Di?tprodukte, die es zu finden gibt. Mit der Di?t sind Di?tler dazu in der Lage, innerhalb von 4 - 12 Wochen bis zu 16 Kilo Gewicht verlieren, ohne dazu viel Sport machen m?ssen. Dieses sehr revolution?re Konzept konnte schon tausende Personen davon ?berzeugen, bei ihrer Di?t vor allem auf [http://abnehmen-mit.com/testberichte/diat- produkte/sedumoxal-und-petoximol/ Sedumoxal und Petoximol] zur?ckzugreifen. Auch in den Medien ist die Di?t stark vertreten, denn diese Methode beheizt den gesamten Gesundheits-Markt. Die vielversprechende Formel greift zur?ck auf exquisite, hoch wirksame Substanzen, welche in den Produkten vereint eine noch nie gesehene Wirkung entfalten. So ist es kaum abstreitbar, dass die Produkte bei den Nutzern so hervorragend anschlagen. Unsere Redaktion konnte beobachten, dass diese Di?tpillen vor allem in Kombination die Pfunde so richtig purzeln lassen. Petoximol und Sedumoxal Erfahrung Durch die Anwender kriegt man ein umfangreiches und ?berwiegend ?berzeugende Meinungen von den Produkten. Unz?hlige Kunden konnten viele Pfunde weg bekommen und ihre Lebensqualit?t signifikant steigern. Zuz?glich wird berichtet, dass die Anwendung der Produkte selbst die emotionale Verfassung optimiert und allgemein f?r gute Laune sorgt. Auch die Nahrungsumwandlung soll sich durch die Di?t von Grund auf verbessern. Beinahe ausschlie?lich alle Interessenten hatten durch die Medien von Sedumoxal und Petoximol geh?rt, viele sind ?ber diverse Webseiten zu den Produkten gelangt und manche haben es durch deren sozialen Umfelder erfahren, dass die Di?t ein gutes Ergebnis hervorbringt. Rezensionen, dass Di?tler in nur wenigen Wochen bis zu 20 Kilo Gewicht verlieren konnten ? Resultate, die f?r diese Produkte sprechen. Dabei ist die Anwendung ganzheitlich und k?rperschonend, aber gleichzeitig sehr wirkm?chtig. Petoximol und Sedumoxal Wirkung Die Di?tmitten bekommen erst wegen deren Wirkstoffkombination eine derartig starke Wirkung. Dabei schw?chtt die Stoffkombination die Fett- Synthese, verst?rkt die Fettverbrennung und sch?tzt den Organismus vor Giftstoffen. Auch beeinflussen diese Pillen die Verdauung zum Guten und dies wird helfen, eine Gewichtsabnahme voranzubringen. Haupts?chlich die Maqui-Beere und gr?ner Tee sind die wirksamen Bestandteile welche die Di?tpillen enthalten. Sie beschleunigen die Fettverbennung und geben unserem K?rper das Zeichen, Fettpolster zu vernichten. Aus diesem Grund ist eine sichere Gewichtsreduzierung gewiss. Petoximol und Sedumoxal Test In unserem exklusiven Testverfahren bew?hrten sich die Pillen ?berdurchschnittlich gut. Unsere Testerin hatt's geschafft, 20 kg in gerade einmal 5 Wochen abzunehmen. Wir sahen davor noch nie derartige Resultate. Dabei nahm die testende Person ?ber den geschilderten Zeitraum jeweils morgens und abends Sedumoxal und Petoximol und konnte bereits nach kurzer Zeit positive Verbesserungen bemerken. Dabei war die anf?ngliche Zielsetzung, in 6 Wochen bis zu 15 Kilos loszuwerden. Dieses Ziel wurde sogar noch ?bertroffen. Petoximol und Sedumoxal kaufen Wir k?nnen best?tigen, dass es am g?nstigsten ist, falls man Sedumoxal und Petoximol direkt ?ber den Produkthersteller bestellt. Im Netz bietet der Fabrikant die Di?tprodukte auf seiner Webseite an. Da k?nnen Sie auch hin und wieder die Pillen mit einem Rabatt bestellen. So sind die Pillen bis zu 60 % billiger als wenn man sie zum Ladenpreis kauft. Eine entgegenkommende Einzigartigkeit ist die Petoximol und Sedumoxal Geld- zur?ck-Garantie, die in Anspruch genommen werden kann, falls man mit den Di?tmitteln nicht die gew?nschten Ergebnisse erzielt. [http://abnehmen- mit.com/] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 11:05:42 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 11:05:42 -0000 Subject: [GHC] #10545: Deadlock in the threaded RTS Message-ID: <047.a8d38e087211dfddaa8ecbe3c62bb848@haskell.org> #10545: Deadlock in the threaded RTS -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Runtime | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following program deadlocks with high probability: {{{ -- ghc -rtsopts -threaded -debug performGC.hs -- ./performGC 1000 +RTS -qg -N2 -- -qg turns off parallel GC, needed to trigger the bug -- -N2 or greater is needed module Main (main) where import System.Environment import Control.Concurrent import Control.Exception import Control.Monad import System.Random import System.Mem import qualified Data.Set as Set main = do [n] <- getArgs forkIO $ doSomeWork forM [1..read n] $ \n -> do print n; threadDelay 1000; performMinorGC doSomeWork :: IO () doSomeWork = forever $ do ns <- replicateM 10000 randomIO :: IO [Int] ms <- replicateM 1000 randomIO let set = Set.fromList ns elems = filter (`Set.member` set) ms evaluate $ sum elems }}} There are a few ways that this bug can be triggered: * At shutdown, when there are other threads still running. This is how we first encountered it. * Using `performGC`, as above. I think it's necessary to call it from a bound thread (e.g. the main thread) to get bad things to happen. * I think `forkProcess` might also trigger it, but I haven't observed it. I'm working on a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 11:24:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 11:24:11 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.b34073d53a66ccfeb8a182bb2953d1d6@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): The blow-up in 7.10 appears to be due to the introduction of silent superclass parameters, a notion which has been replaced in `master` (namely a6f0f5ab45b2643b561e0a0a54a4f14745ab2152 and surrounding commits). I'm working on backporting these to the 7.10 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 12:51:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 12:51:28 -0000 Subject: [GHC] #10348: HEAD: `KnownNat` does not imply `Typeable` any more In-Reply-To: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> References: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> Message-ID: <063.998b7c6730c67ac3d5ffc0b590386822@haskell.org> #10348: HEAD: `KnownNat` does not imply `Typeable` any more -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: diatchki Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:6 simonpj]: > Iavor says he'll do this over the weekend. > > Simon Thanks, that sounds good :-) These are presumably part of the future solution: {{{ $ git grep typeLitTypeRep compiler/deSugar/DsBinds.hs: ctr <- dsLookupGlobalId typeLitTypeRepName compiler/prelude/PrelNames.hs: typeLitTypeRepName, compiler/prelude/PrelNames.hs: , typeLitTypeRepName compiler/prelude/PrelNames.hs:typeLitTypeRepName = varQual tYPEABLE_INTERNAL (fsLit "typeLitTypeRep") typeLitTypeRepKey compiler/prelude/PrelNames.hs: , typeLitTypeRepKey compiler/prelude/PrelNames.hs:typeLitTypeRepKey = mkPreludeMiscIdUnique 506 libraries/base/Data/Typeable/Internal.hs: typeLitTypeRep libraries/base/Data/Typeable/Internal.hs:typeLitTypeRep :: String -> TypeRep libraries/base/Data/Typeable/Internal.hs:typeLitTypeRep nm = rep }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 13:09:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 13:09:01 -0000 Subject: [GHC] #10546: conc034 is failing with a Core Lint error Message-ID: <047.9168d37927d1a0edb26045a19a955209@haskell.org> #10546: conc034 is failing with a Core Lint error -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ =====> conc034(threaded2) 78 of 99 [0, 0, 0] cd . && "/home/smarlow/ghc/inplace/bin/ghc-stage2" -o conc034 conc034.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-warn-tabs -fno-ghci-history -O -threaded -eventlog > conc034.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling Main ( conc034.hs, conc034.o ) *** Core Lint errors : in result of Simplifier *** : warning: In the expression: seq @ e10_a1ZF @ (# State# RealWorld, () #) e2_a1ZN (# eta_X16, () #) Kinds don't match in type application: Type variable: b_13 :: * Arg type: (# State# RealWorld, () #) :: # xx # }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 13:17:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 13:17:40 -0000 Subject: [GHC] #10547: feature request: expanding type synonyms in error messages Message-ID: <043.c20ed6dece31f72a0d7c2a22033dd48e@haskell.org> #10547: feature request: expanding type synonyms in error messages -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: feature | Status: new request | Milestone: 7.12.1 Priority: low | Version: Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type errors sometimes becoming confusing because of synonyms, for example, expected type and found type sometimes use different synonyms or sometimes only one of them use a synonym etc. We discussed this in the mailing list: https://mail.haskell.org/pipermail /ghc-devs/2015-June/009247.html And also moved it to the Wiki to collect examples: https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal I'm currently working on a patch, I made some progress and I'll hopefully submit something for reviews in a couple of days. This ticket is for further discussions and keep track of the progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 13:56:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 13:56:06 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.b2a59410634b765c6b579ddfbf0f1ca7@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Unfortunately it is a bit tricker bringing a6f0f5ab45b2643b561e0a0a54a4f14745ab2152 to `ghc-7.10` than I was hoping it would be, * We want a6f0f5ab45b2643b561e0a0a54a4f14745ab2152 (Eliminate so-called "silent superclass parameters") * Unfortunately this breaks the constraint solver (#10335, manifested when compiling `Data.Data` as missing `Typeable` instances) * This appears to be fixed in `master` by 646866ff318d6eb8beeed98032644182dd9d997b (Fix superclass generation in an instance) * Unfortunately an approximation of this appears to already be present as 7f24cdd63fbfd69a83f81e85384dc8cb7ef57704 I haven't yet taken a careful look at able to the patches fixing superclass generation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 15:07:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 15:07:14 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.5be1661cb973b8e416fd7f70f9697239@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I looked at this a bit too, but I'm now in an all-day meeting. One idea. I think that 95% of the pain comes from cross-module specialisation, dramatically exacerbated by the silent superclasses thing. If I'm right, a much quicker fix would be `-fno-specialise`. A less draconian fix would be an extra flag `-fno-cross-module- specialise`, which turns `Specialise.specImports` into a no-op. GHC never ''used'' to do cross-module specialisation. Maybe we should even disable it by-default in 7.10? Anyway implementing such a flag would take only a minute or two, and would be a Good Thing anyway. Moving HEAD's fix for silent userclasses is a pretty complicated solution. Ben, suggestions: * See if `-fno-specialise` solves the problem * Add the flag and see if that too solves the problem * Add some stats gathering in `Specialise` that reports how many imported functions are specialised, at how many different types, and how big the specialised code is. The idea is so we can more easily see when there's a specialisation blow-up. * If so we can switch off cross-module specialisation by default (although I'd prefer it to be on in 7.12) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 15:41:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 15:41:39 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.7901942cf1caa6d1e9b8cdaac549b8b1@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): -fno-specialise does not seem to solve the problem ( time ghc -v -fsimpl-tick-factor=150 -O2 Slice.hs ) > t.out 2>&1 & tail t.out {{{ Result size of Float inwards = {terms: 4,218,587, types: 4,087,814, coercions: 113,719} *** Called arity analysis: Result size of Called arity analysis = {terms: 4,218,587, types: 4,087,814, coercions: 113,719} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 4,217,640, types: 4,085,011, coercions: 111,731} Result size of Simplifier iteration=2 = {terms: 4,217,311, types: 4,083,869, coercions: 110,905} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 17:34:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 17:34:34 -0000 Subject: [GHC] #10537: Parser: commas_tup_tail duplicate SrcSpan on "Missing" value In-Reply-To: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> References: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org> Message-ID: <059.4e12b5518baf8a944973ac0ff49173e6@haskell.org> #10537: Parser: commas_tup_tail duplicate SrcSpan on "Missing" value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D995 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 17:38:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 17:38:31 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.a04428abad3ed462a700a6d7495ce307@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): George, don't worry about the edits; I am quite guilty of long strings of edits myself and as far as I can tell Trac only produces a message on the initial submission. Simon, I am sad to say that I can confirm that `-fno-specialise` does not help this issue. That being said, I'll see to it that we have a enabled- by-default `-fcross-module-specialise` option and some diagnostics output going forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 17:46:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 17:46:56 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.fb0d1573f234f944fefb4e4c8693d703@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Well I suggest you use `-fno-specialise` in any further investigations. It doesn't fix it, but it'll remove distracting clutter from what you see. The silent-superclass thing is not really the ''cause''. (And hence I don't think it's worth a heroic effort to port HEAD to 7.10. It certainly generates a lot more dictionaries, so perhaps there might be twice as much code as without. But you are seeing MUCH more than that! So maybe there is a bug lurking in HEAD too; it just happens that the code generated by silent superclasses in 7.10 tickles it. So the hunt goes on. Monday is a washout for me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 19:27:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 19:27:41 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.ef6af54919c00afac203e7bf96a2ff02@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T8953 Related Tickets: | Blocking: | Differential Revisions: Phab:D387 -------------------------------------+------------------------------------- Changes (by goldfire): * owner: goldfire => * status: closed => new * version: 7.9 => 7.10.1 * resolution: fixed => * milestone: => 7.12.1 Comment: Embarrassingly, this patch misses closed type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 19:28:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 19:28:01 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.4bc639b5420c180fb13c524e4df026fa@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T8953 Related Tickets: | Blocking: | Differential Revisions: Phab:D387 -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 20:20:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 20:20:04 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.41f7f2fa0ebacef3752d822cdb94fc5a@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: partial- Blocked By: | sigs/should_compile/T10403 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by int-index): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 20:25:42 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 20:25:42 -0000 Subject: [GHC] #10509: UnicodeSyntax documentation lists wrong symbols In-Reply-To: <045.99753819878229404545a65d82eb520e@haskell.org> References: <045.99753819878229404545a65d82eb520e@haskell.org> Message-ID: <060.99888997a8738db8e3174bbf2525445b@haskell.org> #10509: UnicodeSyntax documentation lists wrong symbols -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by pgj): * owner: zardoz => * status: closed => new * resolution: fixed => Comment: Unfortunately, [https://mail.haskell.org/pipermail/ghc- builds/2015-June/005002.html according to the buildbots], this patch does not work with the LaTeX backend but the HTML format only: {{{ Build users_guide.ps latex failed users_guide.tex:17170: Undefined control sequence \Colon. users_guide.tex:17170: leading text: } Unexpected error occured Missing character ⤙ Missing character ⤚ Missing character ⤛ Missing character ⤜ [ -f docs/users_guide/users_guide.ps ] docs/users_guide/ghc.mk:26: recipe for target 'docs/users_guide/users_guide.ps' failed gmake[1]: *** [docs/users_guide/users_guide.ps] Error 1 Makefile:102: recipe for target 'all' failed gmake: *** [all] Error 2 }}} This build problem itself could be fixed with the {{{-P 'latex.unicode.use=1'}}} flag passed to dblatex. Though, the resulting PS/PDF files will not have the expected symbols as dblatex does not know how to translate that. I can add the aforementioned flag for dblatex to {{{mk/config.mk}}} so the buildbots will not get choked on this any more, but it will not solve the problem of generating proper symbols for the PS/PDF versions of the guide. zardoz: Do you have any ideas how to fix that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 20:29:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 20:29:00 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.8f86e05e612fc272197d591d3f82f955@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: partial- Blocked By: | sigs/should_compile/T10403 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-index): Simon, could you please add the code from the ticket to the test case verbatim? Your new variation does not trigger the bug because you removed the `app` function. Since you want to test both `h1 :: _` and `h2 :: _ => _`, please do not forget to include `add1` and `add2` so they get called. Here's code that triggers the bug: {{{ {-# LANGUAGE PartialTypeSignatures #-} module T10403 where main :: IO () main = return () data I a = I a instance Functor I where fmap f (I a) = I (f a) newtype B t a = B a instance Functor (B t) where fmap f (B a) = B (f a) newtype H f = H (f ()) app1 :: H (B t) app1 = h1 (H . I) (B ()) app2 :: H (B t) app2 = h2 (H . I) (B ()) h1 :: _ => _ --h1 :: Functor m => (a -> b) -> m a -> H m h1 f b = (H . fmap (const ())) (fmap f b) h2 :: _ --h2 :: Functor m => (a -> b) -> m a -> H m h2 f b = (H . fmap (const ())) (fmap f b) }}} The error message I'm getting when loading it in GHCi is: {{{ GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help ?> :l Bug.hs [1 of 1] Compiling T10403 ( Bug.hs, interpreted ) Bug.hs:21:12: Couldn't match type ?b? with ?H I? ?b? is untouchable inside the constraints () bound by the type signature for app2 :: H (B t) at Bug.hs:20:9-15ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): No skolem info: b_ao6[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 Jun 19 21:41:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 21:41:12 -0000 Subject: [GHC] #10509: UnicodeSyntax documentation lists wrong symbols In-Reply-To: <045.99753819878229404545a65d82eb520e@haskell.org> References: <045.99753819878229404545a65d82eb520e@haskell.org> Message-ID: <060.7f467bf4bd82f377ccdbea40bace8f1f@haskell.org> #10509: UnicodeSyntax documentation lists wrong symbols -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Gabor Pali ): In [changeset:"440d1bc1f5fa4d31f1f7bc45f3f3485733509313/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="440d1bc1f5fa4d31f1f7bc45f3f3485733509313" docs: Unbreak the PS/PDF builds for the User's Guide (#10509) dblatex can only translate the Unicode glyphs introduced in #10509 for LaTeX if the `latex.unicode.use=1` flag is set, otherwise it will just fail. However, note that adding this flag is not going to fully solve the problem as those symbols are not known by LaTeX, so the corresponding character codes will be added instead to the resulting PS/PDF files. Hence it is considered an interim solution only, not a true fix, until a better one is found. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 22:07:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 22:07:40 -0000 Subject: [GHC] #10546: conc034 is failing with a Core Lint error In-Reply-To: <047.9168d37927d1a0edb26045a19a955209@haskell.org> References: <047.9168d37927d1a0edb26045a19a955209@haskell.org> Message-ID: <062.b7a1b2ed688c42eaf3298d5a9978c12d@haskell.org> #10546: conc034 is failing with a Core Lint error -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | concurrent/should_run/conc034.hs | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) * testcase: => concurrent/should_run/conc034.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 19 22:09:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Jun 2015 22:09:20 -0000 Subject: [GHC] #10546: conc034 is failing with a Core Lint error In-Reply-To: <047.9168d37927d1a0edb26045a19a955209@haskell.org> References: <047.9168d37927d1a0edb26045a19a955209@haskell.org> Message-ID: <062.6871ecfad01eb3ec5e66a213fd5426db@haskell.org> #10546: conc034 is failing with a Core Lint error -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | concurrent/should_run/conc034.hs | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by slyfox): Also fails in opt modes: {{{ $ make test TEST="conc034" WAY=optasm *** Core Lint errors : in result of Simplifier *** : warning: In the expression: seq @ e10_a1ZU @ (# State# RealWorld, () #) e2_a202 (# eta_X16, () #) Kinds don't match in type application: Type variable: b_13 :: * Arg type: (# State# RealWorld, () #) :: # xx # }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 03:13:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 03:13:15 -0000 Subject: [GHC] #10548: Support PartialTypeSignatures in Template Haskell Message-ID: <045.2df5e13492bce560a66b130aa6f59e92@haskell.org> #10548: Support PartialTypeSignatures in Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently Template Haskell cannot emit [https://hackage.haskell.org/package/template-haskell-2.10.0.0/docs /Language-Haskell-TH-Syntax.html#t:Type Type]s with wildcards as in [https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures PartialTypeSignatures]. A data constructor for wildcards (eg. {{{WildcardT (Maybe Name)}}}) could be added to [https://hackage.haskell.org/package/template- haskell-2.10.0.0/docs/Language-Haskell-TH-Syntax.html#t:Type Type], which would be converted to wildcards in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 03:25:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 03:25:13 -0000 Subject: [GHC] #10548: Support PartialTypeSignatures in Template Haskell In-Reply-To: <045.2df5e13492bce560a66b130aa6f59e92@haskell.org> References: <045.2df5e13492bce560a66b130aa6f59e92@haskell.org> Message-ID: <060.673dc8d5ea36cd6a1a69217d1ce844a4@haskell.org> #10548: Support PartialTypeSignatures in Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer Comment: Adding new language features to TH is a fantastic way to start hacking on GHC. (Proof: it was my first contribution.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 03:59:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 03:59:33 -0000 Subject: [GHC] #8353: Easy way to defer type errors In-Reply-To: <047.34842edf8c636f9b11361128b151d960@haskell.org> References: <047.34842edf8c636f9b11361128b151d960@haskell.org> Message-ID: <062.f077794411223be83f9a1b850577d582@haskell.org> #8353: Easy way to defer type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D960 -------------------------------------+------------------------------------- Comment (by goldfire): For whatever it's worth, I haven't changed my mind about wanting this feature, nor the choice of concrete syntax. Thanks for putting together a patch! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 05:06:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 05:06:14 -0000 Subject: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.1925b45c09f5337c0a1311d74ceaaf64@haskell.org> #10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | MonadFail deprecate warning Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #8004, #4834, | Test Case: #4879, #2119 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by oerjan): * related: #8004, #4384, #4879, #2119 => #8004, #4834, #4879, #2119 Comment: (fix typo in related ticket number) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 08:55:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 08:55:27 -0000 Subject: [GHC] #7854: Constrained method type accepted in Haskell 98 mode In-Reply-To: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> References: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> Message-ID: <060.e81b65ea9405f0b81c71042de2844b77@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"e4918034896948642718f15906f5b379b98f68cf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e4918034896948642718f15906f5b379b98f68cf" Amend tcrun024, tcrun025 after Trac #7854 fix Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 08:55:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 08:55:33 -0000 Subject: [GHC] #10486: Allow addTopDecls to create annotations In-Reply-To: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> References: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> Message-ID: <060.9ba95024d5db593a33cc91a6d6083c73@haskell.org> #10486: Allow addTopDecls to create annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): I can submit a patch for this if the idea is okay. It's a very trivial change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 09:07:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 09:07:06 -0000 Subject: [GHC] #7854: Constrained method type accepted in Haskell 98 mode In-Reply-To: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> References: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> Message-ID: <060.dc673596a51275b68d0594806c502ee8@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"7c2293a07fb057e492278f46e8fde48b69d178a3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7c2293a07fb057e492278f46e8fde48b69d178a3" Amend tcrun037 after Trac #7854 fix Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 09:12:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 09:12:59 -0000 Subject: [GHC] #10522: Add UInfixT, like UInfixE or UInfixP but for types In-Reply-To: <045.117758279834e73fff10891f1400af9d@haskell.org> References: <045.117758279834e73fff10891f1400af9d@haskell.org> Message-ID: <060.7bd6e68ea0b1dc4acadd263e8842829c@haskell.org> #10522: Add UInfixT, like UInfixE or UInfixP but for types -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): For reference: the (one-line) implementation of [https://github.com/ghc/ghc/blob/master/compiler/hsSyn/Convert.hs#L920 UInfixP] and the corresponding "[https://github.com/ghc/ghc/blob/master/compiler/hsSyn/Convert.hs#L739-L768 Converting UInfix]" note. Addressing this looks fairly straightforward. (1) Add a new {{{UInfixT Type Name Type}}} data constructor to the declaration of [https://github.com/ghc/ghc/blob/master/libraries/template- haskell/Language/Haskell/TH/Syntax.hs#L1464-L1483 Language.Haskell.TH.Syntax.Type]. (2) Add a new branch to [https://github.com/ghc/ghc/blob/058af6c90a0e8d122f2d1339b6b4fd0b5ec83d05/compiler/hsSyn/Convert.hs#L989 cvtTypeKind] with a one-to-one conversion to [https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc/HsTypes.html#v:HsOpTy HsOpTy]. Then the renamer already handles [https://github.com/ghc/ghc/blob/058af6c90a0e8d122f2d1339b6b4fd0b5ec83d05/compiler/rename/RnTypes.hs#L153-L166 restructuring the tree]. I'll try my hand at it myself when I get the time, if no one has taken it up by then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 09:17:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 09:17:57 -0000 Subject: [GHC] #10548: Support PartialTypeSignatures in Template Haskell In-Reply-To: <045.2df5e13492bce560a66b130aa6f59e92@haskell.org> References: <045.2df5e13492bce560a66b130aa6f59e92@haskell.org> Message-ID: <060.5b5483034eb54fb296407cc93d80d9ba@haskell.org> #10548: Support PartialTypeSignatures in Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): I believe an implementation would consist of: (1) Add a {{{WildcardT (Maybe Name)}}} data constructor to the declaration of [https://github.com/ghc/ghc/blob/master/libraries/template- haskell/Language/Haskell/TH/Syntax.hs#L1464-L1483 Language.Haskell.TH.Syntax.Type]. (2) Add a new branch to [https://github.com/ghc/ghc/blob/058af6c90a0e8d122f2d1339b6b4fd0b5ec83d05/compiler/hsSyn/Convert.hs#L989 cvtTypeKind] that translates this to either [https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc/HsTypes.html#v:HsWildcardTy HsWildcardTy] or [https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc/HsTypes.html#v:HsNamedWildcardTy HsNamedWildcardTy], depending on the {{{Maybe Name}}} value. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 09:35:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 09:35:34 -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.d33b7a1495f63bd66a5944da2a4defa0@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: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): Attempt at a rough specification: (1) Extend [https://hackage.haskell.org/package/template- haskell-2.10.0.0/docs/Language-Haskell-TH-Syntax.html#t:ModuleInfo ModuleInfo] (obtained from [https://hackage.haskell.org/package/template- haskell-2.10.0.0/docs/Language-Haskell-TH-Syntax.html#v:reifyModule reifyModule]) to {{{ModuleInfo [Module] [Name]}}}, where {{{[Module]}}} is still the import list and {{{[Name]}}} contains the module's list of exported names. (2) Add {{{thisModule :: Q Module}}} producing the current [https://hackage.haskell.org/package/template-haskell-2.10.0.0/docs /Language-Haskell-TH-Syntax.html#t:Module Module]. (3) Add {{{topLevelNames :: Q [Name]}}} producing a list of top-level names (both exported and non-exported) bound in the current module that would be visible to {{{reify}}}. (4) Add {{{nestedNames :: Q [Name]}}} (in need of a better name) producing a list of the non-top-level (nested) names visible to {{{reify}}} in this context. (5) Add {{{parentNames :: Q [Name]}}} (also in need of a better name) producing a list of the names immediately associated with the current splicing context, if available. For example, {{{foo, bar :: $(typeSplice)}}} would see {{{foo}}} and {{{bar}}}, {{{foo = $(exprSplice)}}} would see {{{foo}}}, and {{{$(topLevelDecSplice)}}} would see {{{[]}}}. (6) ''Optional'' Add {{{isTopLevel :: Name -> Q Bool}}} to detect whether a name is bound at the top level (of the current module?). Something like this could alternately be accomplished by searching through {{{topLevelNames}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 09:35:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 09:35:50 -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.b645f0e0b3248c6c858fd0d5261426e0@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: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by spinda): * cc: spinda (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 09:57:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 09:57:09 -0000 Subject: [GHC] #10052: Panic (something to do with floatExpr?) In-Reply-To: <044.712619dfc86074dec5613c292886ee1f@haskell.org> References: <044.712619dfc86074dec5613c292886ee1f@haskell.org> Message-ID: <059.680628da11648f75f4f9e6af885068d1@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"2c6a0411dcd921ea6ec1cbe5eaf93d17adcf33a2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2c6a0411dcd921ea6ec1cbe5eaf93d17adcf33a2" Fix a couple of tests for GHCi/-O* (Trac #10052) Tests use unboxed types (or optimizer gets to them), those can't be handled by ghci. Fixed by using -fobject-code. Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 15:19:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 15:19:28 -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.4e36ac9db201f44d9615b66a85784a3a@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: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by MikeIzbicki): This would work for my use case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 15:35:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 15:35:37 -0000 Subject: [GHC] #10549: floatExpr tick break<2> Message-ID: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Status: new Type: bug | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When running the Shake test suite against GHC HEAD I get: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.11.20150615 for x86_64-unknown-linux): floatExpr tick break<2>() }}} Full log at https://travis-ci.org/ndmitchell/shake/jobs/67636563. The command line that produced it is: {{{ runhaskell -ignore-package=hashmap -ioutput/docs/ -isrc output/docs/Main.hs }}} If this seems like a legitimate bug that you don't already know about and are interested in tracking down, I'll try and grab the output/docs directory (it's on a remote machine I don't have access to on a different OS with a compiler I don't have installed, so it's not trivial to find it, but should be possible). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 16:09:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 16:09:11 -0000 Subject: [GHC] #10476: Wrong ar during cross-compilation In-Reply-To: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> References: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> Message-ID: <061.94deef05391747963c97a6bde012bed8@haskell.org> #10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: jakzale Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: cross- Operating System: MacOS X | compiling Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jakzale): * owner: => jakzale -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 17:03:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 17:03:12 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.b959100b53d774afb1512a073ab02037@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): George, what GHC version did you test `-fno-specialise` on? While yesterday I was able to confirm that `-fno-specialise` seemed to make no difference on a test machine running what should have been 7.10.1 I am now having trouble replicating this on my laptop. Unfortunately I no longer have access to the test environment on which I tested this yesterday but clearly something was inconsistent. I am now seeing on multiple machines that `-fno-specialise` indeed allows things to compile, {{{ $ ghc -V The Glorious Glasgow Haskell Compilation System, version 7.10.1 $$ time ghc Slice.hs -fforce-recomp -O2 -fno-specialise [1 of 1] Compiling Slice ( Slice.hs, Slice.o ) real 0m3.759s user 0m1.688s sys 0m0.044s $ time ghc Slice.hs -fforce-recomp -O2 [1 of 1] Compiling Slice ( Slice.hs, Slice.o ) ^C real 0m51.103s user 0m44.336s sys 0m0.948s }}} I am now looking at whether disabling only cross-module specialisation is enough to eliminate the blow-up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 17:54:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 17:54:29 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.2e212adf8bb329503ce177701c312abb@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T10047 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) Comment: I skimmed through testsuite failures on full validate today and found qq007 and qq008 failures: {{{#!hs [sf] ~/dev/git/ghc/testsuite/tests/quasiquotation/qq007:cat QQ.hs {-# LANGUAGE TemplateHaskell #-} module QQ where import Language.Haskell.TH.Quote import Language.Haskell.TH pq = QuasiQuoter { quoteDec = \_ -> [d| f x = x |], quoteType = \_ -> [t| Int -> Int |], quoteExp = \_ -> [| $(varE (mkName "x")) + 1::Int |], quotePat = \_ -> [p| Just x |] } [sf] ~/dev/git/ghc/testsuite/tests/quasiquotation/qq007:"/home/slyfox/dev/git/ghc/inplace/bin /ghc-stage2" --make Test -fforce-recomp -dcore-lint -dcmm-lint -dno- debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -v0 Test.hs:6:1: error: The type signature for ?f? lacks an accompanying binding }}} Reid suggested this fix likely caused the change. Is it fine/expected? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 18:58:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 18:58:29 -0000 Subject: [GHC] #10456: Wrong CPP during cross-compilation In-Reply-To: <046.462d8102e6aedbc950f7c67c721714d1@haskell.org> References: <046.462d8102e6aedbc950f7c67c721714d1@haskell.org> Message-ID: <061.9854b7d07c43c5aafe44ab8ab8aa23e3@haskell.org> #10456: Wrong CPP during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: jakzale Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: cross- Operating System: Unknown/Multiple | compiling Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jakzale): * owner: => jakzale -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 19:11:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 19:11:40 -0000 Subject: [GHC] #10456: Wrong CPP during cross-compilation In-Reply-To: <046.462d8102e6aedbc950f7c67c721714d1@haskell.org> References: <046.462d8102e6aedbc950f7c67c721714d1@haskell.org> Message-ID: <061.4ec1efa9ed43dd22b9ffe30218758e67@haskell.org> #10456: Wrong CPP during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: jakzale Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: cross- Operating System: Unknown/Multiple | compiling Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D998 -------------------------------------+------------------------------------- Changes (by jakzale): * differential: => Phab:D998 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 19:56:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 19:56:21 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.e1d3b33fb49acd3bad2409cc9b23c1d8@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Phab:D999 adds a `-fno-cross-module-specialisation` option which works around the blow-up will likely still be present in 7.10.2. I'm still trying to work out exactly what is happening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 20:42:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 20:42:12 -0000 Subject: [GHC] #10550: Drop truncated package name prefix from package keys Message-ID: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> #10550: Drop truncated package name prefix from package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Package | Version: 7.11 system | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Early on when we moved to package keys, we decided it would be useful for documentation purposes to have a package key be something like `ghcpr_8TmvWUcS1U1IKHT0levwg3` rather than just `8TmvWUcS1U1IKHT0levwg3`, which would leave a user with no idea what the key is. I now think that this is more trouble than its worth: 1. We have fixed library *paths* so that the full package name, version, key is in the path, e.g. libraries are installed to `/home/ezyang/Dev/ghc-7.10.2/usr/lib/ghc-7.10.2/ghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3` instead of `/home/ezyang/Dev/ghc-7.10.1/usr/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3`. This means that the biggest case where users might care about package keys is no longer relevant; a user will always be able to get the real package key. 2. The other case where package keys show up is in symbol names. However, symbol names already contain *modules names*, so today we have `procezu0hwN3CTKynhHQqQkChnSdH_SystemziProcess_rawSystem1_info` but `0hwN3CTKynhHQqQkChnSdH_SystemziProcess_rawSystem1_info` seems just about as clear (in particular, five letters just doesn't seem like enough to adequately describe long package names.) 3. Now, the reason why we don't want to truncate the prefix name is because it makes it more difficult to reliably, deterministically generate a package key based on a few parameters about a package: namely, any algorithm needs to know that `take 5 (filter (/= '-') packageName)` and prefix that onto the key. Really, we only care about the hash, but for most equality tests the prefix matters too! So it would be much nicer if we didn't have to care about the hash as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 20:45:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 20:45:49 -0000 Subject: [GHC] #10550: Drop truncated package name prefix from package keys In-Reply-To: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> References: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> Message-ID: <060.d5489ea0c73ea39cb91441e1f452ca3a@haskell.org> #10550: Drop truncated package name prefix from package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Package system | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Works for me, is there a convenient `ghc-pkg something 0hwN3CTKynhHQqQkChnSdH` that will hand me `process-1.2.3.0` back? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 20:52:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 20:52:49 -0000 Subject: [GHC] #10550: Drop truncated package name prefix from package keys In-Reply-To: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> References: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> Message-ID: <060.d133f5ca260d2853918207337afbe02e@haskell.org> #10550: Drop truncated package name prefix from package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Package system | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Yeah, `ghc-pkg describe --package-key blah`, which is already in 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 21:58:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 21:58:55 -0000 Subject: [GHC] #2437: More accurate package dependencies In-Reply-To: <047.68fd28011c214b441523af716564e799@haskell.org> References: <047.68fd28011c214b441523af716564e799@haskell.org> Message-ID: <062.5384bdf69d691ffc6fb1a78cd9207d6d@haskell.org> #2437: More accurate package dependencies -------------------------------------+------------------------------------- Reporter: simonmar | Owner: niteria Type: task | Status: patch Priority: lowest | Milestone: 7.12.1 Component: Package system | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #3560, #8174 | Blocking: | Differential Revisions: Phab:D973 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"85d539754ac07286ef5fed714ad42451bd5a1d28/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="85d539754ac07286ef5fed714ad42451bd5a1d28" Make GHC install libraries to e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh. Summary: Previously, we'd install them to something like xhtml_0ACfOp3hebWD9jGWE4v4G which was fairly ugly; this commit changes the default install path to contain the full package name and version, as well as the package key. Needs a Cabal submodule update for the commit for install paths support "Add libname install-dirs variable, use it by default. Fixes #2437". It also contains some miscellaneous fixes for Cabal HEAD. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: austin Subscribers: bgamari, thomie Trac Issues: #10479 Differential Revision: https://phabricator.haskell.org/D922 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 21:58:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 21:58:55 -0000 Subject: [GHC] #10479: Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh In-Reply-To: <045.1ef1ca690686af7d2265216e3878b27c@haskell.org> References: <045.1ef1ca690686af7d2265216e3878b27c@haskell.org> Message-ID: <060.42cb8b279d2cde1541bf6494d149a7d1@haskell.org> #10479: Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Package system | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: 9506 | Differential Revisions: Phab:D922 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"85d539754ac07286ef5fed714ad42451bd5a1d28/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="85d539754ac07286ef5fed714ad42451bd5a1d28" Make GHC install libraries to e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh. Summary: Previously, we'd install them to something like xhtml_0ACfOp3hebWD9jGWE4v4G which was fairly ugly; this commit changes the default install path to contain the full package name and version, as well as the package key. Needs a Cabal submodule update for the commit for install paths support "Add libname install-dirs variable, use it by default. Fixes #2437". It also contains some miscellaneous fixes for Cabal HEAD. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: austin Subscribers: bgamari, thomie Trac Issues: #10479 Differential Revision: https://phabricator.haskell.org/D922 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 22:13:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 22:13:30 -0000 Subject: [GHC] #10420: "Care with plugin imports" is wrong / orphan RULE visibility In-Reply-To: <045.0008d7bf15a6c184529405e4260be834@haskell.org> References: <045.0008d7bf15a6c184529405e4260be834@haskell.org> Message-ID: <060.ef2d1f97dcfbaa7b50c35017ed437f03@haskell.org> #10420: "Care with plugin imports" is wrong / orphan RULE visibility -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: plugins07 Blocked By: | Blocking: 10294 Related Tickets: | Differential Revisions: Phab:D950 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"0cb1f5cf26fae946ca745abc5e302e62a8f66feb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0cb1f5cf26fae946ca745abc5e302e62a8f66feb" Filter orphan rules based on imports, fixes #10294 and #10420. Summary: If we have an orphan rule in our database, don't apply it unless the defining module is transitively imported by the module we are processing. We do this by defining a new RuleEnv data type which includes both the RuleBase as well as the set of visible orphan modules, and threading this through the relevant environments (CoreReader, RuleCheckEnv and ScEnv). This is analogous to the instances fix we applied in #2182 4c834fdddf4d44d12039da4d6a2c63a660975b95, but done for RULES. An important knock-on effect is that we can remove some buggy code in LoadInterface which tried to avoid loading interfaces that were loaded by plugins (which sometimes caused instances and rules to NEVER become visible). One note about tests: I renamed the old plugins07 test to T10420 and replaced plugins07 with a test to ensure that a plugin import did not cause new rules to be loaded in. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, goldfire Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D950 GHC Trac Issues: #10420 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 22:13:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 22:13:30 -0000 Subject: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> References: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> Message-ID: <059.4ca8b04239c45cfb36346bf7a1dc8dfa@haskell.org> #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 6.9 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: T2182ghci, invalid program | T2182ghci2, T2182 Blocked By: | Blocking: 5316 Related Tickets: | Differential Revisions: Phab:D488 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"0cb1f5cf26fae946ca745abc5e302e62a8f66feb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0cb1f5cf26fae946ca745abc5e302e62a8f66feb" Filter orphan rules based on imports, fixes #10294 and #10420. Summary: If we have an orphan rule in our database, don't apply it unless the defining module is transitively imported by the module we are processing. We do this by defining a new RuleEnv data type which includes both the RuleBase as well as the set of visible orphan modules, and threading this through the relevant environments (CoreReader, RuleCheckEnv and ScEnv). This is analogous to the instances fix we applied in #2182 4c834fdddf4d44d12039da4d6a2c63a660975b95, but done for RULES. An important knock-on effect is that we can remove some buggy code in LoadInterface which tried to avoid loading interfaces that were loaded by plugins (which sometimes caused instances and rules to NEVER become visible). One note about tests: I renamed the old plugins07 test to T10420 and replaced plugins07 with a test to ensure that a plugin import did not cause new rules to be loaded in. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, goldfire Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D950 GHC Trac Issues: #10420 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 22:13:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 22:13:30 -0000 Subject: [GHC] #10294: Missing instances if compiling with -fplugin In-Reply-To: <046.47fd486c7f73b488b5247db11cbe3c48@haskell.org> References: <046.47fd486c7f73b488b5247db11cbe3c48@haskell.org> Message-ID: <061.95ea2d281e03f73f0f36910b41acf963@haskell.org> #10294: Missing instances if compiling with -fplugin -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: duplicate | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: 10420 | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"0cb1f5cf26fae946ca745abc5e302e62a8f66feb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0cb1f5cf26fae946ca745abc5e302e62a8f66feb" Filter orphan rules based on imports, fixes #10294 and #10420. Summary: If we have an orphan rule in our database, don't apply it unless the defining module is transitively imported by the module we are processing. We do this by defining a new RuleEnv data type which includes both the RuleBase as well as the set of visible orphan modules, and threading this through the relevant environments (CoreReader, RuleCheckEnv and ScEnv). This is analogous to the instances fix we applied in #2182 4c834fdddf4d44d12039da4d6a2c63a660975b95, but done for RULES. An important knock-on effect is that we can remove some buggy code in LoadInterface which tried to avoid loading interfaces that were loaded by plugins (which sometimes caused instances and rules to NEVER become visible). One note about tests: I renamed the old plugins07 test to T10420 and replaced plugins07 with a test to ensure that a plugin import did not cause new rules to be loaded in. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, goldfire Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D950 GHC Trac Issues: #10420 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 22:13:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 22:13:56 -0000 Subject: [GHC] #10420: "Care with plugin imports" is wrong / orphan RULE visibility In-Reply-To: <045.0008d7bf15a6c184529405e4260be834@haskell.org> References: <045.0008d7bf15a6c184529405e4260be834@haskell.org> Message-ID: <060.9575f7d335cc1e2743829f1b19920aec@haskell.org> #10420: "Care with plugin imports" is wrong / orphan RULE visibility -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: plugins07 Blocked By: | Blocking: 10294 Related Tickets: | Differential Revisions: Phab:D950 -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 22:19:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 22:19:05 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.0572b4ebad3447867e0035726fa35a78@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D606 -------------------------------------+------------------------------------- Comment (by ezyang): I took a look, but unfortunately I don't have a very good idea for how to cause very deep TrieMaps to be generated. Some sort of very large types? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 22:28:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 22:28:50 -0000 Subject: [GHC] #10551: dynwrapper points to wrong paths on Windows Message-ID: <045.79129e7f0ae414856614a351b14b84aa@haskell.org> #10551: dynwrapper points to wrong paths on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I was looking at build-prog.mk and I noticed this: {{{ >-------echo 'LPTSTR path_dirs[] = {' >> $$@ >-------$$(foreach p,$$($1_$2_TRANSITIVE_DEP_KEYS),$$(call make- command,echo ' TEXT("/../lib/$$p")$$(comma)' >> $$@)) >-------echo ' TEXT("/../lib/"),' >> $$@ >-------echo ' NULL};' >> $$@ >-------echo 'LPTSTR progDll = TEXT }}} This probably can't be right since we're now using LIB_NAME to refer to filepaths. Better fix this... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 23:27:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 23:27:54 -0000 Subject: [GHC] #10551: dynwrapper points to wrong paths on Windows In-Reply-To: <045.79129e7f0ae414856614a351b14b84aa@haskell.org> References: <045.79129e7f0ae414856614a351b14b84aa@haskell.org> Message-ID: <060.9fd0bd04f9ef29c2692799f29a2d5262@haskell.org> #10551: dynwrapper points to wrong paths on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Build System | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Build System Comment: No rush. DYNAMIC_GHC_PROGRAMS=NO on Windows (#5987), so this condition is never satisfied: `ifeq "$$(Windows_Host) $$($1_$2_PROGRAM_WAY)" "YES dyn"` Which means that that code is never used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 23:33:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 23:33:31 -0000 Subject: [GHC] #10551: dynwrapper points to wrong paths on Windows In-Reply-To: <045.79129e7f0ae414856614a351b14b84aa@haskell.org> References: <045.79129e7f0ae414856614a351b14b84aa@haskell.org> Message-ID: <060.6d46df180f747bcaea0b63751ea60057@haskell.org> #10551: dynwrapper points to wrong paths on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * priority: high => normal Comment: Lowering priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 20 23:41:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Jun 2015 23:41:09 -0000 Subject: [GHC] #10551: dynwrapper points to wrong paths on Windows In-Reply-To: <045.79129e7f0ae414856614a351b14b84aa@haskell.org> References: <045.79129e7f0ae414856614a351b14b84aa@haskell.org> Message-ID: <060.778a49ba7efb4f0cfc719e9873092b9f@haskell.org> #10551: dynwrapper points to wrong paths on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1001 -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => Phab:D1001 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 02:47:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 02:47:11 -0000 Subject: [GHC] #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" In-Reply-To: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> References: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> Message-ID: <061.c9ac2a1ec1f9dc115d0ecdaaad4326b5@haskell.org> #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by yongqli): I can't isolate a test case -- whenever I set a function in my program to `undefined` the problem goes away. Is it possible I'm hitting against a limit in terms of how large a function can be? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 03:12:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 03:12:16 -0000 Subject: [GHC] #10552: round on negative fractionals causes a segfault Message-ID: <046.e7127d46bf2a13e01474e6019d4d5225@haskell.org> #10552: round on negative fractionals causes a segfault -----------------------------------+---------------------------------- Reporter: mmirman | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86 | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+---------------------------------- "round (-1.5)" causes a segfault. Causes a runtime crash as well as a ghci crash. OS X 10.6.8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 07:50:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 07:50:58 -0000 Subject: [GHC] #10553: powerpc: getEnvironment empty when run in GHCi Message-ID: <046.adcc18ef3ca28476b5b33aa794685929@haskell.org> #10553: powerpc: getEnvironment empty when run in GHCi -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Incorrect result Test Case: | at runtime Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Hi, on powerpc (only), with ghc-7.8, we have this: ``` $ cat env.hs import System.Environment main = getEnvironment >>= print $ runhaskell env.hs [] $ ./env [("RESET","\\e[0m")... ``` This breaks the test suite of shake. Does anyone feel like investigating this? Also tracked at https://bugs.debian.org/789458 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 07:53:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 07:53:30 -0000 Subject: [GHC] #10553: powerpc: getEnvironment empty when run in GHCi In-Reply-To: <046.adcc18ef3ca28476b5b33aa794685929@haskell.org> References: <046.adcc18ef3ca28476b5b33aa794685929@haskell.org> Message-ID: <061.0846d5ed6e9d4d840cd365803089df61@haskell.org> #10553: powerpc: getEnvironment empty when run in GHCi -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Description changed by nomeata: Old description: > Hi, > > on powerpc (only), with ghc-7.8, we have this: > > ``` > $ cat env.hs > import System.Environment > main = getEnvironment >>= print > $ runhaskell env.hs > [] > $ ./env > [("RESET","\\e[0m")... > ``` > > This breaks the test suite of shake. Does anyone feel like investigating > this? > > Also tracked at https://bugs.debian.org/789458 New description: Hi, on powerpc (only), with ghc-7.8, we have this: {{{ $ cat env.hs import System.Environment main = getEnvironment >>= print $ runhaskell env.hs [] $ ./env [("RESET","\\e[0m")... }}} This breaks the test suite of shake. Does anyone feel like investigating this? Also tracked at https://bugs.debian.org/789458 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 08:03:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 08:03:02 -0000 Subject: [GHC] #10553: powerpc: getEnvironment empty when run in GHCi In-Reply-To: <046.adcc18ef3ca28476b5b33aa794685929@haskell.org> References: <046.adcc18ef3ca28476b5b33aa794685929@haskell.org> Message-ID: <061.9bdcd60ef98aeaf4a4fd47887e784b0e@haskell.org> #10553: powerpc: getEnvironment empty when run in GHCi -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Ok, looks like it is fixed in 7.10.2-rc1. Sorry for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 11:36:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 11:36:23 -0000 Subject: [GHC] #10554: Replacing existing attachment with the same name doesn't work Message-ID: <045.2f4472be5df2a2cd30bde47cef4d48c1@haskell.org> #10554: Replacing existing attachment with the same name doesn't work -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 11:42:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 11:42:07 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.ac73fcc29d849613b21b0f98da257bfb@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): ghc -V The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150612 It seems that the order of the args determines if it succeeds or not. {{{ time ghc -fno-specialise -fforce-recomp -O2 Slice.hs [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, Slice.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150612 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_s1FS5 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 1668604 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug real 0m19.542s user 0m18.451s sys 0m0.901s bash-3.2$ time ghc -O2 -fno-specialise -fforce-recomp Slice.hs [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, Slice.o ) real 0m3.299s user 0m3.085s sys 0m0.158s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 11:47:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 11:47:21 -0000 Subject: [GHC] #10554: Replacing existing attachment with the same name doesn't work In-Reply-To: <045.2f4472be5df2a2cd30bde47cef4d48c1@haskell.org> References: <045.2f4472be5df2a2cd30bde47cef4d48c1@haskell.org> Message-ID: <060.17bdddfeb9fa89d4ee12c08d640efa9a@haskell.org> #10554: Replacing existing attachment with the same name doesn't work -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9675 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9675 Old description: New description: To reproduce: * download `T9675-max_bytes_used.2.png` * notice that it says `+RTS` in the legend * rename the file to `T9675-max_bytes_used.png` * add it as an attachment to this ticket, clicking "Replace existing attachment of the same name" * notice that the file `T9675-max_bytes_used.png` [https://ghc.haskell.org/trac/ghc/attachment/ticket/10554/T9675-max_bytes_used.png attached] to this ticket is still the old version, without the `+RTS` in the legend -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 12:06:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 12:06:12 -0000 Subject: [GHC] #10555: RULE left-hand side too complicated to desugar Message-ID: <046.f79ed2aea9404c40727abba6768bec30@haskell.org> #10555: RULE left-hand side too complicated to desugar -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: yes | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- GHC version 7.10.1.20150612 breaks the `fast-math` package, which compiled fine on GHC 7.10.1. To reproduce, run `cabal install fast-math`. {{{ Numeric/FastMath/Approximation.hs:60:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_X2 { __DEFAULT -> +## wild_X2 }) wild_00 } Orig lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_00 { __DEFAULT -> +## wild_00 }) wild_00 } Numeric/FastMath/Approximation.hs:63:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_X2 { __DEFAULT -> -## wild_X2 }) wild_00 } Orig lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_00 { __DEFAULT -> -## wild_00 }) wild_00 } Numeric/FastMath/Approximation.hs:103:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case divideFloat# y2 x of wild_00 { __DEFAULT -> (case divideFloat# y1 x of wild_X2 { __DEFAULT -> minusFloat# wild_X2 }) wild_00 } Orig lhs: case divideFloat# y2 x of wild_00 { __DEFAULT -> (case divideFloat# y1 x of wild_00 { __DEFAULT -> minusFloat# wild_00 }) wild_00 } ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150612 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired float commute left * To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 4004 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 Sun Jun 21 12:23:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 12:23:34 -0000 Subject: [GHC] #10555: RULE left-hand side too complicated to desugar In-Reply-To: <046.f79ed2aea9404c40727abba6768bec30@haskell.org> References: <046.f79ed2aea9404c40727abba6768bec30@haskell.org> Message-ID: <061.3ff6e2704fd438f23a19dcfc269a25fa@haskell.org> #10555: RULE left-hand side too complicated to desugar -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by yongqli: Old description: > GHC version 7.10.1.20150612 breaks the `fast-math` package, which > compiled fine on GHC 7.10.1. To reproduce, run `cabal install fast-math`. > > {{{ > > Numeric/FastMath/Approximation.hs:60:1: Warning: > RULE left-hand side too complicated to desugar > Optimised lhs: case /## y2 x of wild_00 { __DEFAULT -> > (case /## y1 x of wild_X2 { __DEFAULT -> +## wild_X2 > }) wild_00 > } > Orig lhs: case /## y2 x of wild_00 { __DEFAULT -> > (case /## y1 x of wild_00 { __DEFAULT -> +## wild_00 }) > wild_00 > } > > Numeric/FastMath/Approximation.hs:63:1: Warning: > RULE left-hand side too complicated to desugar > Optimised lhs: case /## y2 x of wild_00 { __DEFAULT -> > (case /## y1 x of wild_X2 { __DEFAULT -> -## wild_X2 > }) wild_00 > } > Orig lhs: case /## y2 x of wild_00 { __DEFAULT -> > (case /## y1 x of wild_00 { __DEFAULT -> -## wild_00 }) > wild_00 > } > > Numeric/FastMath/Approximation.hs:103:1: Warning: > RULE left-hand side too complicated to desugar > Optimised lhs: case divideFloat# y2 x of wild_00 { __DEFAULT -> > (case divideFloat# y1 x of wild_X2 { __DEFAULT -> > minusFloat# wild_X2 > }) > wild_00 > } > Orig lhs: case divideFloat# y2 x of wild_00 { __DEFAULT -> > (case divideFloat# y1 x of wild_00 { __DEFAULT -> > minusFloat# wild_00 > }) > wild_00 > } > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.1.20150612 for x86_64-unknown-linux): > Simplifier ticks exhausted > When trying RuleFired float commute left * > To increase the limit, use -fsimpl-tick-factor=N (default 100) > If you need to do this, let GHC HQ know, and what factor you needed > To see detailed counts use -ddump-simpl-stats > Total ticks: 4004 > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: GHC version 7.10.1.20150612 breaks the `fast-math` package, which compiled fine on GHC 7.10.1.20150519. To reproduce, run `cabal install fast-math`. {{{ Numeric/FastMath/Approximation.hs:60:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_X2 { __DEFAULT -> +## wild_X2 }) wild_00 } Orig lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_00 { __DEFAULT -> +## wild_00 }) wild_00 } Numeric/FastMath/Approximation.hs:63:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_X2 { __DEFAULT -> -## wild_X2 }) wild_00 } Orig lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_00 { __DEFAULT -> -## wild_00 }) wild_00 } Numeric/FastMath/Approximation.hs:103:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case divideFloat# y2 x of wild_00 { __DEFAULT -> (case divideFloat# y1 x of wild_X2 { __DEFAULT -> minusFloat# wild_X2 }) wild_00 } Orig lhs: case divideFloat# y2 x of wild_00 { __DEFAULT -> (case divideFloat# y1 x of wild_00 { __DEFAULT -> minusFloat# wild_00 }) wild_00 } ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150612 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired float commute left * To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 4004 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 Sun Jun 21 13:21:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 13:21:06 -0000 Subject: [GHC] #10555: RULE left-hand side too complicated to desugar In-Reply-To: <046.f79ed2aea9404c40727abba6768bec30@haskell.org> References: <046.f79ed2aea9404c40727abba6768bec30@haskell.org> Message-ID: <061.875dd711fd4fe10c2dba6a4172e2c6af@haskell.org> #10555: RULE left-hand side too complicated to desugar -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by yongqli): Possibly related: https://mail.haskell.org/pipermail/ghc- devs/2015-June/009271.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 17:49:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 17:49:03 -0000 Subject: [GHC] #10543: MacOS: validate fails on \u In-Reply-To: <047.a887440a0df817cb06caf9fc53c8c2c9@haskell.org> References: <047.a887440a0df817cb06caf9fc53c8c2c9@haskell.org> Message-ID: <062.4a2c3880708f45e0becc2675235aba5e@haskell.org> #10543: MacOS: validate fails on \u -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.10.1 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1004 -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => cpp * status: new => patch * differential: => Phab:D1004 Comment: Reproducible with: {{{ $ cat T10543.hs matchBuildTarget pkg = \utarget fexists -> undefined $ ghc -pgmP clang T10543.hs -fforce-recomp -cpp -Werror ...same error... }}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 18:19:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 18:19:02 -0000 Subject: [GHC] #10556: Add parsePattern entry point Message-ID: <049.1ec5d8db2610e1b9c74e8fbc78e5e7a3@haskell.org> #10556: Add parsePattern entry point -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The parser currently exposes several entry points but not one which parses patterns. It would be useful for me if the pattern parser was also exposed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 18:23:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 18:23:00 -0000 Subject: [GHC] #10556: Add parsePattern entry point In-Reply-To: <049.1ec5d8db2610e1b9c74e8fbc78e5e7a3@haskell.org> References: <049.1ec5d8db2610e1b9c74e8fbc78e5e7a3@haskell.org> Message-ID: <064.6d383eb47f6381458edc60777af26026@haskell.org> #10556: Add parsePattern entry point -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1005 -------------------------------------+------------------------------------- Changes (by mpickering): * cc: alanz (added) * status: new => patch * differential: => Phab:D1005 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 19:29:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 19:29:00 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.baab5a8a2b9b66a3605cd1d6e5dc0d9e@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Having recently seen how the `-O` option is implemented, it's actually not terribly surprising that it's order dependent. Essentially `-O2` is equivalent to a passing a bunch of individual `-f` options explicitly. `-f` options are themselves just flipping flags in the parser state and are therefore order dependent. I'll admit that this behavior is a bit surprising, but then again I'm not entirely sure how to improve the situation without sacrificing expressive power. I wonder how other compilers manage this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 19:45:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 19:45:21 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.f1464c09d96c186d75c0eda4f8730760@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): I think something needs to be changed. AFAIK, there is no documentation that it is order dependent. A language that is not order dependent should not have command line options that are! As a minimum if -O2 and -fno means -f and -fno and some remaining -f then the user should get an error message if the order is "wrong" and no error message if the order is right, i.e. -fno wins. At least, this is what I think off the top of my head from my naive viewpoint. I believe there is a ticket for an ER or task to improve command line options. I'll try to find it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 19:52:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 19:52:32 -0000 Subject: [GHC] #10556: Add parsePattern entry point In-Reply-To: <049.1ec5d8db2610e1b9c74e8fbc78e5e7a3@haskell.org> References: <049.1ec5d8db2610e1b9c74e8fbc78e5e7a3@haskell.org> Message-ID: <064.b4396f3ecdc79247caccb1ae7e1dfb3a@haskell.org> #10556: Add parsePattern entry point -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1005 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"38f374571290b8115ef5b82587ac2ec6c18e91f1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="38f374571290b8115ef5b82587ac2ec6c18e91f1" Add parsePattern parser entry point Reviewers: austin, thomie, alanz Reviewed By: thomie, alanz Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1005 GHC Trac Issues: #10556 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 19:59:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 19:59:36 -0000 Subject: [GHC] #10556: Add parsePattern entry point In-Reply-To: <049.1ec5d8db2610e1b9c74e8fbc78e5e7a3@haskell.org> References: <049.1ec5d8db2610e1b9c74e8fbc78e5e7a3@haskell.org> Message-ID: <064.ec29d5225c8285330e513bd5967b1819@haskell.org> #10556: Add parsePattern entry point -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1005 -------------------------------------+------------------------------------- Changes (by alanz): * status: patch => merge * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 20:06:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 20:06:05 -0000 Subject: [GHC] #10554: Replacing existing attachment with the same name doesn't work In-Reply-To: <045.2f4472be5df2a2cd30bde47cef4d48c1@haskell.org> References: <045.2f4472be5df2a2cd30bde47cef4d48c1@haskell.org> Message-ID: <060.f63da0bacd2a2b5cc15bdc57f478198a@haskell.org> #10554: Replacing existing attachment with the same name doesn't work -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: lowest | Milestone: Component: Trac & Git | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9675 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => lowest Comment: Seems to be just a cache thing, a few hours later the old file did get replaced. Maybe add a note to the attachment upload screen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 20:40:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 20:40:36 -0000 Subject: [GHC] #10557: Use `+RTS -G1` for more stable residency measurements Message-ID: <045.b69f224ec7b010fc435a2530f08e6526@haskell.org> #10557: Use `+RTS -G1` for more stable residency measurements -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Tests that measure `peak_megabytes_allocated` and `max_bytes_used` can be very sensitive to small changes in, well, just about anything: order of command line flags, what should be irrelevant compiler patches, minor changes in the test file to compile. From `Note [residency]` in `testsuite/tests/perf/compiler/all.T`: {{{ # Residency (peak_megabytes_allocated and max_bytes_used) is sensitive # to when the major GC runs, which makes it inherently inaccurate. # Sometime an innocuous change somewhere can shift things around such # that the samples occur at a different time, and the residency # appears to change (up or down) when the underlying profile hasn't # really changed. }}} I propose setting `+RTS -G1` for these tests. This seems to make them more robust to small changes, as can be seen in the following two graphs, adapted from the test for #9675: https://ghc.haskell.org/trac/ghc/attachment/ticket/9675/T9675-peak_megabytes_allocated.png https://ghc.haskell.org/trac/ghc/attachment/ticket/9675/T9675-max_bytes_used.png This shows the `peak_megabytes_allocated` and `max_bytes_used` as a function of the number fields when compiling a single record: {{{ data Foo = Foo { field1 :: Int -> Int , field2 :: Int -> Int ... }}} The default `GHC -O` line is wiggling up and down, while the `GHC -O +RTS -G1` line is nice and smooth, which is what we want. I don't know if making this change defeats the purpose of some tests, which is why I'm opening this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 20:47:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 20:47:09 -0000 Subject: [GHC] #10348: HEAD: `KnownNat` does not imply `Typeable` any more In-Reply-To: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> References: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> Message-ID: <063.c25c812b36e5cf7ee292d46ba92602c1@haskell.org> #10348: HEAD: `KnownNat` does not imply `Typeable` any more -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: diatchki Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by diatchki): I pushed a fix this morning, 4854fcea4f73897bbdcdfede382c826da7b64b97. Give it a go and let me know if you find a problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 21 21:02:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Jun 2015 21:02:24 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.961f740d43aef0c6b1047c24775993a9@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Sure, let's continue the command line parsing discussion on another issue. On the issue of the specialiser, it seems that cross-module specialisation generates a fairly large number of `Shape` dictionaries (along with its superclasses). `Shape` is defined thusly, {{{ class (Elt sh, Elt (Any sh), Repr.Shape (EltRepr sh)) => Shape sh where dim :: sh -> Int size :: sh -> Int ignore :: sh intersect :: sh -> sh -> sh toIndex :: sh -> sh -> Int fromIndex :: sh -> Int -> sh bound :: sh -> sh -> Boundary a -> Either a sh iter :: sh -> (sh -> a) -> (a -> a -> a) -> a -> a iter1 :: sh -> (sh -> a) -> (a -> a -> a) -> a rangeToShape :: (sh, sh) -> sh shapeToRange :: sh -> (sh, sh) shapeToList :: sh -> [Int] listToShape :: [Int] -> sh sliceAnyIndex :: sh -> Repr.SliceIndex (EltRepr (Any sh)) (EltRepr sh) () (EltRepr sh) }}} The most noticeable dictionaries one finds in the Core are for types of the form `(((), Int), Int)`. For instance, {{{ $s$fShape(,)_sby9 :: Data.Array.Accelerate.Array.Representation.Shape (((), Int), Int) $s$fShape(,)_sby9 = Data.Array.Accelerate.Array.Representation.D:Shape @ (((), Int), Int) $dEq_a9Zd $dSlice_a9Ze (Data.Array.Accelerate.Array.Representation.$fShape(,)_$cdim @ ((), Int) $dEq_a9Zd $dSlice_a9Ze $dShape_a9YB) ... $s$fShape(,)_$cdim_sbxD :: (((), Int), Int) -> Int $s$fShape(,)_$cdim_sbxD = \ _ -> case Data.Array.Accelerate.Array.Representation.dim @ ((), Int) $dShape_a9YB (undefined @ ((), Int)) of _ { GHC.Types.I# x_abe0 -> GHC.Types.I# (GHC.Prim.+# x_abe0 1) } -- along with implementations for the remaining functions of Shape }}} Along with the dictionary the specialiser also generates implementations for `Eq` and `ArrayElt` for these types. All of these are generated for all types up to `((((((((((), Int), Int), Int), Int), Int), Int), Int), Int), Int)`. In addition, one also finds `ArrayElt` dictionaries for tuples of the same shape but with `s/Int/()`, e.g. `(((), ()), ())`. One then finds `Show`, `Elt`, and `Shape` implementations for types of the form `(((Z :. Int) :. Int) :. Int)` for all types up to `(((((((((Z :. Int) :. Int) :. A) :. A) :. A) :. A) :. A) :. A)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 00:00:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 00:00:21 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.300f76744e34cccda9de2d9837f4eb8a@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D807 -------------------------------------+------------------------------------- Comment (by thomie): Here's another commit in the #8959 series: 6e4a75001fae1bf9251907d605b3f0b74da537cb {{{ Author: Joachim Breitner Date: Fri Jun 6 18:07:29 2014 +0200 Only use UnicodeSytanx pretty printing if the locale supports it using the same check as for unicode quotes. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 00:06:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 00:06:09 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.7bbdad4f43abd4d0e0c5b8b8afb24671@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: merge Priority: low | Milestone: 7.10.2 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D807 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge * milestone: 7.12.1 => 7.10.2 Comment: I think work is done here. int-e is asking for a merge to 7.10.2 of 6dd2765a300bb139b4ab67688dbc6f48de66969b -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 00:18:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 00:18:15 -0000 Subject: [GHC] #10543: MacOS: validate fails on \u In-Reply-To: <047.a887440a0df817cb06caf9fc53c8c2c9@haskell.org> References: <047.a887440a0df817cb06caf9fc53c8c2c9@haskell.org> Message-ID: <062.c117729d1e6db4d7b86fcb52d47a1626@haskell.org> #10543: MacOS: validate fails on \u -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.10.1 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1004 -------------------------------------+------------------------------------- Comment (by thomie): @trommler: could you try with the attached patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 00:31:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 00:31:52 -0000 Subject: [GHC] #10558: Alter type of parseDeclaration and parseTypeSignature entry points Message-ID: <049.362080c44bcdb3de80ad7a4b94d8a842@haskell.org> #10558: Alter type of parseDeclaration and parseTypeSignature entry points -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab: | D1007 | -------------------------------------+------------------------------------- Currently the type of the two mentioned entry points is {{{#!hs parseDeclaration :: P (OrdList (LHsDecl RdrName)) }}} and {{{#!hs parseTypeSignature :: P (Located (OrdList (LHsDecl RdrName))) }}} It turns out that in both cases, OrdList is always a singleton so the additional wrapping is redundant. I propose that the parser is modified in order to reflect this so that this is clearer to end users. The end result being that both entry points have type `P (LHsDecl RdrName)` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 00:31:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 00:31:58 -0000 Subject: [GHC] #10558: Alter type of parseDeclaration and parseTypeSignature entry points In-Reply-To: <049.362080c44bcdb3de80ad7a4b94d8a842@haskell.org> References: <049.362080c44bcdb3de80ad7a4b94d8a842@haskell.org> Message-ID: <064.43112a8aec80539820979bb75e082848@haskell.org> #10558: Alter type of parseDeclaration and parseTypeSignature entry points -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab: | D1007 -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 00:43:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 00:43:39 -0000 Subject: [GHC] #10558: Alter type of parseDeclaration and parseTypeSignature entry points In-Reply-To: <049.362080c44bcdb3de80ad7a4b94d8a842@haskell.org> References: <049.362080c44bcdb3de80ad7a4b94d8a842@haskell.org> Message-ID: <064.80b04ae57b3b4e0e362af0e5a923c17d@haskell.org> #10558: Alter type of parseDeclaration and parseTypeSignature entry points -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab: | D1007 -------------------------------------+------------------------------------- Comment (by mpickering): It might also be good to add a bit more documentation describing precisely what each of the parses does. For example, `parseTypeSignature` actually corresponds to `sigdecl` which is the rule for all signatures rather than just specifically type signatures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 05:43:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 05:43:35 -0000 Subject: [GHC] #10559: the 'impossible' happened while building stack Message-ID: <046.377c7156f15c8faf6fd87aaa77e340be@haskell.org> #10559: the 'impossible' happened while building stack -------------------------------------+------------------------------------- Reporter: barnaby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I ran stack update; stack install stack:latest It errored out and told me to mail you .. .... stack-0.0.3: build Completed all 122 actions. -- While building package stack-0.0.3 using: /Users/test/.stack/programs/x86_64-osx/ghc-7.10.1/bin/runhaskell -package=Cabal-1.22.2.0 -clear-package-db -global-package-db -package- db=/Users/test/.stack/snapshots/x86_64-osx/nightly-2015-06-21/7.10.1/pkgdb/ /var/folders/gj/0zl8brn57zsb78slcjmjywrw0000gn/T/stack14231/stack-0.0.3/Setup.hs --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.2.0/ build Process exited with code: ExitFailure 1 Logs have been written to: "/private/var/tmp/haskell/Moodler/Moodler /.stack-work/logs/stack-0.0.3.log" Configuring stack-0.0.3... Building stack-0.0.3... Preprocessing library stack-0.0.3... [ 1 of 53] Compiling Data.Set.Monad ( src/Data/Set/Monad.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Set/Monad.o ) [ 2 of 53] Compiling Network.HTTP.Download.Verified ( src/Network/HTTP/Download/Verified.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Network/HTTP/Download/Verified.o ) [ 3 of 53] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/System/Process/Log.o ) [ 4 of 53] Compiling Data.Attoparsec.Combinators ( src/Data/Attoparsec/Combinators.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Attoparsec/Combinators.o ) [ 5 of 53] Compiling Data.Maybe.Extra ( src/Data/Maybe/Extra.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Maybe/Extra.o ) [ 6 of 53] Compiling Stack.New ( src/Stack/New.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/New.o ) [ 7 of 53] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/System/Process/PagerEditor.o ) [ 8 of 53] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/System/Process/Read.o ) [ 9 of 53] Compiling System.Process.Run ( src/System/Process/Run.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/System/Process/Run.o ) [10 of 53] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Paths_stack.o ) [11 of 53] Compiling Path.IO ( src/Path/IO.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Path/IO.o ) [12 of 53] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Path/Find.o ) [13 of 53] Compiling Data.Aeson.Extended ( src/Data/Aeson/Extended.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Aeson/Extended.o ) [14 of 53] Compiling Network.HTTP.Download ( src/Network/HTTP/Download.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Network/HTTP/Download.o ) [15 of 53] Compiling Stack.Types.PackageName ( src/Stack/Types/PackageName.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/PackageName.o ) [16 of 53] Compiling Stack.Types.Docker ( src/Stack/Types/Docker.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/Docker.o ) [17 of 53] Compiling Stack.Types.FlagName ( src/Stack/Types/FlagName.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/FlagName.o ) [18 of 53] Compiling Stack.Types.Version ( src/Stack/Types/Version.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/Version.o ) [19 of 53] Compiling Data.Binary.VersionTagged ( src/Data/Binary/VersionTagged.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Binary/VersionTagged.o ) [20 of 53] Compiling Stack.Types.PackageIdentifier ( src/Stack/Types/PackageIdentifier.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/PackageIdentifier.o ) [21 of 53] Compiling Stack.Types.GhcPkgId ( src/Stack/Types/GhcPkgId.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/GhcPkgId.o ) [22 of 53] Compiling Stack.Types.BuildPlan ( src/Stack/Types/BuildPlan.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/BuildPlan.o ) [23 of 53] Compiling Stack.Types.Config ( src/Stack/Types/Config.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/Config.o ) src/Stack/Types/Config.hs:12:1: Warning: The import of ?<*>, pure, <$>? from module ?Control.Applicative? is redundant [24 of 53] Compiling Stack.Constants ( src/Stack/Constants.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Constants.o ) [25 of 53] Compiling Stack.Types ( src/Stack/Types.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types.o ) [26 of 53] Compiling Stack.Package ( src/Stack/Package.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Package.o ) [27 of 53] Compiling Stack.Exec ( src/Stack/Exec.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Exec.o ) [28 of 53] Compiling Stack.Build.Types ( src/Stack/Build/Types.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Build/Types.o ) [29 of 53] Compiling Stack.GhcPkg ( src/Stack/GhcPkg.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/GhcPkg.o ) [30 of 53] Compiling Stack.PackageDump ( src/Stack/PackageDump.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/PackageDump.o ) src/Stack/PackageDump.hs:316:22: Warning: In the use of ?S.breakByte? (imported from Data.ByteString): Deprecated: "It is an internal function and should never have been exported. Use 'break (== x)' instead. (There are rewrite rules that handle this special case of 'break'.)" [31 of 53] Compiling Stack.Path ( src/Stack/Path.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Path.o ) [32 of 53] Compiling Stack.Build.Cache ( src/Stack/Build/Cache.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Build/Cache.o ) [33 of 53] Compiling Control.Concurrent.Execute ( src/Control/Concurrent/Execute.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Control/Concurrent/Execute.o ) [34 of 53] Compiling Stack.Build.Doc ( src/Stack/Build/Doc.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Build/Doc.o ) [35 of 53] Compiling Stack.Upload ( src/Stack/Upload.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Upload.o ) src/Stack/Upload.hs:29:1: Warning: The import of ?Control.Applicative? is redundant except perhaps to import instances from ?Control.Applicative? To import instances alone, use: import Control.Applicative() [36 of 53] Compiling Stack.Docker.GlobalDB ( src/Stack/Docker/GlobalDB.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Docker/GlobalDB.o ) [37 of 53] Compiling Stack.Types.Internal ( src/Stack/Types/Internal.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/Internal.o ) [38 of 53] Compiling Stack.Types.StackT ( src/Stack/Types/StackT.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/StackT.o ) [39 of 53] Compiling Stack.PackageIndex ( src/Stack/PackageIndex.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/PackageIndex.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/gj/0zl8brn57zsb78slcjmjywrw0000gn/T/ghc27479_0/libghc27479_197.dylib, 5): Symbol not found: _stackzu7QSuU95iv0I3hQSByROmsn_SystemziProcessziLog_showProcessArgDebug_closure Referenced from: /var/folders/gj/0zl8brn57zsb78slcjmjywrw0000gn/T/ghc27479_0/libghc27479_197.dylib Expected in: flat namespace in /var/folders/gj/0zl8brn57zsb78slcjmjywrw0000gn/T/ghc27479_0/libghc27479_197.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 07:16:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 07:16:41 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.ba11ca769260b5b8af563e55f8c23d45@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): * There is, so far as I can see, no documentation of the fact that command-line arguments are applied in-order (so `-fspecialise -fno- specialise` has the same effect as `-fno-specialise`). '''Ben''': could you add documentation of this, to the preamble of 4.10 in the user manual? In 4.10.1, when discussing `-O`, stress the order-dependence with individual flags. * Let's debate whether or not this order dependence is a good design on another ticket. * I think we have a workaround for this particular problem (`-fno- specialise`) * But as Ben mentions, we still don't know why it leads to such a stunning blow-up, so let's keep looking for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 07:18:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 07:18:20 -0000 Subject: [GHC] #10557: Use `+RTS -G1` for more stable residency measurements In-Reply-To: <045.b69f224ec7b010fc435a2530f08e6526@haskell.org> References: <045.b69f224ec7b010fc435a2530f08e6526@haskell.org> Message-ID: <060.bb5ff6852d8aa30d7a07a30b423be795@haskell.org> #10557: Use `+RTS -G1` for more stable residency measurements -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Sounds like a jolly good idea to me. If it defeats the purpose for something, we can change the something -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 07:27:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 07:27:35 -0000 Subject: [GHC] #10558: Alter type of parseDeclaration and parseTypeSignature entry points In-Reply-To: <049.362080c44bcdb3de80ad7a4b94d8a842@haskell.org> References: <049.362080c44bcdb3de80ad7a4b94d8a842@haskell.org> Message-ID: <064.c2d3265083db94bebdd700efbf4c3499@haskell.org> #10558: Alter type of parseDeclaration and parseTypeSignature entry points -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab: | D1007 -------------------------------------+------------------------------------- Comment (by simonpj): Simplifying the type and adding documentation: both good with me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 08:00:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 08:00:11 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways Message-ID: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 Revisions: | -------------------------------------+------------------------------------- The `-O[012]` and `-f*` flags are both implemented by manipulating a set of flags in `DynFlags`. These manipulations occur in the order that the flags occur in the command line. This leads to some rather surprising behavior. For instance, if the user wants to compile with optimization but specifically wants to disable specialisation, they might enter `-fno- specialise -O1`. This, however, would not do what the user expects as `-O1` implies `-fspecialise`, overriding the first flag. This is surprising and poorly documented behavior at best. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 08:02:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 08:02:19 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.f792bf5ffccda89f06c02500bdd9c7e7@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > The `-O[012]` and `-f*` flags are both implemented by manipulating a set > of flags in `DynFlags`. These manipulations occur in the order that the > flags occur in the command line. This leads to some rather surprising > behavior. > > For instance, if the user wants to compile with optimization but > specifically wants to disable specialisation, they might enter `-fno- > specialise -O1`. This, however, would not do what the user expects as > `-O1` implies `-fspecialise`, overriding the first flag. > > This is surprising and poorly documented behavior at best. New description: The `-O[012]` and `-f*` flags are both implemented by manipulating a set of flags in `DynFlags`. These manipulations occur in the order that the flags occur in the command line. This leads to some rather surprising behavior. For instance, if the user wants to compile with optimization but specifically wants to disable specialisation, they might enter `-fno- specialise -O1`. This, however, would not do what the user expects as `-O1` implies `-fspecialise`, overriding the first flag. This is surprising and poorly documented behavior at best. See the later comments of #10491 which lead to this ticket. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 08:04:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 08:04:45 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.a3c14c057125a1fbfbb6ed655897c490@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I've opened #10560 to discuss the command-line parser behavior. George, perhaps you want to write down some thoughts there (or just paste Comment 31 from above for reference)? Simon, documentation is on its way. I'll be looking at the simplifier blow-up shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 08:06:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 08:06:01 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.1e966b729a85dfb1d06616c2f68a4a75@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): A naive solution would be to process meta-flags before specific flags, regardless of their order on the command line. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 08:13:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 08:13:02 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.db20fab2d189054d16ee8b92d437e95f@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I don?t find that too surprising, and the order dependency is often used in build tools, which assume that you can always override earlier choices by ''appending'' to the command line. But it could be documented better, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 08:16:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 08:16:05 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.ea5e43420adebe21fa78d4b262715ce2@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): Perhaps a warning would be in order, if -Ox overrode an earlier -fx? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 08:41:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 08:41:08 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.18da9de1fa899ef661e61d2fdb387e9e@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I have opened Phab:D1008 to document the current behavior. nomeata, I find the fact that the `-f` flags are order dependent to be perfectly acceptable. Moreover, I don't know how else one would handle this without losing expressive power. I think the real issue is the fact that `-O` and `-f` can silently conflict and one has know way of knowing this other than looking at `optLevelFlags` in the source. This tripped up both me and George in #10491. I think gidyn's suggestion of warning is a nice solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 08:45:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 08:45:18 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.b2c7f5c943a2b423acfaae80b011102e@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by svenpanne): I would even go further than Joachim in comment 3: I would open a ticket if the commandline arguments were *not* order-dependent, this is by far the most common way of doing things for lots of tools/compilers. I would even object to the idea of emitting a warning if something is overridden, even in the case of meta flags like -Ox (might be OK to enable the warning by another flag, but definitely not by default). Warnings are part of the "API" of a compiler, and I bet many automatic builds would be broken by such an ad-hoc change for no good reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 08:47:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 08:47:37 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.5bb814fa44412dc9a836e4445782ae80@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): Overriding -fx with a subsequent -Ox is arguably bad practice, as it is not clear which flags (if any) are being overridden. It should be overridden with the corresponding -fnot-x. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 09:16:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 09:16:51 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.1c05afe323fe40303ca0661c41ba301c@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): One thing in the post-explosion Core that I've noticed is some extremely large bindings of type, {{{#!hs lvl_scb5 :: forall a_aaJ9. (((((((Z :. Int) :. Int) :. A) :. A) :. A) :. A) :. A) :. Int -> (((((((Z :. Int) :. Int) :. A) :. A) :. A) :. A) :. A) :. Int -> Data.Array.Accelerate.Type.Boundary a_aaJ9 -> Either a_aaJ9 ((((((((Z :. Int) :. Int) :. A) :. A) :. A) :. A) :. A) :. Int) }}} with variously sized indices. The size of the binding (determined very roughly by the number of lines in the textual Core representation) scales very strongly with the size of the index, * `((((Z :. Int) :. Int) :. A) :. A) :. Int`: 11777 lines * `(((((Z :. Int) :. Int) :. A) :. A) :. A) :. Int`: 34246 lines * `((((((Z :. Int) :. Int) :. A) :. A) :. A) :. A) :. Int`: 108745 lines * `(((((((Z :. Int) :. Int) :. A) :. A) :. A) :. A) :. A) :. Int`: 351252 lines -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 09:34:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 09:34:12 -0000 Subject: [GHC] #2531: Prune duplicates in ghci history In-Reply-To: <045.a0871c51adeff1456b5bd9c24f43a05b@haskell.org> References: <045.a0871c51adeff1456b5bd9c24f43a05b@haskell.org> Message-ID: <060.5e507104a6d09bc34449ac911f22c9aa@haskell.org> #2531: Prune duplicates in ghci history -------------------------------------+------------------------------------- Reporter: venkat | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.12.1 Component: GHCi | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"b5a2e8763fcf0e2b4c57e12f2b2e5817e5ce9df0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b5a2e8763fcf0e2b4c57e12f2b2e5817e5ce9df0" Documentation: add section on .haskeline file (#2531) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 09:38:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 09:38:58 -0000 Subject: [GHC] #2531: Prune duplicates in ghci history In-Reply-To: <045.a0871c51adeff1456b5bd9c24f43a05b@haskell.org> References: <045.a0871c51adeff1456b5bd9c24f43a05b@haskell.org> Message-ID: <060.f331e660758d999dcf6d1a9fe187a05e@haskell.org> #2531: Prune duplicates in ghci history -------------------------------------+------------------------------------- Reporter: venkat | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.12.1 Component: GHCi | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: The user's guide now mentions that you can prune duplicates from GHCi's history by changing the .haskeline file, with a link to the Haskeline documentation. No need to reimplement this feature in GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 10:59:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 10:59:50 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.98fa898d747b6ae2a6d77018058e1489@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): To a naive users who doesn't know how the -O* options are implemented it is very surprising. A language that is not order dependent should not have command line options that are! Haskell differs from other languages thus I don't know why Haskell command line option processing needs to agree with them. In any case we definitely need to document the current behavior of 7.10. I like Gidyn's suggestion above to process meta-flags before specific flags, regardless of their order on the command line. However as Ben writes above, perhaps it is best not to concentrate on order but on "the fact that -O and -f can silently conflict and one has know way of knowing this" Perhaps the simplest example of the issue is that the following do different things and there is currently no documentation that explains what that is. I think a warning or error would be appropriate. ghc -fspecialise -fno-specialise .hs ghc -fno-specialise -fspecialise .hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 11:09:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 11:09:06 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.7f16f53741bf6c0318f09cd3dce4e672@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): Replying to [comment:34 bgamari]: Ben, Simon thanks for explaining this. I've added my comments to #10560. Sorry to distract you from the bug here. I was just surprised by the command line option issue. Adding the documentation will definitely be a big help. > I've opened #10560 to discuss the command-line parser behavior. George, perhaps you want to write down some thoughts there (or just paste Comment 31 from above for reference)? > > Simon, documentation is on its way. > > I'll be looking at the simplifier blow-up shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 11:24:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 11:24:12 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.62fe9c1996e65ccc5084e42d6f1aaa23@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by svenpanne): I think we should follow the principle of least surprise, and IMHO if the order is relevant, it *is* least surprising to all people who know various tools/compilers/etc. I would strongly object any change regarding this, even adding warnings (will break builds, see above) or handling meta flags differently. If it helps, think of the command line as a list of functions modifying the flag state and GHC as doing a foldl over it, starting with its default state. :-) Making the documentation more explicit/clearer is perfectly fine, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 11:57:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 11:57:31 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.9dbc5f268324d6a692f03c1d86dd9cd2@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): If such a warning does actually break any builds, it will be immediately obvious why, and presumably easy to fix. The same cannot be said for someone trying to understand why GHC isn't behaving as expected because some flag silently undid the effect of an earlier flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 12:08:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 12:08:01 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.647af15c523c53d7b6080b6d0e21944e@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by svenpanne): It's totally irrelevant if it's easy to fix: The proposed change is completely surprising, unnatural and ad hoc. When you intend to break things, you'll better have a very good reason for doing so, and I don't think that this is the case here. It is the first time that I've heard that order-dependent flags are considered a problem, quite the opposite: Making them behave differently would confuse people and cause useless work. Later options override/modify previous options, that's how most commandline tools work. By all means, improve the documentation, but leave the flag processing as it is... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 12:14:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 12:14:39 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.9b6430681a2831df337357ec21a37a2d@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): It's "completely surprising, unnatural and ad hoc" that a warning should be issued when a flag silently undoes the effect of an earlier flag? Additionally, we don't even know if any actual build system will be broken by this. Only if somebody's using a script which breaks if unexpected compiler warnings are encountered, and they're calling GHC with "conflicting" flags in a problematic order. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 12:15:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 12:15:45 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.f11983727b3a831058af9076c150bc92@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): At this point I'm pretty certain that `bound` for the deep `(:.)` instances is the culprit here. For instance, the implementation for `((((((((Z :. Int) :. Int) :. A) :. A) :. A) :. A) :. A) :. A)` grows from `{terms: 10, types: 59, coercions: 147}` to `{terms: 1,375,016, types: 1,282,534, coercions: 14,151}` in one simplifier iteration (phase 0). Let's follow the specialized implementation of `bound` for `((Z .: Int) :. Int) :. Int` which clearly exhibits this explosion, but on a much smaller scale (from `{terms: 10, types: 23, coercions: 33}` to `{terms: 2,789, types: 2,743, coercions: 78}` over the same simplifier iteration; it's not clear that the smaller types are exploding quite as much, namely they still have 0 coercions after the simplifier does its work). It starts simple enough, {{{#!hs $s$fShape:._$cbound_sbQv :: forall a_aaK6. ((Z :. Int) :. Int) :. Int -> ((Z :. Int) :. Int) :. Int -> Data.Array.Accelerate.Type.Boundary a_aaK6 -> Either a_aaK6 (((Z :. Int) :. Int) :. Int) $s$fShape:._$cbound_sbQv = \ (@ a142_abqH) (w4_abqI :: ((Z :. Int) :. Int) :. Int) (w5_abqJ :: ((Z :. Int) :. Int) :. Int) (w6_abqK :: Data.Array.Accelerate.Type.Boundary a142_abqH) -> Data.Array.Accelerate.Array.Sugar.$w$cbound @ ((Z :. Int) :. Int) $s$fElt:._sbKS ($s$fShape(,)_sbz9 `cast` ...) @ a142_abqH w4_abqI w5_abqJ w6_abqK }}} This gets simplified to this, https://gist.github.com/bgamari/c6e360478b0e98df62e3. More analysis shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 12:42:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 12:42:38 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.fd0b6aef7c349abe20f75aa7f75cfa92@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): George, it would be great if you could have a quick look at D1009 and confirm that the proposed language it addresses your concerns (suggestions for improvement would also be appreciated). Sven, I think we agree that the left-to-right parsing is standard and expected. The problem here is the fact that there is no sign to the user that `-f` and `-O` should interact. This spooky action at a distance has the very real potential to trip up users and has already masked the effectiveness of a workaround to a known bug. However, I can also see that it's not always possible to ensure that `-O` is placed first in the command line and making users endure a warning in this case is unfortunate. However, I think this is outweighed by the danger of a user not knowing which optimizations the compiler is actually performing. Trusting that they we see and remember a note in the documentation does not seem like a strong enough measure here. If the warning really is a problem we could issue it only if the last flag to set a given option was `-O`. This would allow the user to silence the warning by adding an additional `-f`, reaffirming the value set by `-O`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 13:08:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 13:08:10 -0000 Subject: [GHC] #10348: HEAD: `KnownNat` does not imply `Typeable` any more In-Reply-To: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> References: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> Message-ID: <063.e8287cb1ed56d29be0c64abd914996c3@haskell.org> #10348: HEAD: `KnownNat` does not imply `Typeable` any more -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: diatchki Type: bug | Status: closed Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by heisenbug): * status: new => closed * resolution: => fixed Comment: Replying to [comment:8 diatchki]: > I pushed a fix this morning, 4854fcea4f73897bbdcdfede382c826da7b64b97. Give it a go and let me know if you find a problems. Your fix solves my compilation problems, thanks! It will take some days to have my testing done, but I anticipate no problems. I'll close this PR for now, possibly reopening it of some related issues remain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 13:29:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 13:29:28 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.a40e26af2fe2027f39a03ba4099afdd8@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Let's look at `bound` more closely, {{{#!hs -- |Apply a boundary condition to an index. bound :: sh -> sh -> Boundary a -> Either a sh }}} It takes the size of an array, an index, and a `Boundary a` value describing how lookups falling outside of the array should be handled. The result is either the index that should be looked up or a fixed value. In light of this it seems clear where the deep case analyses appearing in the simplified `$s$fShape:._$cbound_sbQv` are coming from: the compiler is expanding tests for whether each index falls within the array. This test being replicated can be found here https://github.com/AccelerateHS/accelerate/blob/release/0.15/Data/Array/Accelerate/Array/Representation.hs#L110. Interestingly enough, the `master` branch (5803c5e566a0647139523f2aad06081dc2818ef2) decides not to inline any of the `Data.Array.Accelerate.Array.Sugar.$w$cbound` occurrences, which is why it is able to finish. Interestingly enough the default implementation `Data.Array.Accelerate.Array.Sugar.bound` is not marked as `INLINEABLE` and marking it as `NOINLINE` allows GHC 7.10.2 to compile. Likewise, marking `bound` as `INLINE` on `master` produces a blow-up similar to what we see with 7.10 (actually it does even worse, running out of simplifier ticks even with `-fsimpl-tick-factor=150`). I suppose that GHC 7.10 probably decides on its own that it should be `INLINEABLE` but `master` does not, resulting in the observed difference. Regardless, it does seem as though the Accelerate folks would want a function like `bound` to be inlined (robertce, perhaps you could comment here?). Perhaps the real bug here is our inability to produce a reasonable amount of optimized code for this function? That being said, the definition of `bound` isn't exactly conducive to efficient implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 13:44:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 13:44:41 -0000 Subject: [GHC] #10348: HEAD: `KnownNat` does not imply `Typeable` any more In-Reply-To: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> References: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> Message-ID: <063.ca8104e9ed84472a3d38d317b13daf63@haskell.org> #10348: HEAD: `KnownNat` does not imply `Typeable` any more -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: diatchki Type: bug | Status: closed Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Gabor Greif ): In [changeset:"e60dbf30adfcc0ba90ed9271239c0c8a7bc14f06/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e60dbf30adfcc0ba90ed9271239c0c8a7bc14f06" Check KnownSymbol => Typeable deduction verifying fix for #10348 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 14:51:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 14:51:23 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.59614783a1689cdbe8caf4eb6c5439fd@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by robertce): Replying to [comment:38 bgamari]: > Regardless, it does seem as though the Accelerate folks would want a function like `bound` to be inlined (robertce, perhaps you could comment here?). Perhaps the real bug here is our inability to produce a reasonable amount of optimized code for this function? That being said, the definition of `bound` isn't exactly conducive to efficient implementation. It's actually not terribly important that `bound` is inlined for Accelerate. We achieve high-performance by generating CUDA C or LLVM IR from our DSL rather than having fast Haskell code. The functions in `Shape`, like `bound`, are primarily used in our (slow) reference interpreter. If necessary, we could just put a `NOINLINE` pragma on `bound` or add an `-fno-specialse` to the top of any files affected. I guess what we really would like is to just not have such an explosion when something like `bound` is defined in the way it is. Having GHC figure out optimised code for it is not something I see us having any immediate need for. By the way, thanks for looking at this and tracking it down so quickly. Sorry I couldn't have been more help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 15:23:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 15:23:21 -0000 Subject: [GHC] #10522: Add UInfixT, like UInfixE or UInfixP but for types In-Reply-To: <045.117758279834e73fff10891f1400af9d@haskell.org> References: <045.117758279834e73fff10891f1400af9d@haskell.org> Message-ID: <060.b9341498f97f33ec15c36396fb6d3f58@haskell.org> #10522: Add UInfixT, like UInfixE or UInfixP but for types -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Without looking at the code myself, this sounds entirely reasonable to me. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 15:23:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 15:23:55 -0000 Subject: [GHC] #10094: Template Haskell cannot represent type wildcards In-Reply-To: <049.6629ff791e291b2d66323173df5c56f5@haskell.org> References: <049.6629ff791e291b2d66323173df5c56f5@haskell.org> Message-ID: <064.0bc5d66884cb3c2879a2d616ff94723d@haskell.org> #10094: Template Haskell cannot represent type wildcards -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9879, #10548 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: adamgundry => * related: #9879 => #9879, #10548 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 15:24:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 15:24:24 -0000 Subject: [GHC] #10548: Support PartialTypeSignatures in Template Haskell In-Reply-To: <045.2df5e13492bce560a66b130aa6f59e92@haskell.org> References: <045.2df5e13492bce560a66b130aa6f59e92@haskell.org> Message-ID: <060.696451a4c1912a074ce56a8dadb87e6f@haskell.org> #10548: Support PartialTypeSignatures in Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Without looking at the code myself, this sounds entirely reasonable to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 15:35:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 15:35:58 -0000 Subject: [GHC] #10548: Support PartialTypeSignatures in Template Haskell In-Reply-To: <045.2df5e13492bce560a66b130aa6f59e92@haskell.org> References: <045.2df5e13492bce560a66b130aa6f59e92@haskell.org> Message-ID: <060.083991e8cd4d32c87af29e90760d6446@haskell.org> #10548: Support PartialTypeSignatures in Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: thomasw, adamgundry (added) Comment: I'd also like this (see #10094). I looked at it briefly and it didn't seem to be completely trivial, because the implementation traversed types to collect wildcards prior to renaming the type, and the presence of TH type splices means that it's hard to know up front whether wildcards will be present. But 058af6c90a0e8d122f2d1339b6b4fd0b5ec83d05 may have made it easier. Perhaps thomasw can advise further? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 15:46:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 15:46:48 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.7920bfb624f3fe8573cc9fc33d67949e@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Good question. In principle there are classes at other kinds `Functor1`, `Functor2` (not part of a systematic naming scheme) for which you can write {{{ instance (Functor1 (f :: (* -> *) -> *), Functor2 (g :: * -> (* -> *))) => Functor (Compose f g) }}} but GHC will probably never be able to derive that instance. (Maybe if eventually get a polykinded `Functor`, but then the deriving clause could produce a kind-polymorphic instance and there is no problem.) So, I don't see any real issue with having ordinary `deriving` producing an instance for `Functor (Compose * f g)`, to write the kind variable explicitly. However, it's certainly more clear-cut with the standalone deriving declaration, since then the kind variable is determined by the context which you wrote explicitly. I think GHC may have some general principles regarding ordinary deriving declarations and how they are less general than standalone deriving, but I never understood the exact details (aside from the fact that a standalone deriving declaration lets you specify the context). Maybe they don't have anything to say about this case with a kind variable anyways. Not sure where that leaves this ticket; the behavior of HEAD is a bug that I'll file separately. Maybe a feature request dependent on the resolution of that bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 15:47:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 15:47:03 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.a27b583b576b7cedd9ceedb23eb28c83@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:39 robertce]: > > It's actually not terribly important that `bound` is inlined for Accelerate. We achieve high-performance by generating CUDA C or LLVM IR from our DSL rather than having fast Haskell code. The functions in `Shape`, like `bound`, are primarily used in our (slow) reference interpreter. If necessary, we could just put a `NOINLINE` pragma on `bound` or add an `-fno-specialse` to the top of any files affected. Adding a `NOINLINE` would be the least intrusive solution. We also will have a `-fno-cross-module-specialise` in 7.10.2 which also works around the issue but it obviously won't be available in earlier releases. > I guess what we really would like is to just not have such an explosion when something like `bound` is defined in the way it is. Having GHC figure out optimised code for it is not something I see us having any immediate need for. There are "simple" steps I can imagine we could take to avoid these explosions (e.g. stop inlining into an expression after it has reached some size) but there are likely Good Reasons (TM) why we don't currently do this. Simon, perhaps you could comment here? > By the way, thanks for looking at this and tracking it down so quickly. Sorry I couldn't have been more help. No worries! I'm glad I could help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 15:50:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 15:50:48 -0000 Subject: [GHC] #10561: "deriving (Functor)" on a polykinded type produces ill-kinded instance Message-ID: <047.92b5c73d11a6ce75dd9ba55b0b432115@haskell.org> #10561: "deriving (Functor)" on a polykinded type produces ill-kinded instance -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Arose in #10524, and new since 7.10. {{{ rwbarton at morphism:/tmp$ ~/ghc/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20150615: http://www.haskell.org/ghc/ :? for help Prelude> :set -XPolyKinds -XDeriveFunctor -ddump-deriv -fprint-explicit- kinds Prelude> newtype Compose f g a = Compose (f (g a)) deriving Functor ==================== Derived instances ==================== Derived instances: instance forall (k_and :: BOX) (f_ane :: k_and -> *) (g_anf :: * -> k_and). (GHC.Base.Functor f_ane, GHC.Base.Functor g_anf) => GHC.Base.Functor (Ghci1.Compose k_and * f_ane g_anf) where GHC.Base.fmap f_ang (Ghci1.Compose a1_anh) = Ghci1.Compose (GHC.Base.fmap (GHC.Base.fmap f_ang) a1_anh) Generic representation: Generated datatypes for meta-information: Representation types: Prelude> :i GHC.Base.Functor class Functor (f :: * -> *) where [...] }}} The context `(GHC.Base.Functor f_ane, GHC.Base.Functor g_anf)` is ill- kinded except when `k_and = *`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 15:51:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 15:51:24 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.32987186b5d9c7232a88039d034a67f2@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10561 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #10561 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 16:03:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 16:03:57 -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.126c608af30bfd71ddf5e4ea4e7576db@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: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:2 spinda]: > Attempt at a rough specification: Thanks for putting this together. It's usually best to put this sort of specification on a (fresh) wiki page, so it can evolve more easily that is possible in a comment chain. A few reactions to the spec: - The current module's list of exported names might include names that are not in scope, due to top-level splices. Recall that in a top-level splice, definitions below the splice are not yet in scope, yet might be mentioned in an export list. And there might be exported names that there is no way to know about: for example, if the export list says `T(..)` and `T`'s definition is below a top-level splice, I doubt strongly GHC knows what constructors are in `T` when processing the top-level splice. - Rename `nestedNames` to `localNames`? - `parentNames` is underspecified. (What is returned within a type splice within an expression? What about a `let`-bound expression? What about in patterns?) I further believe that any tight specification will be woefully long and intricate. What is the expected use case of such a function? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 17:32:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 17:32:02 -0000 Subject: [GHC] #10551: dynwrapper points to wrong paths on Windows In-Reply-To: <045.79129e7f0ae414856614a351b14b84aa@haskell.org> References: <045.79129e7f0ae414856614a351b14b84aa@haskell.org> Message-ID: <060.eb01a4e0881cf764516e1e82eebb9f88@haskell.org> #10551: dynwrapper points to wrong paths on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1001 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"6c5a66a225fcd65eb3abe32cc2128b0b90440451/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6c5a66a225fcd65eb3abe32cc2128b0b90440451" Fix #10551 by using LIB_NAMES. Summary: (NB: this code is dead at the moment since Windows is not built dynamically.) Signed-off-by: Edward Z. Yang Test Plan: none Reviewers: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1001 GHC Trac Issues: #10551 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 17:33:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 17:33:16 -0000 Subject: [GHC] #10551: dynwrapper points to wrong paths on Windows In-Reply-To: <045.79129e7f0ae414856614a351b14b84aa@haskell.org> References: <045.79129e7f0ae414856614a351b14b84aa@haskell.org> Message-ID: <060.25b3080e4eb6ceca9492cce19e2c2a6c@haskell.org> #10551: dynwrapper points to wrong paths on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.10.2-rc1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1001 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 18:36:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 18:36:45 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.b2dc51b26580965ed3b7068faa005b01@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): `gcc` does not care whether you put the `-fno` flag before or after the `-Ox` flag. {{{ $ gcc --version gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 }}} {{{ $ cat test.c int factorial(int x) { if (x > 1) return x * factorial(x-1); else return 1; } }}} {{{ $ gcc test.c -S && grep call test.s call factorial $ gcc test.c -S -O2 && grep call test.s $ gcc test.c -S -O2 -fno-optimize-sibling-calls && grep call test.s call factorial $ gcc test.c -S -fno-optimize-sibling-calls -O2 && grep call test.s call factorial }}} This seems right to me. Sven, don't you think it would be least confusing to users if we followed `gcc` on this one. To George: {{{ ghc -fspecialise -fno-specialise .hs ghc -fno-specialise -fspecialise .hs }}} Please open a separate ticket if you want a warning for these. It's related to this ticket, but I think separating these will benefit the discussion here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 19:46:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 19:46:18 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.d9d1f9190bfb1c83f65eb2889eec9e6f@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): The parts of this I feel strongly about are * GHC should never warn about a command line that is valid. It will just cause too many headaches for build systems. The effects of options should be clearly documented and then GHC should do what the user asks without any second-guessing. If a combination of options really doesn't make sense, then it should be an error and not a warning. * `-ffoo -fno-foo` and `-fno-foo -ffoo` (and `-O1 -O0`, etc.) should be valid with the last flag taking priority, as is the case today. I'm not really qualified to comment on how obvious the current behavior of `-fno-specialise -O1` is (it's obvious to me, but I've had the dubious pleasure of reading through DynFlags.hs on many occasions). I also can't think of a use case where the rule suggested in comment:2 "process all `-O` flags before all `-f` flags" would prevent one from doing something useful. So it sounds OK to me. But no warnings please! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 19:55:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 19:55:24 -0000 Subject: [GHC] #10550: Drop truncated package name prefix from package keys In-Reply-To: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> References: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> Message-ID: <060.cb3adb32dc7c9dd18cfff4906ab106e5@haskell.org> #10550: Drop truncated package name prefix from package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Package system | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Backwards compatibility considerations: GHC 7.10.1/7.10.2 will ship with libraries that are installed as `ghcpr_8TmvWUcS1U1IKHT0levwg3`, so Cabal will need to continue to understand this format. However, GHC is indifferent to how you pick future `-this-package-key`, so Cabal can simply generate `8TmvWUcS1U1IKHT0levwg3` for any subsequent installations and GHC wouldn't mind. (Old Cabal would not be able to read the package database however, because the parser is not setup to understand `8TmvWUcS1U1IKHT0levwg3`, but `ghc-pkg` doesn't validate the format so this would simply translate into not being able to use Cabal to manage a more recent package database, which I think already applies.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 20:07:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 20:07:07 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.74207ee0ae94880c03a49c4b8535e854@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by rwbarton): Just for context, what kind of configuration is this? e.g. DYNAMIC_GHC_PROGRAMS=YES/NO (seems both were mentioned in the comments, so maybe it is broken for both)? Registerised (with LLVM) or unregisterised? If registerised, then does the unregisterised version work? I think ghci at least used to work in some configuration on ARM, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 22:41:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 22:41:00 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.d2da16610583fd7963e6d1637c023f19@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm generally in favour of following gcc; that is, to make the fine-grain flags take priority over the -Ox bundles, regardless of order. (I thought we ''were'' following gcc, so it's a surprise to find that we are not.) I'm a bit concerned about changing behavior though. It's an un-forced change that may disrupt some users. I don't really know how to reconcile these two thoughts. Perhaps someone would like to float the idea on a more widely-read forum (ghc-users, #haskell IRC) and seek opinions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 23:04:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 23:04:21 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.f2d358a94f0024f39048bf79ef9ecf45@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Interesting! Looking at [?https://github.com/AccelerateHS/accelerate/blob/release/0.15/Data/Array/Accelerate/Array/Representation.hs#L110 this code] (linked in comment:38), we see that if `bound` is inlined, we get ''seven'' new calls to `bound`. And each of those seven will yield seven new ones, and so on. Very exponential! Some thoughts: * One could rewrite the linked code to say {{{ ... where bound1 = bound sh ix bndy }}} and use `bound1` for all seven occurrences of `bound sh ix bndy`. Does that help? * If it does, one might have hoped that CSE would catch it. But GHC's current CSE is not very clever. I have an idea for how to improve it so that it ''would'' catch it, if anyone interested in optimisation would like to try it out. RSVP. * Use `-ddump-inlinings` to see why HEAD is choosing not to inline it. * In general this kind of thing is quite hard to prevent. The classic case is {{{ f x = f (x-1) + f (x-2) }}} but GHC doesn't inline recursive functions, so we are ok. This case is more like {{{ f1 x = f2 (x-1) + f2 (x-2) f2 x = f3 (x-1) + f3 (x-2) f3 x = f4 (x-1) + f4 (x-2) ...etc... }}} But the successive f's are generated by the nested instance declarations. And I tried hard NOT to prevent inlining in these cases becuase it can be dramatically better to allow it. (E.g. look at the definition of `fromIndex` at the same link. I don't know a good way to trim off unproductive exponential inlinings without killing off good inlinings too. In short, I don't know a general solution. But any definition that has a seven-way (or even two-way) expansion over a recursive type index is going to cause trouble. Worth looking out for these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 22 23:30:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Jun 2015 23:30:38 -0000 Subject: [GHC] #10561: "deriving (Functor)" on a polykinded type produces ill-kinded instance In-Reply-To: <047.92b5c73d11a6ce75dd9ba55b0b432115@haskell.org> References: <047.92b5c73d11a6ce75dd9ba55b0b432115@haskell.org> Message-ID: <062.f8da2c71c5c1af3e1ef2ecccadcc474b@haskell.org> #10561: "deriving (Functor)" on a polykinded type produces ill-kinded instance -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 07:55:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 07:55:04 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.4d52071de67d664af8f6e6d62f68d7cc@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by svenpanne): Hmmm, GCC's behavior is a bit weird, and to be honest: It's the first time that I've heard of the fact that e.g. -Ofoo is processed before -fblah, regardless of the order on the command line. Re-reading GCC's documentation, it is explicitly stated that order is important, but the docs introduce the notion of "option kind", without actually specifying what those kinds are and in which order those kinds are processed (https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Invoking-GCC.html). Obviously, the -Ofoo options are of a different kind than the -fblah options, and the -Ofoo ones are processed before the -fblah ones. *But* within these kinds, order matters: {{{ $ gcc -c -Q --help=optimizers -O3 -O0 | grep tree-vectorize -ftree-vectorize [disabled] $ gcc -c -Q --help=optimizers -O0 -O3 | grep tree-vectorize -ftree-vectorize [enabled] }}} OTOH, clang doesn't seem to have this notion of "kinds" and simply processes options in order: {{{ $ echo 'int x;' | clang -xc -fno-vectorize -O2 - -o /dev/null -\#\#\# 2>&1 | sed 's/\s/\n/g' | grep vectorize-loops "-vectorize-loops" $ echo 'int x;' | clang -xc -O2 -fno-vectorize - -o /dev/null -\#\#\# 2>&1 | sed 's/\s/\n/g' | grep vectorize-loops }}} Same for most other tools, including e.g. git: {{{ $ git log --pretty=short --oneline ab3926f Fix PR13851: Preserve metadata for the unswitched branch 9e7539a Remove broken banner. ... $ git log --oneline --pretty=short commit ab3926f Author: Weiming Zhao Fix PR13851: Preserve metadata for the unswitched branch commit 9e7539a Author: Rafael Espindola Remove broken banner. ... }}} So in a nutshell: If we really want to mirror GCC's behavior (which is not 100% clear to me), we have to introduce "option kinds", partition our flags into those kinds, and impose an order on those kinds. Furthermore, one can't simply expand "meta" flags and process those expanded flags afterwards (see the -O3 -O0 vs. -O0 -O3 example above), the expansion can only be done after the corresponding "kind phase" has been processed. Much fun documenting all this stuff. :-) IMHO this is far too complicated, and GCC seems to be an outlier regarding this, just processing things in order (as we currently do?) is the easiest thing. But I'll leave the final decision up to those implementing and documenting any change, as long as we don't introduce any ad hoc warnings. Final thought: clang's optimizer options for -O0, -O1, ... are *not* subsets of the previous optimization level, so one has to think about meta options removing flags. o_O I hope we won't do this... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 08:06:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 08:06:05 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.b53ff1e313fcbdb4c73e1d6ece0229f9@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Simonpj, indeed sharing `bound sh ix bndy` between the alternatives does help, but only if the binding is marked as `NOINLINE`, otherwise it seems that the compiler is eager to inline it right back in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 08:52:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 08:52:54 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.bba6b1fe465981bfac0f9975de119159@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I've done some testing; notes can be found here. https://github.com/bgamari/ghc-T7450 I have also attached a profile of GHC churning through a Read instance for a 1000-constructor ADT above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 09:55:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 09:55:37 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.b2023edb7e5879ac7c679c012671a368@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Aha, yes you are right. If we have {{{ let x = bound sh ix bndy in case v of A -> case x of ... B -> case x of ... etc }}} then GHC will inline `x` because * Doing so eliminates a thunk * Doing so does no more work Hmm. I really don't see a good general solution here. As an ad-hoc solution, using NOINLINE will be fine. It's probably simpler to use it on the entire `bound` method (with a prominent Note to explain) rather than creating an auxiliary NOINLINE binding. That would be an upstream change in `accelerate`. For posterity, here is the offending instance in `Data.Array.Accelerate.Array.Representation`: {{{ instance Shape sh => Shape (sh, Int) where ... bound (sh, sz) (ix, i) bndy | i < 0 = case bndy of Clamp -> bound sh ix bndy `addDim` 0 Mirror -> bound sh ix bndy `addDim` (-i) Wrap -> bound sh ix bndy `addDim` (sz+i) Constant e -> Left e | i >= sz = case bndy of Clamp -> bound sh ix bndy `addDim` (sz-1) Mirror -> bound sh ix bndy `addDim` (sz-(i-sz+2)) Wrap -> bound sh ix bndy `addDim` (i-sz) Constant e -> Left e | otherwise = bound sh ix bndy `addDim` i where Right ds `addDim` d = Right (ds, d) Left e `addDim` _ = Left e }}} Note the seven recursive calls; plus the fact that we use instances with deeply-nested tuples Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 11:57:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 11:57:39 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.ef31da148b5053315bce736fe738c831@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I could not find any notes at that link. What does `-dshow-passes` show? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:03:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:03:44 -0000 Subject: [GHC] #10507: Looping with type level naturals In-Reply-To: <047.5fd95e048f3c3bca89022fe8d424335a@haskell.org> References: <047.5fd95e048f3c3bca89022fe8d424335a@haskell.org> Message-ID: <062.dd504fddf798e95b12cbfccececdfca8@haskell.org> #10507: Looping with type level naturals -------------------------------------+------------------------------------- Reporter: jhendrix | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: OK let's leave it for 7.12. Sorry about this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:14:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:14:08 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.e7f9a87b6b6a78a05378e335ab3700c6@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: partial- Blocked By: | sigs/should_compile/T10403 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"55843f1c43ec3721a924cbbe5d422798819030c1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="55843f1c43ec3721a924cbbe5d422798819030c1" Further elaborate Trac #10403 test Adding app1, app2, as requested in the ticket }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:15:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:15:54 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.e9ba7fbc4677257952ef7f103d0e27f7@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: partial- Blocked By: | sigs/should_compile/T10403 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): OK, I've elaborated the test with the extra pieces you suggest. It all works fine in HEAD. It does not work in 7.10; and, as you'll see in #10045, we don't propose to fix in 7.10. I hope you can live without it. Sound OK? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:16:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:16:17 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.80c75107ad5f932765f915dbc6084f3b@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: partial- Blocked By: | sigs/should_compile/T10403 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:17:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:17:55 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.a5378e886680216513f3279b20319e6c@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: scpmw (added) Comment: Sounds like one for Peter Wortmann. Peter, can you help? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:19:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:19:41 -0000 Subject: [GHC] #10550: Drop truncated package name prefix from package keys In-Reply-To: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> References: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> Message-ID: <060.cdf6e204d6c772ab7452d8143084e8b8@haskell.org> #10550: Drop truncated package name prefix from package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Package system | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Generally ok with me, but please document in the user manual, in as many plausible places as possible, the use of `ghc-pkg` to decode the package key. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:20:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:20:14 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.5c05383d66d6bd598de65221590e0c4e@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D606 -------------------------------------+------------------------------------- Comment (by simonpj): OK, well, let's just leave it then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:21:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:21:08 -0000 Subject: [GHC] #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" In-Reply-To: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> References: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> Message-ID: <061.49e2021126ce054b82a8005e5a59858d@haskell.org> #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Does `-dcore-lint` show up anything? What happens if you do not use LLVM? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:26:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:26:12 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.157a94350d6eb224f71ebac8deeb2056@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by scpmw): This looks almost exactly like #10052. The gist of the discussion was that it is undefined to try to run optimisation passes such as `FloatIn` on a program with breakpoints. So the question here is why `runhaskell` ends up running optimisations, especially after Austin's fix... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:31:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:31:10 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.83866778961b5a2415df52f1fd4a4dc9@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Can't we at least give a more civilised error message like "Attempting to run FloatIn on a program with breakpoints"? And where are the breakpoints in the example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:39:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:39:40 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.e8f91dd78f9090b9fdf39114915bc389@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+------------------------------------ Reporter: cjwatson | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D996 -----------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"c0847967caf51ea4ca88d0ffc25fe1bd99dcabed/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c0847967caf51ea4ca88d0ffc25fe1bd99dcabed" powerpc: add basic support for PLT relocations (#10402) Commit a93ab43ab5f40cadbedea2f6342b93c245e91434 enabled support for proper PIC relocations from assembler. Commit adds support for relocations of type: R_PPC_REL16_HI R_PPC_REL16_HA R_PPC_REL16_LO R_PPC_PLTREL24 They are used only when GHC is built in DYNAMIC_GHC_PROGRAMS = NO mode. Verified by running the following test: // cat a.c #include void ffi_a_hello (int i) { fprintf (stderr, "WEEEEEEEE: i=%d\n", i); } -- cat A.hs {-# LANGUAGE ForeignFunctionInterface #-} module A where import Foreign.C foreign import ccall "ffi_a_hello" a :: CInt -> IO () # ghc -fPIC -c a.c -fforce-recomp # ghc -fPIC -c A.hs -fforce-recomp # ghc --interactive ./a.o A ... *A> a 42 WEEEEEEEE: i=42 See gory details in Trac #10402. Signed-off-by: Colin Watson Signed-off-by: Sergei Trofimovich Reviewed By: bgamari, austin Differential Revision: https://phabricator.haskell.org/D996 GHC Trac Issues: #10402 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:41:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:41:28 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.5b570ae637816c120cceebd4333d1b17@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: merge Priority: low | Milestone: 7.10.2 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D807 -------------------------------------+------------------------------------- Comment (by thoughtpolice): Hmmmm, I'm rather inclined to leave this one out I'm afraid. Does anyone have any opinions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:43:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:43:02 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.32093c754d5423f6dd20473f0dcbcb25@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+------------------------------------ Reporter: cjwatson | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D996 -----------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:43:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:43:19 -0000 Subject: [GHC] #10556: Add parsePattern entry point In-Reply-To: <049.1ec5d8db2610e1b9c74e8fbc78e5e7a3@haskell.org> References: <049.1ec5d8db2610e1b9c74e8fbc78e5e7a3@haskell.org> Message-ID: <064.1dbe8fe3b595ecaf7b48d69bcbecbfdd@haskell.org> #10556: Add parsePattern entry point -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1005 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 12:53:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 12:53:08 -0000 Subject: [GHC] #10530: Update transformers library In-Reply-To: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> References: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> Message-ID: <067.92d42cdbcd487206778fb74d43eebdaa@haskell.org> #10530: Update transformers library -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | thoughtpolice Priority: normal | Status: closed Component: libraries | Milestone: 7.10.2 (other) | Version: 7.10.2-rc1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | transformers Type of failure: Other | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => wontfix Comment: Actually, after talking about this with Simon etc, we're somewhat inclined to leave it out as we normally reserve point releases for bug fixes - and while `transformers` *was* updated, it only added a few instances, meaning that mostly what's affected are orphans out in the wild. So I'm actually punting this out of 7.10.2, although if someone feels strongly, they can just re-open and we can consider it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 13:21:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 13:21:01 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.12c90cfefa350dc15cdffb13ba7c1038@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, yes, sorry, the above repository is at this point really just a couple of scripts for characterising the problem. `-dshow-passes` points at the specializer being much of the issue. Take the case of a 1000 constructor ADT. With GHC from `master`, the compilation takes roughly 75 seconds on my laptop. Of this it seems roughly 20 seconds is spent in the specialiser, and another 20 seconds are spent in the assembler. Otherwise the rest of the time is split between various simplifier iterations, with no single iteration taking more than a couple of seconds. If I disable specialisation the compilation time drops to 52 seconds, with the largest portion of this being a 7 second simplifier iteration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 13:28:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 13:28:49 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.60f6bc25ce858d3b53d0f92bd0c9a71e@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Here is GHC 7.11 output annotated with relative timestamps for, * with specialisation: https://github.com/bgamari/ghc-T7450/blob/24da000aae23eb8cbd4cec52015c64fa978de738 /with-spec.log * without specialisation: https://github.com/bgamari/ghc-T7450/blob/24da000aae23eb8cbd4cec52015c64fa978de738 /no-spec.log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 13:42:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 13:42:04 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.d8d2975122544ade1b23cc0319d3145c@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: partial- Blocked By: | sigs/should_compile/T10403 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-index): Yes, it sounds ok. I just wanted to make sure that the bug is known of and reflected in the test suite. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 13:54:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 13:54:30 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.1debf52de00b0ae9d086c327020f6a07@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I think I finally found it (after struggling for far too long wondering why the profiles were so useless, eventually finding that I misspelled `OPTIONS_GHC`). `Specialise(pair_fvs)` shows up very strongly in the profile. Still trying to reason through what is happening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 14:18:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 14:18:43 -0000 Subject: [GHC] #10196: Regression regarding Unicode subscript characters in identifiers In-Reply-To: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> References: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> Message-ID: <060.79ed27040cf700a6b36ec73f70e4ad85@haskell.org> #10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | thoughtpolice Priority: normal | Status: patch Component: Compiler | Milestone: 7.10.3 (Parser) | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #5108 | Differential Revisions: Phab:D969 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.2 => 7.10.3 Comment: I think we're going to end up punting this to 7.10.3 at least, because the current patch has some regressions, and this is ultimately fairly minor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 14:19:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 14:19:25 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.a37f8d7070af80cd96a4a423d7399975@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: merge Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D807 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.2 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 14:22:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 14:22:30 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.7f1e12db869f2584ae4db51100099a0b@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D807 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: After discussing it, I think we're going to punt this and just leave it to 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 14:53:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 14:53:19 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.e9863d996565a69c7dd235673b92fd10@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Ben, good work. I think you said that the culprit is `consDictBind`. Here are some ideas: * `snocDictBinds is only ever called with a singleton argument. Nuke it in favour of `snocDictBind`. * The calls to `snocDictBind` in `specBind` have just called `flattenDictBinds` which stupidly throws away all the free varaible information cached in the `DictBind`. Better to keep it! To achieve that * `snocDictBind` should take a `DictBind` not a `CoreBind` * `flattenDictBinds` should return a `DictBind` not a `CoreBind`. This is the place we are discarding the free var info. Instead, keep it! Does that make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 14:59:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 14:59:34 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.6d22499ad14a42428da87eb43838c04d@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 16:39:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 16:39:33 -0000 Subject: [GHC] #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 Message-ID: <047.dce4788acf854b7c92bad29baf2c8a65@haskell.org> #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In running a Stackage Nightly build with GHC 7.10.2 (via Herbert's PPA), I discovered the following regression: http://lpaste.net/135057 Note that boolsimplifier-0.1.8 compiles just fine with GHC 7.10.1, but not with 7.10.2. I am still running the rest of the Stackage build. $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150619 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 16:40:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 16:40:22 -0000 Subject: [GHC] #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 In-Reply-To: <047.dce4788acf854b7c92bad29baf2c8a65@haskell.org> References: <047.dce4788acf854b7c92bad29baf2c8a65@haskell.org> Message-ID: <062.26652533a339a5eb964ea89e03434afb@haskell.org> #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by snoyberg): * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 16:49:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 16:49:51 -0000 Subject: [GHC] #10530: Update transformers library In-Reply-To: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> References: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> Message-ID: <067.8df5b154f2d5770d62856b11b3a347ec@haskell.org> #10530: Update transformers library -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries | Version: 7.10.2-rc1 (other) | Keywords: Resolution: | transformers Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by asr): * owner: thoughtpolice => * status: closed => new * resolution: wontfix => Comment: In Agda and GHC 7.8.*, we couldn't drop support for transformers-0.3.0.0 because transformers is a GHC-included package which makes it difficult for Agda distributions to upgrade. Now, with GHC 7.10.1 we have a similar problem with transformers-0.4.2.0. I guess this is not a problem related only to Agda, so I'm reopening the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 17:08:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 17:08:53 -0000 Subject: [GHC] #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 In-Reply-To: <047.dce4788acf854b7c92bad29baf2c8a65@haskell.org> References: <047.dce4788acf854b7c92bad29baf2c8a65@haskell.org> Message-ID: <062.e8d1643086cac5e5bd17b0c80a86f9b0@haskell.org> #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gershomb): So the relevant lines seem to be: {{{ data QueryRep qtyp a where QAtom :: (Ord a) => a -> QueryRep QAtomTyp a QOp :: (Show qtyp, Ord a) => Set (QueryRep QAtomTyp a) -> Set (QueryRep (QFlipTyp qtyp) a) -> QueryRep qtyp a instance (Eq a) => Eq (QueryRep qtyp a) where (QAtom x) == (QAtom y) = x == y (QOp as cs) == (QOp as' cs') = as == as' && cs == cs' _ == _ = False -- can't happen instance (Ord a) => Ord (QueryRep qtyp a) where compare (QAtom x) (QAtom y) = compare x y compare (QOp as cs) (QOp as' cs') = compare as as' `mappend` compare cs cs' compare (QAtom _) _ = GT -- can't happen compare _ _ = LT -- can't happen }}} And the relevant error seems to be {{{ Overlapping instances for Eq (QueryRep (QFlipTyp qtyp) a) arising from a use of ?compare? }}} With the additional info: {{{ There exists a (perhaps superclass) match: from the context (Eq (QueryRep qtyp a), Ord a) bound by the instance declaration at Data/BoolSimplifier.hs:116:10-41 or from (Show qtyp, Ord a) bound by a pattern with constructor QOp :: forall qtyp a. (Show qtyp, Ord a) => Set (QueryRep QAtomTyp a) -> Set (QueryRep (QFlipTyp qtyp) a) -> QueryRep qtyp a, in an equation for ?compare? at Data/BoolSimplifier.hs:118:14-22 or from (Show qtyp, Ord a) bound by a pattern with constructor QOp :: forall qtyp a. (Show qtyp, Ord a) => Set (QueryRep QAtomTyp a) -> Set (QueryRep (QFlipTyp qtyp) a) -> QueryRep qtyp a, in an equation for ?compare? at Data/BoolSimplifier.hs:118:26-36 (The choice depends on the instantiation of ?qtyp, a? To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) In the second argument of ?mappend?, namely ?compare cs cs'? In the expression: compare as as' `mappend` compare cs cs' In an equation for ?compare?: compare (QOp as cs) (QOp as' cs') = compare as as' `mappend` compare cs cs' }}} So what's happening is we've asserted there's an `Ord a` dictionary three different ways -- first and second from packing it in each of the two GADTs, and third from the constrain in the instance head. Interestingly, it doesn't seem to balk at duplicate `Ord` instances themselves, but from the fact that they lead to duplicate `Eq` instances. To be honest, I don't remember why the `Ord` constraint is ever packed with the GADT at all. But, regardless, this seems like something the compiler should be able to handle properly, and it seems like a regression if it can't? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 17:09:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 17:09:26 -0000 Subject: [GHC] #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 In-Reply-To: <047.dce4788acf854b7c92bad29baf2c8a65@haskell.org> References: <047.dce4788acf854b7c92bad29baf2c8a65@haskell.org> Message-ID: <062.cb655e4214091cfd19a1b3952ff54ff3@haskell.org> #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gershomb): * cc: gershomb (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 17:35:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 17:35:44 -0000 Subject: [GHC] #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom Message-ID: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom -----------------------------------------+--------------------------------- Reporter: tejon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- {{{ [ 4 of 11] Compiling Reflex.Dom.Internal ( src\Reflex\Dom\Internal.hs, dist\build\Reflex\Dom\Internal.o ) ghc.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 00000000184b3978 (GHC version 7.10.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This happens with unmodified reflex-dom.cabal (which specifies -funbox- strict-fields and -O2) and also with all ghc-options: flags removed and -O or -O0. When compiling with the bundled mingw it also pops up a GUI error window: {{{ ghc.exe - Entry Point Not Found The procedure entry point pthread_cond_timedwait_relative_np could not be located in the dynamic link library libwinpthread-1.dll. }}} I also tried using a fully-updated mingw64 from MSYS2, which has solved -pthread issues for me in the past, but that simply crashes with no additional message. Verbose cabal output attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 17:37:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 17:37:05 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.e8bb137e257775899d82f83e53d5cd8e@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gershomb): * cc: gershomb (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 17:40:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 17:40:00 -0000 Subject: [GHC] #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 (was: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom) In-Reply-To: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> References: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> Message-ID: <059.bc527b8a866c145e6d8a80aed8fc7202@haskell.org> #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 ---------------------------------+----------------------------------------- Reporter: tejon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 17:42:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 17:42:55 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.059b1ad424f7bb9754105fd01522b9fe@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I've opened this pull-request addressing this issue upstream. https://github.com/AccelerateHS/accelerate/pull/276 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 17:44:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 17:44:21 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.767b8a0602a4c959375c10ec9742babb@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 17:47:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 17:47:46 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.0c95356ea72cb3b086b670beda349c49@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: As Simon described above, there isn't much we can do to safely optimize this sort of program in general. Moreover, it seems that 7.11 already decides on its own not to inline the offending function. Closing as WONTFIX. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 17:57:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 17:57:02 -0000 Subject: [GHC] #10564: GHC 7.10.2 RC cannot build HList-0.4.0.0 Message-ID: <047.d3b7b31aab7749db694d46171b616686@haskell.org> #10564: GHC 7.10.2 RC cannot build HList-0.4.0.0 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Another Stackage find: http://lpaste.net/135061 {{{ Data/HList/Record.hs:575:10: Illegal instance declaration for ?HasFieldM l (r xs) v? The liberal coverage condition fails in class ?HasFieldM? for functional dependency: ?l r -> v? Reason: lhs types ?l?, ?r xs? do not jointly determine rhs type ?v? In the instance declaration for ?HasFieldM l (r xs) v? Data/HList/Record.hs:587:10: Illegal instance declaration for ?HasField l (Record (Tagged l1 v1 : r)) v? The liberal coverage condition fails in class ?HasField? for functional dependency: ?l r -> v? Reason: lhs types ?l?, ?Record (Tagged l1 v1 : r)? do not jointly determine rhs type ?v? In the instance declaration for ?HasField l (Record (Tagged l1 v1 : r)) v? Data/HList/Record.hs:646:10: Illegal instance declaration for ?HDeleteAtLabel Record l v v'? The liberal coverage condition fails in class ?HDeleteAtLabel? for functional dependency: ?l v -> v'? Reason: lhs types ?l?, ?v? do not jointly determine rhs type ?v'? In the instance declaration for ?HDeleteAtLabel Record l v v'? Data/HList/Record.hs:723:10: Illegal instance declaration for ?HUpdateAtLabel2 l v (Tagged l' e : xs) xs'? The liberal coverage condition fails in class ?HUpdateAtLabel2? for functional dependency: ?l r v -> r'? Reason: lhs types ?l?, ?Tagged l' e : xs?, ?v? do not jointly determine rhs type ?xs'? In the instance declaration for ?HUpdateAtLabel2 l v (Tagged l' e : xs) xs'? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 17:57:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 17:57:45 -0000 Subject: [GHC] #10550: Drop truncated package name prefix from package keys In-Reply-To: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> References: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> Message-ID: <060.535d59a98edca5c7a8e15d822c4638bc@haskell.org> #10550: Drop truncated package name prefix from package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Package system | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1011 -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => Phab:D1011 Comment: GHC plus Cabal PR: https://github.com/haskell/cabal/pull/2671 Simon, I added a note to the user manual; however, I think it might be better to arrange for GHC proper to never display raw package keys to users; always given them an IPID instead (falling back on the key only if something really bad has happened re the package database.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 17:58:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 17:58:56 -0000 Subject: [GHC] #10565: GHC 7.10.2 RC: the impossible happened on hPDB-examples-1.2.0.2 Message-ID: <047.3ffddb89eb8d6f97040b05fb569a18d7@haskell.org> #10565: GHC 7.10.2 RC: the impossible happened on hPDB-examples-1.2.0.2 -----------------------------------------+--------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- When compiling with the RC for Stackage, I get: {{{ [1 of 1] Compiling Main ( examples/Rg.hs, dist/build/Rg/Rg- tmp/Main.o ) : ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150619 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone bindIO To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 19573 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 18:34:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 18:34:18 -0000 Subject: [GHC] #10566: Move "package key" generation to GHC Message-ID: <045.ddebeff3d0e9a54644e59a805a0d4635@haskell.org> #10566: Move "package key" generation to GHC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Package | Version: 7.10.1 system | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently in GHC 7.10, we have the following situation: 1. Cabal computes a package key, which in practice (since no one is using Backpack in the wild) is a Merkle tree of the versions of each of the dependencies of the package. 2. This package key is passed to GHC via `-this-package-key` 3. GHC handles the package key opaquely Now, in recent Backpack implementation, we need GHC to be able to compute package keys. (The concrete case: you're type-checking an interface file of an indefinite package, where you want to instantiate it with some assignment of its holes: instantiating those holes you need to instantiate any package keys mentioned in the interface, in which case you really want to be able to compute the hash.) So I want to move package key generation to GHC. The primary implication is this: does Cabal continue to generate package keys? If it doesn't, we should revert from `-this-package-key` back to `-package-name` from the previous version (but maybe renamed because this name was bad). GHC then computes a package key based on `-package-name` and the explicitly mentioned `-package` dependencies, and Cabal reads it out with something akin to `--abi-hash`. If it does, we need to ensure GHC and Cabal's package key algorithms stay synchronized. I personally lean towards the first option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 19:12:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 19:12:48 -0000 Subject: [GHC] #10196: Regression regarding Unicode subscript characters in identifiers In-Reply-To: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> References: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> Message-ID: <060.277ad1f710ab53110d1908255f2fe0ab@haskell.org> #10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | thoughtpolice Priority: normal | Status: patch Component: Compiler | Milestone: 7.10.3 (Parser) | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #5108 | Differential Revisions: Phab:D969 -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:5 hvr]: > We're planning to allow `Lm` from the 2nd character on in an identifier for 7.10.2 The current patch does exactly this. It still needs a changelog entry. I would have preferred to only allow `Lm` in the suffix of an identifier. But we can leave that for 7.12 or later, as there is a slight chance it breaks someone's code. We could mention it in the docs. There's also the issue that ModifierLetter perhaps brings in too many weird characters: "15-06-18T11:46:27"< hvr@> thomie: can we easily list all modifier letters in Haskell? "15-06-18T11:47:55"< hvr@> [ c | c <- ['\0'..], generalCategory c == ModifierLetter ] "15-06-18T11:47:56"< hvr@> got it "15-06-18T11:48:56"< hvr@> ok, there's a lot in there one doesn't want to allow in identifiers :-/ "15-06-18T11:49:31"< thomie > booh "15-06-18T11:49:50"< hvr@> these look nasty: "15-06-18T11:50:46"< hvr@> so many column variants, theres also "?" hvr: do you think this a big enough issue to not proceed with the current patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 20:42:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 20:42:45 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.9fec6aa85f6f0a93939f72476f37ec5f@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Indeed most of the time spent in the specialiser is spent in `consDictBind`. With respect to `snocDictBinds`: I believe `final_binds` in `specBind` actually can be of length greater than one. Seems worthwhile to keep it. Otherwise it seems fairly clear. I just hacked up a quick attempt; we'll see if it validates. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 21:14:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 21:14:23 -0000 Subject: [GHC] #10566: Move "package key" generation to GHC In-Reply-To: <045.ddebeff3d0e9a54644e59a805a0d4635@haskell.org> References: <045.ddebeff3d0e9a54644e59a805a0d4635@haskell.org> Message-ID: <060.c786066b242eedf5f7d3301c813a78d0@haskell.org> #10566: Move "package key" generation to GHC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Package system | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Sounds good in general terms. But up to now GHC has been primary a module-at-a-time compiler. To compute a package key it needs to know all about a package. Do you intend to do this by giving it a Backpack file describing the package? Or what? And how does Cabal get to know what key GHC computed? More detail required! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 21:24:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 21:24:32 -0000 Subject: [GHC] #10566: Move "package key" generation to GHC In-Reply-To: <045.ddebeff3d0e9a54644e59a805a0d4635@haskell.org> References: <045.ddebeff3d0e9a54644e59a805a0d4635@haskell.org> Message-ID: <060.2e5a2ea0d389bc97efb0c563ea61d81a@haskell.org> #10566: Move "package key" generation to GHC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Package system | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): > Sounds good in general terms. But up to now GHC has been primary a module-at-a-time compiler. To compute a package key it needs to know all about a package. Do you intend to do this by giving it a Backpack file describing the package? Or what? So, actually, we can do this very nicely: if you compile a GHC module with `-hide-all-packages` and a list of `-package` flags, then GHC can infer the package key by just looking at each exposed package, and including their hash in the computed package key. So, in some since Cabal is still "calculating" many of the important parameters of the package key (the package name, version, and what dependencies are used), but GHC does the actual final calculation in the end. Here's how it looks without Backpack: 1. Cabal calls GHC with `-package-name foo-0.1 -hide-all-packages -package-id bar-0.1-ABCD ...` 2. GHC computes the package state with the package flags, getting a list of exposed packages with `PkgConfig`s 3. Compute the package key by hashing the source package ID and package key of each included exposed package. With Backpack it's a little trickier, because we don't necessarily want to hash the package key of included packages: instead, you want to hash the "version hash" of each package, which is like a package key but minus hole instantiation. > And how does Cabal get to know what key GHC computed? My initial thought is a new major mode `ghc --package-key -package-name foo-0.1 -hide-all-packages -package bar-0.1-ABCD ...` which outputs the package key. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 22:02:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 22:02:30 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.4041b3da00b5d6a0b790f566d847c007@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1012 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari * differential: => Phab:D1012 Comment: Seems to work. Opened a Differential. We'll see how it looks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 23 23:48:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Jun 2015 23:48:09 -0000 Subject: [GHC] #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 In-Reply-To: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> References: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> Message-ID: <059.a2d0c24c31fde901ed61208d4ceeee08@haskell.org> #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 -------------------------------------+------------------------------------- Reporter: tejon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by tejon): * failure: None/Unknown => Compile-time crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 24 04:43:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Jun 2015 04:43:32 -0000 Subject: [GHC] #10530: Update transformers library In-Reply-To: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> References: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> Message-ID: <067.640c88774be5a4c551fcd6b1d04815fe@haskell.org> #10530: Update transformers library -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries | Version: 7.10.2-rc1 (other) | Keywords: Resolution: | transformers Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): What is the problem exactly? Are you in a huge hurry to drop support for transformers-0.4.2.0? The latest version of Agda on Hackage seems to support several GHC versions' worth of packages that come with GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 24 12:02:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Jun 2015 12:02:54 -0000 Subject: [GHC] #7650: can't use combining characters in identifiers In-Reply-To: <044.4fb0377eab552e230ee53da0d70baa3c@haskell.org> References: <044.4fb0377eab552e230ee53da0d70baa3c@haskell.org> Message-ID: <059.00258594db304fe087f9db7f9f148b48@haskell.org> #7650: can't use combining characters in identifiers -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => unicode * os: Linux => Unknown/Multiple * architecture: x86 => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 24 12:33:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Jun 2015 12:33:10 -0000 Subject: [GHC] #9494: Probable data corruption with GHCi 7.8.* and Zlib In-Reply-To: <047.c599b15a57b1de1c882b98999535443e@haskell.org> References: <047.c599b15a57b1de1c882b98999535443e@haskell.org> Message-ID: <062.b220d9ad84a0eb4b7d0fd0110280db1f@haskell.org> #9494: Probable data corruption with GHCi 7.8.* and Zlib -------------------------------------+------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: duncan (added) * owner: aseipp => * priority: high => normal Comment: duncan: I can not find the zlib bugtracker. Can you have a look at this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 24 15:51:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Jun 2015 15:51:48 -0000 Subject: [GHC] #10567: Redundant parser entry point Message-ID: <049.8ddc93bc31cd85feb5fe02a4668948de@haskell.org> #10567: Redundant parser entry point -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `stmt` parser is exposed under two different names. (`parseFullStmt` and `parseStatement`) It would be better to remove one of them (I would say `parseFullStmt`) in order to avoid confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 24 17:30:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Jun 2015 17:30:19 -0000 Subject: [GHC] #10567: Redundant parser entry point In-Reply-To: <049.8ddc93bc31cd85feb5fe02a4668948de@haskell.org> References: <049.8ddc93bc31cd85feb5fe02a4668948de@haskell.org> Message-ID: <064.2bd919b78ece605de83461c865da4e32@haskell.org> #10567: Redundant parser entry point -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab: | D1014 -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab: D1014 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 24 19:18:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Jun 2015 19:18:54 -0000 Subject: [GHC] #10565: GHC 7.10.2 RC: the impossible happened on hPDB-examples-1.2.0.2 In-Reply-To: <047.3ffddb89eb8d6f97040b05fb569a18d7@haskell.org> References: <047.3ffddb89eb8d6f97040b05fb569a18d7@haskell.org> Message-ID: <062.a3ead111291d72b4324f112dfe23be4a@haskell.org> #10565: GHC 7.10.2 RC: the impossible happened on hPDB-examples-1.2.0.2 ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by sopvop): Probably duplicate of either #10491 or #10527 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 24 20:27:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Jun 2015 20:27:36 -0000 Subject: [GHC] #10530: Update transformers library In-Reply-To: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> References: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> Message-ID: <067.019e7a52a9bad138f2229f1bc62d9ba9@haskell.org> #10530: Update transformers library -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries | Version: 7.10.2-rc1 (other) | Keywords: Resolution: | transformers Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by asr): Replying to [comment:5 rwbarton]: > What is the problem exactly? Are you in a huge hurry to drop support for transformers-0.4.2.0? I reopened the ticket no because there is a problem right now, but I want to avoid a possible future problem. Let's suppose Agda will use an instance only available in transformers-0.4.3.0 and let's suppose that a new version of the distribution X (for example, Ubuntu) will be shipped with GHC 7.10.2, which includes transformers-0.4.2.0. In consequence, or Agda will need to support both versions of transformers or the distribution X won't include Agda. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 24 20:53:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Jun 2015 20:53:44 -0000 Subject: [GHC] #10550: Drop truncated package name prefix from package keys In-Reply-To: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> References: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> Message-ID: <060.09263cbbaf9e8caf28ba5bd48846e176@haskell.org> #10550: Drop truncated package name prefix from package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Package system | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1011 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"ece2c4349718cf89b291ff3c962cbda4805bab43/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ece2c4349718cf89b291ff3c962cbda4805bab43" Drop prefix from package keys. Summary: Contains Cabal submodule update, as Cabal is responsible generating package keys. We also have to update some output. Also comes with a documentation update for ghc-pkg in the user manual for --package-key. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1011 GHC Trac Issues: #10550 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 24 21:06:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Jun 2015 21:06:13 -0000 Subject: [GHC] #10568: Loading GLUT into GHCI fails on the Mac, probably a regression Message-ID: <045.16a6419c70e069ea547a1b942e636370@haskell.org> #10568: Loading GLUT into GHCI fails on the Mac, probably a regression -----------------------------------------+------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+------------------------------- ghci -V The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150612 ghci -package GLUT GHCi, version 7.10.1.20150612: http://www.haskell.org/ghc/ :? for help : can't load .so/.DLL for: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib (dlopen(/Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib, 5): Symbol not found: _glutBitmap8By13 Referenced from: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib Expected in: flat namespace in /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib) This may be related to the fix for #10322. The GLUT people are aware of this. They believe it is platform scpecific, a regression and probably a ghc issue. See https://github.com/haskell-opengl/GLUT/issues/19 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 24 21:13:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Jun 2015 21:13:42 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.28fee9dfd86b7cde9b24a03cc057025b@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by NeilMitchell): From what I can see, it looks like Austin's changes and all of #10052 was all in by 20150615, suggesting the bug is something different? I'm not deliberately doing anything with breakpoints, but it does have plenty of generated code (I convert the Haddock code snippets into code and try and type check them with some dummy definitions and the real Shake code). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 24 22:18:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Jun 2015 22:18:06 -0000 Subject: [GHC] #10569: Treat an out-of-scope variable like a typed hole Message-ID: <046.67d84e7549a910d711bf04ba8ad86bb4@haskell.org> #10569: Treat an out-of-scope variable like a typed hole -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If we have {{{ f x = x + y }}} GHC currently reports `Not in scope: y`, and halts. It would be cool to treat `y` as a typed hole, so that * The out-of-scope message would give its type * Using `-fdefer-type-errors` we could defer the error to runtime. This was suggested in #5910 [https://ghc.haskell.org/trac/ghc/ticket/5910#comment:19 comment 19], and [http://haskell.1045720.n5.nabble.com/fdefer-more-errors-td5809991.html this Haskell Cafe thread] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 24 22:18:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Jun 2015 22:18:34 -0000 Subject: [GHC] #10569: Treat an out-of-scope variable like a typed hole In-Reply-To: <046.67d84e7549a910d711bf04ba8ad86bb4@haskell.org> References: <046.67d84e7549a910d711bf04ba8ad86bb4@haskell.org> Message-ID: <061.a948b314736d659a56207840ae821464@haskell.org> #10569: Treat an out-of-scope variable like a typed hole -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 10:30:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 10:30:45 -0000 Subject: [GHC] #10570: Too restrictive liberate coverage condition Message-ID: <046.4466b015687c38c71e7a50b843a82b42@haskell.org> #10570: Too restrictive liberate coverage condition -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hello! Let's look at this small example: {{{haskell class ConsByIdx2 x a m cls | x -> m where consByIdx2 :: x -> a -> m cls instance ConsByIdx2 Int a Proxy cls where consByIdx2 _ _ = Proxy }}} It fails to compile with the following error: {{{haskell Illegal instance declaration for ?ConsByIdx2 Int a Proxy cls? The liberal coverage condition fails in class ?ConsByIdx2? for functional dependency: ?x -> m? Reason: lhs type ?Int? does not determine rhs type ?Proxy? In the instance declaration for ?ConsByIdx2 Int a Proxy cls? }}} But Int determines the Proxy in a nice way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 10:32:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 10:32:31 -0000 Subject: [GHC] #10570: Too restrictive liberate coverage condition In-Reply-To: <046.4466b015687c38c71e7a50b843a82b42@haskell.org> References: <046.4466b015687c38c71e7a50b843a82b42@haskell.org> Message-ID: <061.5e96720b6065766cc33f8406e66cf625@haskell.org> #10570: Too restrictive liberate coverage condition -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hello! Let's look at this small example: > > {{{haskell > class ConsByIdx2 x a m cls | x -> m where > consByIdx2 :: x -> a -> m cls > > instance ConsByIdx2 Int a Proxy cls where > consByIdx2 _ _ = Proxy > }}} > > It fails to compile with the following error: > > {{{haskell > Illegal instance declaration for ?ConsByIdx2 Int a Proxy cls? > The liberal coverage condition fails in class ?ConsByIdx2? > for functional dependency: ?x -> m? > Reason: lhs type ?Int? does not determine rhs type ?Proxy? > In the instance declaration for ?ConsByIdx2 Int a Proxy cls? > }}} > > But Int determines the Proxy in a nice way. New description: Hello! Let's look at this small example: {{{ class ConsByIdx2 x a m cls | x -> m where consByIdx2 :: x -> a -> m cls instance ConsByIdx2 Int a Proxy cls where consByIdx2 _ _ = Proxy }}} It fails to compile with the following error: {{{ Illegal instance declaration for ?ConsByIdx2 Int a Proxy cls? The liberal coverage condition fails in class ?ConsByIdx2? for functional dependency: ?x -> m? Reason: lhs type ?Int? does not determine rhs type ?Proxy? In the instance declaration for ?ConsByIdx2 Int a Proxy cls? }}} But Int determines the Proxy in a nice way. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 10:48:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 10:48:27 -0000 Subject: [GHC] #10570: Too restrictive liberate coverage condition In-Reply-To: <046.4466b015687c38c71e7a50b843a82b42@haskell.org> References: <046.4466b015687c38c71e7a50b843a82b42@haskell.org> Message-ID: <061.d5d1a214bfaca9e2dbae547086c5bf14@haskell.org> #10570: Too restrictive liberate coverage condition -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by danilo2): Oh, I just discovered it was caused by the -XPolyKinds flag. This ticket is no longer valid in this situation! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 10:48:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 10:48:45 -0000 Subject: [GHC] #10570: Too restrictive liberate coverage condition In-Reply-To: <046.4466b015687c38c71e7a50b843a82b42@haskell.org> References: <046.4466b015687c38c71e7a50b843a82b42@haskell.org> Message-ID: <061.ea4c1829a4e107023828cb76a7ab2ad7@haskell.org> #10570: Too restrictive liberate coverage condition -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by danilo2): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 10:56:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 10:56:59 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.101b50757f7cae9abeaad0b187e3f8b4@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): The first shipped version of GHC with GHCI support for ARM was ghc-7.8. I just compiled ghc-7.8.4 on ARM and the resulting GHCi fails just like it does for ghc-7.10 and ghc-7.11. For ghc-7.11 (git master) I have tried: * `DYNAMIC_GHC_PROGRAMS` set to both `YES` and `NO` and have the same crash either way. * `Unregisterised` set to `YES` and to `NO`. Both crash in the same way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 13:38:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 13:38:13 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.d6664355eab00d84fcacd5181fac82d4@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D852 -------------------------------------+------------------------------------- Comment (by George): see also #10568 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 13:41:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 13:41:50 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac (was: Loading GLUT into GHCI fails on the Mac, probably a regression) In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.d188e40d6888a7845ca8c21b9f366945@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Description changed by George: Old description: > ghci -V > The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150612 > > ghci -package GLUT > GHCi, version 7.10.1.20150612: http://www.haskell.org/ghc/ :? for help > : can't load .so/.DLL for: > /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 > -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib > (dlopen(/Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 > -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib, 5): Symbol not found: > _glutBitmap8By13 > Referenced from: > /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 > -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib > Expected in: flat namespace > in > /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 > -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib) > > This may be related to the fix for #10322. The GLUT people are aware of > this. They believe it is platform scpecific, a regression and probably a > ghc issue. See https://github.com/haskell-opengl/GLUT/issues/19 New description: ghci -V The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150612 ghci -package GLUT GHCi, version 7.10.1.20150612: http://www.haskell.org/ghc/ :? for help : can't load .so/.DLL for: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib (dlopen(/Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib, 5): Symbol not found: _glutBitmap8By13 Referenced from: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib Expected in: flat namespace in /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib) This may be related to the fix for #10322 or the underlying problem reported there. The GLUT people are aware of this. They believe it is platform scpecific, a regression from 7.8.4 and probably a ghc issue. See https://github.com/haskell-opengl/GLUT/issues/19 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 13:45:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 13:45:19 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.64fd2c001aa3e49571ebacf3ebbe6ff4@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 13:50:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 13:50:56 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.8ceab5d0871645b2128409a8bc397e2a@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Changes (by trommler): * status: new => infoneeded Comment: Can you try with HEAD and/or the tip of the 7.10 branch, please. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 14:51:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 14:51:18 -0000 Subject: [GHC] #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 In-Reply-To: <047.dce4788acf854b7c92bad29baf2c8a65@haskell.org> References: <047.dce4788acf854b7c92bad29baf2c8a65@haskell.org> Message-ID: <062.33d0c047c7ed25966c57a950ad297c69@haskell.org> #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c7b6fb59eca478650dcb391a6f424e3c42a155dc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c7b6fb59eca478650dcb391a6f424e3c42a155dc" Test Trac #10562 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 14:51:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 14:51:17 -0000 Subject: [GHC] #10561: "deriving (Functor)" on a polykinded type produces ill-kinded instance In-Reply-To: <047.92b5c73d11a6ce75dd9ba55b0b432115@haskell.org> References: <047.92b5c73d11a6ce75dd9ba55b0b432115@haskell.org> Message-ID: <062.8299d7a6b1dc4a1855b3c101627c695c@haskell.org> #10561: "deriving (Functor)" on a polykinded type produces ill-kinded instance -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9a348640c5ddd63c3385d3722fb3ade38013a148/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9a348640c5ddd63c3385d3722fb3ade38013a148" Improve kind-checking for 'deriving' clauses The main payload is in 'mk_functor_like_constraints' in TcDeriv.inferConstraints. This is moving towards a fix for Trac #10561 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 15:50:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 15:50:30 -0000 Subject: [GHC] #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 In-Reply-To: <047.dce4788acf854b7c92bad29baf2c8a65@haskell.org> References: <047.dce4788acf854b7c92bad29baf2c8a65@haskell.org> Message-ID: <062.e12ec3b399a6fdfbb2bcb4e6c70218cc@haskell.org> #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Here is a smaller test case {{{ {-# LANGUAGE GADTs, TypeFamilies #-} module T10562 where type family Flip a data QueryRep qtyp a where QAtom :: a -> QueryRep () a QOp :: QueryRep (Flip qtyp) a -> QueryRep qtyp a instance (Eq a) => Eq (QueryRep qtyp a) instance (Ord a) => Ord (QueryRep qtyp a) where compare (QOp a) (QOp b) = a `compare` b }}} With 7.10 we get {{{ T10562.hs:13:31: Overlapping instances for Eq (QueryRep (Flip qtyp) a) arising from a use of ?compare? }}} The problem arises because of the "silent superclass" trick (which is happily gone from HEAD). The instance declaration that is actually checked is {{{ instance (Eq (QueryRep qtyp a), Ord a) => Ord (QueryRep qtyp a) }}} with an extra `Eq (QueryRep qtyp a)` constraint. That gets GHC confused when it tries to solve `Eq (QueryRep (Flip qtyp) a)` from a method. A workaround is to use `-XIncoherentInstances` for this module. Exactly the same failure happens with GHC 7.8.3 doesn't it? Though apparently not with 7.8.2, mysteriously. I'm sorry but it's not feasible to get HEAD's solution into 7.10 now. It works fine in HEAD, and I'll add the example as a test case, to check it stays working. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 16:12:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 16:12:14 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.ce2237e1af39dfc2d5ac0afa9afd3807@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I am still churning through this one but I think I finally have some traction. In 7.10.2 each field added to the records roughly doubles the `simpl-tick-factor` necessary to finish. I am now comparing the sequences of inlinings performed by GHC 7.10.1 and 7.10.2. For those following along at home, it is enlightening (albeit verbose) to compile like this, {{{ ghc -fforce-recomp -O -dverbose-core2core -ddump-simpl -ddump-to-file -dshow-passes -ddump-simpl-stats -ddump-inlinings Bug.hs -fsimpl-tick- factor=100 >|ghc.log 2>&1 }}} Out pops a few hundred megabytes of text, but you now you have what you need. You can then easily compare two of these dumps with, {{{ paste <(grep -n "Inlining done" 7.10.1/ghc.log) <(grep -n "Inlining done" 7.10.2/ghc.log) | column -s $'\t' -t | less }}} One notices certain patterns in this output. In particular, one finds inlinings of `Inlining done: Data.Functor.Identity.$fFoldableIdentity2` are done far more often in 7.10.1 than 7.10.2. More analysis later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 16:33:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 16:33:43 -0000 Subject: [GHC] #10570: Terrible error message with fundeps and PolyKinds (was: Too restrictive liberate coverage condition) In-Reply-To: <046.4466b015687c38c71e7a50b843a82b42@haskell.org> References: <046.4466b015687c38c71e7a50b843a82b42@haskell.org> Message-ID: <061.bc46d43bd0b786321bc67b37a33cfec5@haskell.org> #10570: Terrible error message with fundeps and PolyKinds -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: invalid => Comment: I'm going to re-open because the error message is so terrible. It should jolly well mention kinds, suggest `-fprint-explicit-kinds` etc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 16:56:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 16:56:20 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.07f4202e9372dbd0fe980d69f77c31bb@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): rVery early in simplifier run I noticed this difference. In 7.10.1, {{{#!hs Inlining done: Data.Functor.Identity.$fFoldableIdentity2 Inlined fn: \ (@ a4) (ds [Occ=Once] :: Data.Functor.Identity.Identity a4) -> ds Cont: ApplyToTy (Bug.Rec ss) ApplyToVal nodup ((g x) `cast` (Sym (Nth:0 (_R -> Data.Functor.Identity.NTCo:Identity[0] _R)) :: Data.Functor.Identity.Identity (Bug.Rec ss) ~R# Data.Functor.Identity.Identity (Bug.Rec ss))) CastIt Nth:1 (_R -> Data.Functor.Identity.NTCo:Identity[0] _R) Stop[BoringCtxt] Bug.Rec ss }}} In 7.10.2, {{{#!hs Inlining done: Data.Functor.Identity.$fFoldableIdentity2 Inlined fn: \ (@ a4) (ds [Occ=Once] :: Data.Functor.Identity.Identity a4) -> ds Cont: ApplyToTy (Bug.Rec ss) ApplyToVal simpl ((g x) `cast` (Sym (Nth:0 (_R -> Data.Functor.Identity.NTCo:Identity[0] _R)) :: Data.Functor.Identity.Identity (Bug.Rec ss) ~R# Data.Functor.Identity.Identity (Bug.Rec ss))) CastIt Nth:1 (_R -> Data.Functor.Identity.NTCo:Identity[0] _R) Stop[BoringCtxt] Bug.Rec ss }}} Notice the second "frame" of the context: `ApplyToVal nodup ((g x) ...)` (7.10.1) in contrast to `ApplyToVal simpl ((g x) ...)` (7.10.2). I'm not yet sure whether this is significant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 17:19:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 17:19:56 -0000 Subject: [GHC] #10559: the 'impossible' happened while building stack In-Reply-To: <046.377c7156f15c8faf6fd87aaa77e340be@haskell.org> References: <046.377c7156f15c8faf6fd87aaa77e340be@haskell.org> Message-ID: <061.1ca81332098ae3553c0441f295c614fd@haskell.org> #10559: the 'impossible' happened while building stack -------------------------------------+------------------------------------- Reporter: barnaby | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: Should be a duplicate of #10322. Try with GHC 7.10.2-rc1? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 17:44:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 17:44:00 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.c090cc6882edc4b7cfc174d19dd6a37e@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I have also noticed that GHC 7.10.1 often appears to by simplifying inside of a `cast` when 7.10.2 is just working inside of `Const`. For instance, it is common to see the `SimplCont` of 7.10.1 terminates with, {{{#!hs CastIt Nth:1 (((forall a6 b. _R -> Control.Applicative.NTCo:Const[0] _R _P)@"field1" Bug.:-> Bug.Expr GHC.Types.Int)@Bug.Rec '["field1" Bug.:-> Bug.Expr GHC.Types.Int, "field2" Bug.:-> Bug.Expr GHC.Types.Int, "id" Bug.:-> Bug.Expr GHC.Types.Int, "event_type" Bug.:-> Bug.Expr GHC.Types.Int]) Stop[BoringCtxt] "field1" Bug.:-> Bug.Expr GHC.Types.Int }}} whereas 7.10.2 will end in, {{{#!hs Stop[BoringCtxt] Control.Applicative.Const ("field1" Bug.:-> Bug.Expr GHC.Types.Int) (Bug.Rec '["field1" Bug.:-> Bug.Expr GHC.Types.Int, "field2" Bug.:-> Bug.Expr GHC.Types.Int, "id" Bug.:-> Bug.Expr GHC.Types.Int, "event_type" Bug.:-> Bug.Expr GHC.Types.Int]) }}} with the inner context being essentially identical. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 17:45:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 17:45:45 -0000 Subject: [GHC] #10552: round on negative fractionals causes a segfault In-Reply-To: <046.e7127d46bf2a13e01474e6019d4d5225@haskell.org> References: <046.e7127d46bf2a13e01474e6019d4d5225@haskell.org> Message-ID: <061.93144ac0d6492b79f3cb2a8006fa798c@haskell.org> #10552: round on negative fractionals causes a segfault ----------------------------------+--------------------------------- Reporter: mmirman | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. This looks like a duplicate of #7043, fixed since GHC 7.8.3 (or earlier). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 18:06:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 18:06:35 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.d2591f0fe659ced4cbe1fe33ee48f888@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Here I compare what the simplifier does to a term of type `"event_type" :-> Int` from my test program in GHC 7.10.1 and 7.10.2. The test program (found here https://github.com/bgamari/ghc-T10527/blob/master/Bug2.hs) is cut down just enough so that it fails with 7.10.2 and succeeds with 7.10.1 with a sufficiently low `simpl-tick-factor` (10). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 18:07:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 18:07:22 -0000 Subject: [GHC] #10539: ghc internal error compiling simple template haskell + lens program In-Reply-To: <049.325e9961b4964885fc9c66aa2a848ba4@haskell.org> References: <049.325e9961b4964885fc9c66aa2a848ba4@haskell.org> Message-ID: <064.1881c8856fbcd71ed616554fad796bf3@haskell.org> #10539: ghc internal error compiling simple template haskell + lens program -------------------------------------+------------------------------------- Reporter: andrew.wja | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: lens Operating System: Linux | template-haskell Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => infoneeded Comment: No because even after adding `{-# LANGUAGE TemplateHaskell, DeriveDataTypeable #-}` I get {{{ Syntax.hs:24:11: Not in scope: ?uniplate? }}} On the other hand, I guess that means the splice `makeLenses ''Arith`, which is probably where GHC crashes for you, has already run successfully, so in that sense I can't reproduce it either. Can you double check the reproducer? Maybe you minimized it too much? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 18:26:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 18:26:37 -0000 Subject: [GHC] #10521: Wrong results in strict Word8 storage on x64 In-Reply-To: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> References: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> Message-ID: <070.29b87a4346619b0bca28f72c6e17cf3f@haskell.org> #10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: VincentBerthoux2 | Owner: rwbarton Type: bug | Status: patch Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D993 -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"a2f828a370b220839ad9b31a274c0198ef91b7fe/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a2f828a370b220839ad9b31a274c0198ef91b7fe" Be aware of overlapping global STG registers in CmmSink (#10521) Summary: On x86_64, commit e2f6bbd3a27685bc667655fdb093734cb565b4cf assigned the STG registers F1 and D1 the same hardware register (xmm1), and the same for the registers F2 and D2, etc. When mixing calls to functions involving Float#s and Double#s, this can cause wrong Cmm optimizations that assume the F1 and D1 registers are independent. Reviewers: simonpj, austin Reviewed By: austin Subscribers: simonpj, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D993 GHC Trac Issues: #10521 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 18:27:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 18:27:12 -0000 Subject: [GHC] #10521: Wrong results in strict Word8 storage on x64 In-Reply-To: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> References: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> Message-ID: <070.cef8c106ab2c95a2ac6ab15ff1330e89@haskell.org> #10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: VincentBerthoux2 | Owner: rwbarton Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D993 -------------------------------------+------------------------------------- Changes (by rwbarton): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 18:28:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 18:28:45 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.b9c17a9c73e8e903a4e492f3a0bedd87@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: rwbarton Type: bug | Status: merge Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: enum01.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D957 -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => merge Comment: I added a description to the processor itself in a7eee0d8a25789ce1ef349304d27e2a5e22766b7. Merge if desired. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 18:51:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 18:51:03 -0000 Subject: [GHC] #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' In-Reply-To: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> References: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> Message-ID: <057.7bc8fd255fa5fe181c8e95eb9d7979cc@haskell.org> #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: attached Blocked By: | Blocking: Related Tickets: #437 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): With optimization enabled, another identifier `main4` appears in the interface file for A, but only when `-main-is A.main` (`ZCMain_main_info` is a jump to `main4`). So because of this change, a new interface file gets written out, which then has the correct flag hash as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 18:59:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 18:59:33 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.63c9add8fe37cd3de83fbd2fa0260a48@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+----------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by rwbarton): I'm a little worried about whether the obvious fix for this (adding `-lfoo` to the gcc command line for building the temporary shared objects for each library `-lfoo` specified on the ghci command line) might cause #8935 to occur again in some configurations. If we add every library that we've loaded there then what was the point of loading the libraries with RTLD_LOCAL? Possibly we only need to use RTLD_LOCAL when building the ghci linker statically? Then we could revert the other changes like #10322 and #10110 and #10058. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 19:11:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 19:11:07 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.5fbd814bc09f1314dd8766108a9fdb2f@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by trommler): Hmm, this issue is different. In #10322 we are linking temporary shared libraries. Here the problem is that the shared library for package GLUT cannot be loaded because of a missing symbol. Which shared library contains the missing `_glutBitmap8By13` ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 19:14:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 19:14:18 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.b4ea660d9462171acd5b953552ee1672@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): One obvious qualitative difference between the two simplifier trajectories is that the 7.10.2 stops emits its last `SimplBind` trace (for `$s$crsubset_s2gQ`) somewhere around 13% through the log (measured in lines). In contrast, 7.10.1 emits `SimplBinds` every regularly (at most every few hundred lines) throughout the log. I suppose this means that 7.10.2 is spending most of its time playing with this one top-level binding? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 19:15:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 19:15:56 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.d8ccc458e64b5a2349883e0dbfc30b98@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by rwbarton): I agree with jpbernardy that generating an empty case on (or equivalently forcing) the first argument would be more correct than producing a new error. However, it seems that in this case the "blame" could be assigned to jpbernardy, who wrote the original report with `instance Eq D where (==) = undefined` :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 19:17:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 19:17:09 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.5fe05958faa7fcd19c3b465fa95271de@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): Right, it's not #10322, but rather #10458. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 19:26:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 19:26:28 -0000 Subject: [GHC] #10564: GHC 7.10.2 RC cannot build HList-0.4.0.0 In-Reply-To: <047.d3b7b31aab7749db694d46171b616686@haskell.org> References: <047.d3b7b31aab7749db694d46171b616686@haskell.org> Message-ID: <062.08aa0cbceb34f90d49461954380b8a18@haskell.org> #10564: GHC 7.10.2 RC cannot build HList-0.4.0.0 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => high Comment: Setting priority to high since it is a regression (or a change, at least) since 7.10.1. Probably relevant is that the type classes involved are polykinded; I got too confused trying to work out the interaction between functional dependencies and polykinds to determine whether the program should be accepted or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 20:18:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 20:18:39 -0000 Subject: [GHC] #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) In-Reply-To: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> References: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> Message-ID: <057.42d864310b6706824cf054e977d5a19f@haskell.org> #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: testcase Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): nomeata, sorry if I am missing something obvious, but this ticket seems to be about the time stamp not appearing in the interface hash, so the fact that this ticket is just waiting for a test is not incompatible with the interface hash including the file name. Currently we need the .h file name in the interface file so that we can check whether the file fingerprint matches, and we use the interface hash to determine whether to write a new interface file, so it's not immediately obvious that we can avoid putting the file name in the interface hash. Maybe you'd like to create a new ticket about finding some way to avoid this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 21:08:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 21:08:25 -0000 Subject: [GHC] #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) In-Reply-To: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> References: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> Message-ID: <057.f80a157f08e629e1e20f2c86e3431f66@haskell.org> #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: testcase Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > and we use the interface hash to determine whether to write a new interface file, Ah, this is new to me. I assumed that when a module is compiled, its interface is written, and the interface hash is only used to decide whether to rebuild another module or not. But you are right, this deserves a separate ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 21:43:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 21:43:21 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.83fb95cc81167f404445b0ee52e93494@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by George): Replying to [comment:3 trommler]: > Can you try with HEAD and/or the tip of the 7.10 branch, please. Sorry I can't although what is reported is close to the tip of the branch, i.e. 7.10.1.20150612 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 21:51:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 21:51:55 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.3382438ce13cf848e1fe60f319265910@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by George): Replying to [comment:5 rwbarton]: > Right, it's not #10322, but rather #10458. Sorry I don't understand how it can be #10458, can you explain? The error I reported {{{ : can't load .so/.DLL for: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib (dlopen(/Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib, 5): Symbol not found: _glutBitmap8By13 Referenced from: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib Expected in: flat namespace in /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib) }}} seeems quite different than the one in #10458: {{{ Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0... GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help /usr/bin/ld: dist/build/etamoo/etamoo-tmp/src/cbits/crypt.o: relocation R_X86_64_PC32 against undefined symbol `crypt' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} In addition #10458 does not mention regression and it is on Linux. This bug is a regression from 7.8.4 and happens on the Mac but not on Linux. From https://github.com/haskell-opengl/GLUT/issues/19: {{{ I checked it under GHC 7.8.4 and $ ghci -package GLUT works fine (loads the package and shows the prompt). ... OK, so this seems to be unrelated to TH and to the specific Mac OS X version. Do you have GHC 7.8.3 or 7.8.4 on your Mac to check if this is a GHC 7.10 regression? In the meantime I'll try to get 7.10 running on a Mac, but this might take some time, normally I develop on Windows + Linux only, so some help would be appreciated. ... The consensus seems to be that this is a GHC 7.8.4 => 7.10.1 regression }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 22:02:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 22:02:57 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.31e91fa04aef2c79b275d7ae16c98976@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by George): Replying to [comment:4 trommler]: > Hmm, this issue is different. In #10322 we are linking temporary shared libraries. Here the problem is that the shared library for package GLUT cannot be loaded because of a missing symbol. > > Which shared library defines the missing `_glutBitmap8By13` ? Not sure if this helps but from https://github.com/haskell- opengl/GLUT/issues/19: tried loading the OSX's GLUT.framework manually: $ ghci -framework GLUT -package GLUT but it produces the same error message. ghci -framework GLUT -package GLUT GHCi, version 7.10.1.20150612: http://www.haskell.org/ghc/ :? for help : can't load .so/.DLL for: /Library/Haskell/ghc-7.10.1.20150612-x86_64 /lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA- ghc7.10.1.20150612.dylib (dlopen(/Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib, 5): Symbol not found: _glutBitmap8By13 Referenced from: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib Expected in: flat namespace in /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib) To be sure I checked the OSX's GLUT.framework, it does contain the _glutBitmap8By13 symbol. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 22:04:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 22:04:02 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.e424d989c22fa5f8d7a2d9fbadc195fd@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): Sorry, you're right. These error messages are entirely too long :( (Though I don't see anyone claiming on the GLUT thread that it actually works on Linux; but I tested and it does work for me.) Seems to be a new issue, and may even be cabal's fault since it does the final link itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 22:16:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 22:16:51 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.3393997cdaf86eae9f9eac3c74300288@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10561 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): It looks like {{{PolyKinds}}} also breaks deriving {{{Data}}} instances as well: {{{#!hs {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE PolyKinds #-} import Data.Data newtype WrappedFunctor f a = WrapFunctor (f a) deriving (Data, Typeable) }}} This will result in the error: {{{ No instance for (Typeable a) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Data (WrappedFunctor f a)) }}} (Presumably, it's trying to infer the instance context {{{Data (f a), Typeable f, Typeable a) => Data (WrappedFunctor f a)}}}, but can't.) I'm not sure if this is due to the same underlying issue, but it seems likely, since that code will compile without {{{PolyKinds}}}. I reproduced this on GHC 7.8, 7.10, and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 22:45:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 22:45:23 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.0fdd973899978423bd609c6711405e47@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Well, I quickly bisected get an idea of what I should be looking for. It seems like the regression was introduced by the fix for the huge space leak in the mighty simplifier (8af219adb914b292d0f8c737fe0a1e3f7fb19cf3). If I understand correctly this patch touched code surrounding the treatment of interesting arguments. Perhaps an inadvertent change here is now resulting in more inlining than we would like. I'll have another look after I've slept on it to see if this revelation gets us any closer to a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 25 23:11:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Jun 2015 23:11:05 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.c0fa97a032d37ef75044d909f3de50fb@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Reading through the patch it indeed seems that the `NoDup` to `Simplified` change that I noticed above could have arisen out of this commit. See the treatment of `simplArg` for https://phabricator.haskell.org/rGHC8af219adb914b292d0f8c737fe0a1e3f7fb19cf3#C60694NL1193 for how. That being said, using `dup_flag` instead of `Simplified` on line 1203 doesn't seem to help. I'll need more sleep to get any further I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 01:06:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 01:06:41 -0000 Subject: [GHC] #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts Message-ID: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts -------------------------------------+------------------------------------- Reporter: anders_ | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- For numbers other than 1, anyway. {{{ $ ghc -e 'Data.Bits.shiftL 1 (-1)' -9223372036854775808 $ ghc -e 'Data.Bits.shiftL 2 (-1)' zsh: segmentation fault ghc -e 'Data.Bits.shiftL 2 (-1)' $ ghc -e 'Data.Bits.shiftL 100 (-1)' zsh: segmentation fault ghc -e 'Data.Bits.shiftL 100 (-1)' }}} This also happens with a compiled program. It doesn't with {{{shiftR}}} in either case though. Side notes: - On OS X, when the first operand is also negative, I get a {{{bus error}}} instead of a {{{segmentation fault}}}. Linux gives {{{segmentation fault}}} on both. - On Linux, you have to use {{{ghci}}} instead of {{{-e}}}, for some (probably unrelated?) reason). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 01:39:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 01:39:11 -0000 Subject: [GHC] #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts In-Reply-To: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> References: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> Message-ID: <061.cfa30ba08804e7c6d5039204dcf29c37@haskell.org> #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts -------------------------------------+------------------------------------- Reporter: anders_ | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: hvr (added) * priority: normal => high Comment: The documentation for `shiftL` does say "the specified number of bits (which must be non-negative)", so the first case might be okay, but crashing is too much. The whole `shift`/`shiftL`/`shiftR` thing seems a little dubious to me in general, but surely for Integer we should test the sign of the shift in `shiftL`/`shiftR` and produce the expected result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 03:16:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 03:16:20 -0000 Subject: [GHC] #10572: Template Haskell does not implicitly quantify types Message-ID: <045.ba132a89df5c5be9ce7705320ad52764@haskell.org> #10572: Template Haskell does not implicitly quantify types -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.1 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider the simple quasiquoter producing a type variable: {{{ tv :: QuasiQuoter tv = QuasiQuoter { quoteType = varT . mkName } }}} If a type variable is introduced elsewhere in a type signature, it is implicitly quantified as normal and the TH name resolves properly: {{{ id' :: a -> [tv|a|] id' x = x }}} But if the type variable is not mentioned elsewhere in the type, an error results: {{{ const' :: a -> [tv|b|] -> a const' x _ = x }}} {{{ Not in scope: type variable ?b? }}} One would expect the type variable introduced by the TH splice to be included in the implicit quantification of the type signature. In fact, there is no way to introduce a new type variable in this context, apart from using {{{Rank(2/N)Types}}} with an explicit {{{forall}}}. But this prevents the type variable from being referred to elsewhere in the type, eg: {{{ const'' :: [tv|a|] -> b -> [tv|a|] const'' x _ = x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 04:13:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 04:13:02 -0000 Subject: [GHC] #10550: Drop truncated package name prefix from package keys In-Reply-To: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> References: <045.59c97210dfe934c485a09cdff4db913c@haskell.org> Message-ID: <060.d0d649ef4fa682c4a2c91a5c98d1df5e@haskell.org> #10550: Drop truncated package name prefix from package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Package system | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1011 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 04:14:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 04:14:37 -0000 Subject: [GHC] #10572: Template Haskell does not implicitly quantify types In-Reply-To: <045.ba132a89df5c5be9ce7705320ad52764@haskell.org> References: <045.ba132a89df5c5be9ce7705320ad52764@haskell.org> Message-ID: <060.ae30592c3fc2d4866457540aec029859@haskell.org> #10572: Template Haskell does not implicitly quantify types -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by spinda: Old description: > Consider the simple quasiquoter producing a type variable: > > {{{ > tv :: QuasiQuoter > tv = QuasiQuoter { quoteType = varT . mkName } > }}} > > If a type variable is introduced elsewhere in a type signature, it is > implicitly quantified as normal and the TH name resolves properly: > > {{{ > id' :: a -> [tv|a|] > id' x = x > }}} > > But if the type variable is not mentioned elsewhere in the type, an error > results: > > {{{ > const' :: a -> [tv|b|] -> a > const' x _ = x > }}} > > {{{ > Not in scope: type variable ?b? > }}} > > One would expect the type variable introduced by the TH splice to be > included in the implicit quantification of the type signature. > > In fact, there is no way to introduce a new type variable in this > context, apart from using {{{Rank(2/N)Types}}} with an explicit > {{{forall}}}. But this prevents the type variable from being referred to > elsewhere in the type, eg: > > {{{ > const'' :: [tv|a|] -> b -> [tv|a|] > const'' x _ = x > }}} New description: Consider this simple quasiquoter producing a type variable: {{{ tv :: QuasiQuoter tv = QuasiQuoter { quoteType = varT . mkName } }}} If a type variable is introduced elsewhere in a type signature, it is implicitly quantified as normal and the TH name resolves properly: {{{ id' :: a -> [tv|a|] id' x = x }}} But if the type variable is not mentioned elsewhere in the type, an error results: {{{ const' :: a -> [tv|b|] -> a const' x _ = x }}} {{{ Not in scope: type variable ?b? }}} One would expect the type variable introduced by the TH splice to be included in the implicit quantification of the type signature. In fact, there is no way to introduce a new type variable in this context, apart from using {{{Rank(2/N)Types}}} with an explicit {{{forall}}}. But this prevents the type variable from being referred to elsewhere in the type, eg: {{{ const'' :: [tv|a|] -> b -> [tv|a|] const'' x _ = x }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 05:30:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 05:30:34 -0000 Subject: [GHC] #10573: Generalize forever to Applicative Message-ID: <047.69a95e7ce51e2fd0eb11bda65dfbf5a4@haskell.org> #10573: Generalize forever to Applicative -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: AMP | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This was proposed a month ago (https://mail.haskell.org/pipermail/libraries/2015-May/025711.html), and all the responses were positive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 05:31:13 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 05:31:13 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.87bb81a0aa3ecf550bf7aee775a9dd5a@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mitchty): It appears I'm hitting an instance of this, or a related case after porting ghc to Alpine Linux. Though the situation I'm encountering is slightly different, the error I see is the same as rwbarton noted earlier with the stg function. What I am seeing with a ghc --make test.hs compile of a really simple haskell program: https://gist.githubusercontent.com/mitchty/296be0fd030aba6aa7b5/raw/f845993582c32e9b8e4e1752d64f7f1a9b3fc1aa/make.out If you note from that make.out example, stg_bh_upd_frame_info is not PIC after its been statically linked. To explain a bit more, Alpine linux is setup to compile with PIE executables by default, as well as PIC libraries. This can be changed for errant things which cannot use aslr if needed, but the default ABI requires PIE/PIC. Effectively Alpine linux is running the same as Debian when hardened. However if necessary you can use an escape hatch of -nopie -fno-PIC, which is how I had to port ghc. This presents a problem however, as it appears ghc will not emit PIC assembly in this case. Nor is there apparently an option to do so that one can toggle via configure or auto tools or editing the settings file directly to achieve that goal. What would appear to be needed here after chatting with rwbarton on irc is some way to have ghc emit PIC assembly on Linux x86_64 platforms when necessary. Note that in the case of Alpine Linux, we would want PIC/PIE to always be on. For Debian hardened that may not hold true in that ghc itself might need to be built as a pie executable but executables it creates in this situation may not need to be pie. As an example, gcc on Alpine Linux has the following macros set by default with no feature switches enabled to gcc: $ echo ";" | gcc -E -dD -c -| grep PIC #define __PIC__ 2 $ echo ";" | gcc -E -dD -c -| grep PIE #define __PIE__ 2 Also note, unlike the Debian hardening, there is no easy way to change these defaults outside of possibly recompiling gcc. From the discussion in irc the following two options seem reasonable: - Add a value to the settings file to control if ghc will emit PIC assembly by default or not - Possibly attempt to detect that the Linux in use requires PIC/PIE via some trick like the above gcc preprocessor dumps The latter may be a better option overall but I will need to compare against the other hardened linux flavors in all their possible settings. As an example Gentoo linux allows you to change the gcc hardened settings at run time, which would make detection of the "right" thing to do rather difficult. Similar behavior would apply to fedora as well. I'm not sure the correct way forward but for the moment a setting to adjust what type of assembly ghc emits would seem the best option. Right now I have to force all binaries to be nopie as a workaround to this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 06:51:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 06:51:05 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.c2659f75c65c57831a5ebcd8b0859a28@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by trommler): Replying to [comment:4 trommler]: > Hmm, this issue is different. In #10322 we are linking temporary shared libraries. Here the problem is that the shared library for package GLUT cannot be loaded because of a missing symbol. > > Which shared library defines the missing `_glutBitmap8By13` ? On my Linux box `glutBitmap8By13` is defined in `libglut.so`. Could you check if `_glutBitmap8By13` is defined in the GLUT framework on Mac OS. Perhaps another Framework defines that symbol and thus needs to be linked too. In Mach-O symbols are not reexported by default (we discussed that in #10322). This is different from ELF. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 06:56:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 06:56:52 -0000 Subject: [GHC] #10572: Type signatures are not implicitly quantified over TH type variables (was: Template Haskell does not implicitly quantify types) In-Reply-To: <045.ba132a89df5c5be9ce7705320ad52764@haskell.org> References: <045.ba132a89df5c5be9ce7705320ad52764@haskell.org> Message-ID: <060.3c95259758d840d349a6686db35a56ca@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: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 07:22:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 07:22:09 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.f5f029f8e4ed65294cd205eb65498ecf@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 07:29:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 07:29:46 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.2261b456760e4cc81342bf9d22bade92@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by slyfox): I propose to extent SysTools.hs:getCompilerInfo to detect PIC at ghc startup time as we do with gcc/clang and set fPIC default accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 07:32:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 07:32:43 -0000 Subject: [GHC] #10482: Not enough unboxing happens on data-family function argument In-Reply-To: <043.b6b30783c65ab27e97e75d03aac8ab21@haskell.org> References: <043.b6b30783c65ab27e97e75d03aac8ab21@haskell.org> Message-ID: <058.43a8a10b0f342d4056da8594500f04e2@haskell.org> #10482: Not enough unboxing happens on data-family function argument -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0b7e538a09bc958474ec704063eaa08836e9270e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0b7e538a09bc958474ec704063eaa08836e9270e" Allow recursive unwrapping of data families When doing strictness analysis, we need to look inside products. To avoid unpacking infinitely, we must be careful about infinite types. That in turn is controlled by TyCon.checkRecTc. For data families like data instance T (a,b) = MkT a (T b) we want to unpack the thing recursively for types like T (Int, (Int, (Int, Int))) This patch elaborates the checkRecTc mechanism in TyCon, to maintain a *count* of how many times a TyCon has shown up, rather than just a boolean. A simple change, and a useful one. Fixes Trac #10482. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 07:32:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 07:32:43 -0000 Subject: [GHC] #10569: Treat an out-of-scope variable like a typed hole In-Reply-To: <046.67d84e7549a910d711bf04ba8ad86bb4@haskell.org> References: <046.67d84e7549a910d711bf04ba8ad86bb4@haskell.org> Message-ID: <061.ab1f677647ba7b876cb33321788f6c23@haskell.org> #10569: Treat an out-of-scope variable like a typed hole -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fb7b6922573af76a954d939c85e6af7c39a19896/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fb7b6922573af76a954d939c85e6af7c39a19896" Treat out-of-scope variables as holes This patch implements the idea in Trac #10569. * An out-of-scope variable is treated as a typed expression hole. * That is, we don't report it in the type checker, not the renamer, and we when we do report it, we give its type. * Moreover, we can defer the error to runtime with -fdefer-typed-holes In implementation terms: * The renamer turns an unbound variable into a HsUnboundVar * The type checker emits a Hole constraint for a HsUnboundVar, and turns it back into a HsVar It was a bit painful to implement because a whole raft of error messages change slightly. But there was absolutely nothing hard in principle. Holes are reported with a bunch of possibly-useful context, notably the "relevant bindings". I found that this was distracting clutter in the very common case of a mis-typed variable that is only accidentally not in scope, so I've arranged to print the context information only for true holes, that is ones starting with an underscore. Unbound data constructors use in patterns, like f (D x) = x are still reportd by the renamer, and abort compilation before type checking. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 08:12:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 08:12:54 -0000 Subject: =?utf-8?b?W0dIQ10gIzEwNTc0OiDCq3RoZSAnaW1wb3NzaWJsZScgaGFwcGVu?= =?utf-8?q?ed=C2=BB_when_compiling_singletons?= Message-ID: <045.61f4a0f8532afd7d0d32e052e46dc85b@haskell.org> #10574: ?the 'impossible' happened? when compiling singletons -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When building the ?singletons? package (v1.1.2.1 from hackage) in a fresh sandbox, GHC panics. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 08:15:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 08:15:22 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.a5b49f4316bf0fd8a88fea001cee61dd@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by Rydgel): Replying to [comment:10 trommler]: > On my Linux box `glutBitmap8By13` is defined in `libglut.so`. Could you check if `_glutBitmap8By13` is defined in the GLUT framework on Mac OS. Perhaps another Framework defines that symbol and thus needs to be linked too. In Mach-O symbols are not reexported by default (we discussed that in #10322). This is different from ELF. It is defined by the GLUT Framework, see: {{{ nm -gU /System/Library/Frameworks/GLUT.framework/Versions/A/GLUT 000000003e01b756 T ___glutGetFCB 000000003e01b7b4 T ___glutSetFCB 000000003e089ea0 S __gle_gc 000000003e02a388 T _gleCreateGC 000000003e027318 T _gleExtrusion 000000003e0271ef T _gleGetJoinStyle 000000003e02733c T _gleGetNumSlices 000000003e0280b2 T _gleHelicoid 000000003e027d1d T _gleLathe 000000003e027656 T _glePolyCone 000000003e02764a T _glePolyCylinder 000000003e0280d4 T _gleScrew 000000003e0271c7 T _gleSetJoinStyle 000000003e027348 T _gleSetNumSlices 000000003e0277d9 T _gleSpiral 000000003e027216 T _gleSuperExtrusion 000000003e02a449 T _gleTextureMode 000000003e0280c3 T _gleToroid 000000003e0276fc T _gleTwistExtrusion 000000003e01751d T _glutAddMenuEntry 000000003e017675 T _glutAddSubMenu 000000003e017816 T _glutAttachMenu 000000003e054480 S _glutBitmap8By13 000000003e056820 S _glutBitmap9By15 000000003e01eb85 T _glutBitmapCharacter ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 08:26:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 08:26:04 -0000 Subject: [GHC] #10575: "unsatisfied constraints" typo Message-ID: <045.95237d2ec1c60db7ff6ad28f67a1da5f@haskell.org> #10575: "unsatisfied constraints" typo -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: low | Milestone: Component: Core | Version: 7.10.1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ UnsatisfiedConstraints -> "unsatisified constraints" }}} should be {{{ UnsatisfiedConstraints -> "unsatisfied constraints" }}} in http://hackage.haskell.org/package/base-4.8.0.0/docs/src/GHC-IO- Exception.html#line-326 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 08:31:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 08:31:53 -0000 Subject: [GHC] #10545: Deadlock in the threaded RTS In-Reply-To: <047.a8d38e087211dfddaa8ecbe3c62bb848@haskell.org> References: <047.a8d38e087211dfddaa8ecbe3c62bb848@haskell.org> Message-ID: <062.885036188efe446aed0a43d0f9807f4f@haskell.org> #10545: Deadlock in the threaded RTS -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"111ba4beda4ffc48381723da12e5b237d7f9ac59/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="111ba4beda4ffc48381723da12e5b237d7f9ac59" Fix deadlock (#10545) yieldCapability() was not prepared to be called by a Task that is not either a worker or a bound Task. This could happen if we ended up in yieldCapability via this call stack: performGC() scheduleDoGC() requestSync() yieldCapability() and there were a few other ways this could happen via requestSync. The fix is to handle this case in yieldCapability(): when the Task is not a worker or a bound Task, we put it on the returning_workers queue, where it will be woken up again. Summary of changes: * `yieldCapability`: factored out subroutine waitForWorkerCapability` * `waitForReturnCapability` renamed to `waitForCapability`, and factored out subroutine `waitForReturnCapability` * `releaseCapabilityAndQueue` worker renamed to `enqueueWorker`, does not take a lock and no longer tests if `!isBoundTask()` * `yieldCapability` adjusted for refactorings, only change in behavior is when it is not a worker or bound task. Test Plan: * new test concurrent/should_run/performGC * validate Reviewers: niteria, austin, ezyang, bgamari Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D997 GHC Trac Issues: #10545 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 11:00:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 11:00:52 -0000 Subject: [GHC] #10576: REPL returns list of all imported names when operator completion requested Message-ID: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> #10576: REPL returns list of all imported names when operator completion requested -------------------------------------+------------------------------------- Reporter: Geraldus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple completions complete command | Type of failure: Incorrect result operator | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When querying completions for operators GHCi returns a list containing all imported names rather than suitable completions. For example, if you simply start GHCi and run `:complete repl ">>"` command it will give you all names from base and Prelude. Then if you import something else, for example `:m +Data.Text`, the result of query will contain names from Data.Text also. In case of projects (`cabal repl`) things are worst, because returned list contains all names imported project-wise and it could be really huge. GHCi behaves similarly with following queries: :complete repl "(>>" :complete repl "Prelude.>>" :complete repl "Prelude.(>>" I only tested this on OS X 10.9, GHC 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 11:43:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 11:43:07 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.23387802917f9294beb3eaa70392734a@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Another simple but perhaps unsurprising observation: If the call to `addBndrRules` in `simplRecBind` is short-circuited (`addBndrRules env _ out_id = return (env, out_id)`) compilation completes. Neither of the other calls to `addBndrRules` have this property when short-circuited. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 12:05:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 12:05:31 -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.54e358e5224368cce57eb66b7f1b3d08@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: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Quite right. Should be easy enough to fix. I'm not going to put the `newcomer` tag on this one, because renaming and scoping and such has tended to be a little challenging, but my guess is that this is straightforward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 12:23:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 12:23:11 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDU3NDogwqt0aGUgJ2ltcG9zc2libGUnIGhh?= =?utf-8?q?ppened=C2=BB_when_compiling_singletons?= In-Reply-To: <045.61f4a0f8532afd7d0d32e052e46dc85b@haskell.org> References: <045.61f4a0f8532afd7d0d32e052e46dc85b@haskell.org> Message-ID: <060.3906597e2d76beebed13c958c9cb91b1@haskell.org> #10574: ?the 'impossible' happened? when compiling singletons -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: This is likely a duplicate of #10251, fixed for GHC 7.10.2. In the meantime, if you say `--ghc-options=-O1` when installing via `cabal`, you should be able to get past this error. I am closing this ticket as a duplicate. If you think this is in error, please reopen. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 13:28:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 13:28:19 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.fa40892249491d41bbe3e4f9243c0153@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by trommler): That is strange the symbol is there. Is it possible that `libHSGLUT...dylib` is not linked against the framework? Could you check? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 14:12:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 14:12:16 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.e37c3171c7f53ebe5d41bedcdf1372a9@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): So what do you think about current StandaloneDeriving implementation? It's already doing what you're complaining. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 14:22:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 14:22:33 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.ac0da1d3fe5ea47d652f24d29d273cc9@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by rwbarton): Indeed. I for one think it should be changed to use an empty case. This ticket might not be the right place to discuss it though, since in any case standalone deriving and ordinary deriving should not produce two different instances. I only skimmed over the patch on Phab, but I assume the same code is used to actually generate the instances in those two cases, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 14:24:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 14:24:31 -0000 Subject: [GHC] #10545: Deadlock in the threaded RTS In-Reply-To: <047.a8d38e087211dfddaa8ecbe3c62bb848@haskell.org> References: <047.a8d38e087211dfddaa8ecbe3c62bb848@haskell.org> Message-ID: <062.58900a9ec899e8bf26ef6a5fb65c24c3@haskell.org> #10545: Deadlock in the threaded RTS -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 14:24:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 14:24:37 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.0fda88655dcf6180d10674d671e3c306@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): > but I assume the same code is used to actually generate the instances in those two cases, right? Right, the whole point is to make those work the same. Either way(e.g. empty case or error) works for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 14:53:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 14:53:11 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.fb6adef5831ee71bb546ee6f0ac2c2ac@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): One thing to note is we need to use current implementation at least for methods like `mempty :: Monoid a => a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 15:03:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 15:03:00 -0000 Subject: [GHC] #10569: Treat an out-of-scope variable like a typed hole In-Reply-To: <046.67d84e7549a910d711bf04ba8ad86bb4@haskell.org> References: <046.67d84e7549a910d711bf04ba8ad86bb4@haskell.org> Message-ID: <061.5a63f03f40c5c3bac27b427363ac6b29@haskell.org> #10569: Treat an out-of-scope variable like a typed hole -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Well I did this in a fit of enthusiasm. I hope you like it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 15:21:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 15:21:35 -0000 Subject: [GHC] #10543: MacOS: validate fails on \u In-Reply-To: <047.a887440a0df817cb06caf9fc53c8c2c9@haskell.org> References: <047.a887440a0df817cb06caf9fc53c8c2c9@haskell.org> Message-ID: <062.d8dfe77b165b1a087244cda73dc5da24@haskell.org> #10543: MacOS: validate fails on \u -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.10.1 Resolution: invalid | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1004 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => invalid Comment: Please open an issue with Homebrew. This line shouldn't be there: https://github.com/Homebrew/homebrew/commit/b160b165d42f07abc912b1903095c593de61a0df #diff-e06a9de6bb362e22e1ceb9a66eaf171eR72 The GHC build system sets `-Wno-unicode` by default when HS_CPP_CMD is `clang`: {{{ $HS_CPP_CMD -x c /dev/null -dM -E > conftest.txt 2>&1 if grep "__clang__" conftest.txt >/dev/null 2>&1; then HS_CPP_ARGS="-E -undef -traditional -Wno-invalid-pp-token -Wno- unicode -Wno-trigraphs" }}] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 15:36:13 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 15:36:13 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.f950b12f821e654877318357e642d3ee@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): If we do so should we apply the options from `-optc-foo` when doing this detection? I was going to object that the C compiler options can vary between input files in a single compilation (with `OPTIONS_GHC`) though technically the same is true of the C compiler program and it looks like we don't currently handle that correctly either. Probably it would not be unreasonably difficult to redo the detection only when the program/options have actually changed. Does the Debian (or Fedora/Gentoo) build system have some extra magic that makes all invocations of gcc produce PIC/PIE by default? Otherwise `ghc -optl-fPIE -optl-pie -optl-Wl,-z,relro -optl-Wl,-z,now` is not going to get the job done in any case, and the build systems will have to learn about how to specify either `-fPIC` or `-optc-fPIC` to `ghc` even if we do this autodetection and it uses the C compiler options. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 15:52:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 15:52:50 -0000 Subject: [GHC] #10576: REPL returns list of all imported names when operator completion requested In-Reply-To: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> References: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> Message-ID: <062.0c4153aca4a0503d42554f6710bc80bc@haskell.org> #10576: REPL returns list of all imported names when operator completion requested -------------------------------------+------------------------------------- Reporter: Geraldus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | completions complete command Type of failure: Incorrect result | operator at runtime | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Geraldus): Same here on Windows with GHC 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 16:12:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 16:12:58 -0000 Subject: [GHC] #10385: Annotation restriction is not respected while generating Annotation via TH In-Reply-To: <046.a42873b06c4b8b607d6d3487710fdc0c@haskell.org> References: <046.a42873b06c4b8b607d6d3487710fdc0c@haskell.org> Message-ID: <061.49956b03c1385fb4523c6fd6dc5a4097@haskell.org> #10385: Annotation restriction is not respected while generating Annotation via TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 16:16:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 16:16:07 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.2c5537e6d479294735828264ff1da531@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => ezyang * component: Compiler => Template Haskell Comment: Edward, I came across this on a sweep of TH tickets. It looks like you should be listed as the owner. Please correct if I'm wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 16:23:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 16:23:10 -0000 Subject: [GHC] #10577: Use empty cases where appropriate when deriving instances for empty types Message-ID: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> #10577: Use empty cases where appropriate when deriving instances for empty types -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In some sense the correct instance for {{{ data X deriving instance Eq X }}} is not (what GHC currently produces) {{{ instance Eq X where (==) = error "Void ==" }}} but rather {{{ instance Eq X where a == b = case a of {} -- using the EmptyCase extension }}} See comments starting at ticket:7401#comment:28 for justification. The list of classes that GHC can currently derive is * Eq, Ord, Enum, Bounded, Show, Read (Haskell 2010 Report) * Functor, Foldable, Traversable, Typeable, Generic, Data, "any class" (`-XDerive*`) Deriving Enum and Bounded is not currently allowed for empty data types. The `showList` method of Show and the whole Read instance are easy and already implemented correctly. All the remaining methods of Haskell 2010 derivable type classes take at least one argument of the instance head type `a`. I propose that all these methods be defined as an empty case on the first such argument. Similarly in Functor, Foldable and Traversable, each method has a single argument of the form `t _` where `t :: * -> *` is the instance head type, and the method should be defined as an empty case on that argument. In all these cases so far, the derived methods for a non-empty type would, at the outermost level, be a (non-empty) case on that first argument, or the equivalent (series of pattern matches, one for each constructor), so the use of an empty case is justified for an empty type. Typeable does not care about the values or even the kind of the type at all, so it's not relevant here. Generic and especially Data are above my pay grade, but generally I expect that methods which are normally defined by case analysis on an argument of the instance head type should be defined by an empty case, and methods that (sometimes) produce a value of the instance head type should do whatever they normally do when unable to produce such a value (like `readsPrec` returning an empty list, or `read` calling `error` (if `read` were actually a method of `Read`)). `DeriveAnyClass` doesn't generate any new code, so like Typeable it's not relevant. None of this behavior is specified by the Haskell 2010 Report, which disallows deriving any class for a type with no constructors; but see #7401. So, we are entitled to do what we think is best here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 16:24:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 16:24:05 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.49fa4fa18162ac126fd7162c3203b66f@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by rwbarton): I created a separate ticket #10577 for the issue of how to define the derived instances of empty types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 16:32:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 16:32:49 -0000 Subject: [GHC] #10578: ghci line numbers are off by one Message-ID: <047.babcd43e2857d19107b478b8249a9812@haskell.org> #10578: ghci line numbers are off by one -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ rwbarton at morphism:/tmp$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> 3 : 'a' :2:5: Couldn't match expected type ?[a]? with actual type ?Char? Relevant bindings include it :: [a] (bound at :2:1) In the second argument of ?(:)?, namely ?'a'? In the expression: 3 : 'a' In an equation for ?it?: it = 3 : 'a' Prelude> 3 : 'a' :3:5: Couldn't match expected type ?[a]? with actual type ?Char? Relevant bindings include it :: [a] (bound at :3:1) In the second argument of ?(:)?, namely ?'a'? In the expression: 3 : 'a' In an equation for ?it?: it = 3 : 'a' Prelude> }}} Why are the errors reported as being on lines 2 and 3? And no, I don't buy that line 1 was the GHCi welcome message :) Apparently it's been like this since at least GHC 7.4 and I've never noticed. `ghc -e cmd1 -e cmd2` reports every command as beginning on a new line 1, which is also weird. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 16:37:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 16:37:01 -0000 Subject: [GHC] #10579: full module names of names not in scope have gone missing in ghci Message-ID: <047.b63d248973b529e66515b0b0ffe3a663@haskell.org> #10579: full module names of names not in scope have gone missing in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compare {{{ rwbarton at morphism:/tmp$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :t GHC.Read.readPrec GHC.Read.readPrec :: Read a => Text.ParserCombinators.ReadPrec.ReadPrec a }}} with {{{ rwbarton at morphism:/tmp$ ~/ghc/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20150624: http://www.haskell.org/ghc/ :? for help Prelude> :t GHC.Read.readPrec GHC.Read.readPrec :: Read a => ReadPrec a }}} The `Text.ParserCombinators.ReadPrec.` bit can be quite helpful, was it suppressed intentionally? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 16:53:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 16:53:05 -0000 Subject: [GHC] #10482: Not enough unboxing happens on data-family function argument In-Reply-To: <043.b6b30783c65ab27e97e75d03aac8ab21@haskell.org> References: <043.b6b30783c65ab27e97e75d03aac8ab21@haskell.org> Message-ID: <058.be7b4116480c6d7e2bb71351d1b9828a@haskell.org> #10482: Not enough unboxing happens on data-family function argument -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0696fc6d4de28cb589f6c751b8491911a5baf774/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0696fc6d4de28cb589f6c751b8491911a5baf774" Improve CPR behavior for strict constructors When working on Trac #10482 I noticed that we could give constructor arguments the CPR property if they are use strictly. This is documented carefully in Note [CPR in a product case alternative] and also Note [Initial CPR for strict binders] There are a bunch of intersting examples in Note [CPR examples] which I have added to the test suite as T10482a. I also added a test for #10482 itself. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 16:53:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 16:53:05 -0000 Subject: [GHC] #10564: GHC 7.10.2 RC cannot build HList-0.4.0.0 In-Reply-To: <047.d3b7b31aab7749db694d46171b616686@haskell.org> References: <047.d3b7b31aab7749db694d46171b616686@haskell.org> Message-ID: <062.a74b0f8b061f9b39484f064c391bb24f@haskell.org> #10564: GHC 7.10.2 RC cannot build HList-0.4.0.0 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7c07cf16ab5d5bdfb64efb1d4fc5f20cf7437437/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7c07cf16ab5d5bdfb64efb1d4fc5f20cf7437437" closeOverKinds *before* oclose in coverage check Combining functional dependencies with kind-polymorphism is devilishly tricky! It's all documented in Note [Closing over kinds in coverage] Fixes Trac #10564 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 16:53:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 16:53:05 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.62cf404d9ca62188cd4c42fa2a8d8c49@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10561 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8e347839be4d52b6f74cc11e18e5820f88969c80/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8e347839be4d52b6f74cc11e18e5820f88969c80" Make fvType ignore kinds TcValidity.fvTypes works in partnership with sizeTypes, and hence should ignore kinds in exactly the same way. It wasn't doing so, which meant that validDerivPred said "No" when it should have said "Yes". That led to the bug reported in Trac #10524 comment:7. The error message is pretty terrible No instance for (Typeable T) but I'll fix that next }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 16:53:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 16:53:05 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.eb640e378411d7de89fbb899bca0f227@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10561 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0e1e7987bdcec0e9be309cbe97fa1c92551997f7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0e1e7987bdcec0e9be309cbe97fa1c92551997f7" Test Trac #10524 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 16:53:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 16:53:05 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.703a47e709ec26c4be0fa335241679bd@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10561 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ceb3c8448dfba23aa98a710f846304158c1c584b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ceb3c8448dfba23aa98a710f846304158c1c584b" Improve error message for Typeable k (T k) GHC can't yest build a TypeRep for a type involving kind variables. (We await kinds = types for that.) But the error message was terrible, as fixing #10524 reminded me. This improves it a lot. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 17:00:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 17:00:07 -0000 Subject: [GHC] #10576: REPL returns list of all imported names when operator completion requested In-Reply-To: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> References: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> Message-ID: <062.1ca228683533fd78ff0257690f8341d5@haskell.org> #10576: REPL returns list of all imported names when operator completion requested -------------------------------------+------------------------------------- Reporter: Geraldus | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | completions complete command Type of failure: Incorrect result | operator at runtime | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9996 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie * related: => #9996 Comment: Also reported as #9996. The problem comes from using the default `word_break_chars` when completing identifiers in `ghc/ghc/InteractiveUI.hs`: {{{ -- We initialize readline (in the interactiveUI function) to use -- word_break_chars as the default set of completion word break characters. -- This can be overridden for a particular command (for example, filename -- expansion shouldn't consider '/' to be a word break) by setting the third -- entry in the Command tuple above. -- -- NOTE: in order for us to override the default correctly, any custom entry -- must be a SUBSET of word_break_chars. word_break_chars :: String word_break_chars = let symbols = "!#$%&*+/<=>?@\\^|-~" specials = "(),;[]`{}" spaces = " \t\n" in spaces ++ specials ++ symbols wrapIdentCompleter = wrapCompleter word_break_chars }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 17:03:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 17:03:28 -0000 Subject: [GHC] #10576: REPL returns list of all imported names when operator completion requested In-Reply-To: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> References: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> Message-ID: <062.eb7ca244851d442004c1e460abebf9d3@haskell.org> #10576: REPL returns list of all imported names when operator completion requested -------------------------------------+------------------------------------- Reporter: Geraldus | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | completions complete command Type of failure: Incorrect result | operator at runtime | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9996 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Geraldus): My little investigation lead me to `completeQuotedWord` function, but I can't follow any further now because I can't find where it comes from: `completeCmd` [1] -> -> [2] -> `ghciCompleteWord` [3] -> [4] -> `completeExpression` [5] {{{ completeExpression = completeQuotedWord (Just '\\') "\"" listFiles completeIdentifier }}} [1]:https://github.com/ghc/ghc/blob/d20031d4c88b256cdae264cb05d9d850e973d956/ghc/InteractiveUI.hs#L2481 [2]:https://github.com/ghc/ghc/blob/d20031d4c88b256cdae264cb05d9d850e973d956/ghc/InteractiveUI.hs#L2484 [3]:https://github.com/ghc/ghc/blob/d20031d4c88b256cdae264cb05d9d850e973d956/ghc/InteractiveUI.hs#L2528 [4]:https://github.com/ghc/ghc/blob/d20031d4c88b256cdae264cb05d9d850e973d956/ghc/InteractiveUI.hs#L2535 [5]:https://github.com/ghc/ghc/blob/d20031d4c88b256cdae264cb05d9d850e973d956/ghc/InteractiveUI.hs#L2639 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 17:09:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 17:09:18 -0000 Subject: [GHC] #10576: REPL returns list of all imported names when operator completion requested In-Reply-To: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> References: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> Message-ID: <062.76acc1c01695d82ee4d939f976a0226e@haskell.org> #10576: REPL returns list of all imported names when operator completion requested -------------------------------------+------------------------------------- Reporter: Geraldus | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | completions complete command Type of failure: Incorrect result | operator at runtime | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9996 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Geraldus): > The problem comes from using the default `word_break_chars` Oh, so I suppose potential solution is to check if prefix to be completed starts with operator symbol, and if the case do not use `wrapIdentCompleter` in `completeIdentifier`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 17:33:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 17:33:39 -0000 Subject: [GHC] #10578: ghci line numbers are off by one In-Reply-To: <047.babcd43e2857d19107b478b8249a9812@haskell.org> References: <047.babcd43e2857d19107b478b8249a9812@haskell.org> Message-ID: <062.c36b06240f0035e9ec8411bbf25ef461@haskell.org> #10578: ghci line numbers are off by one -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Try {{{ :set prompt "\955:%l> " :set prompt2 "\955:%l| " }}} :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 17:43:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 17:43:27 -0000 Subject: [GHC] #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts In-Reply-To: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> References: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> Message-ID: <061.780538295f31e29291bc1dce31c46c26@haskell.org> #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts -------------------------------------+------------------------------------- Reporter: anders_ | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Right now, {{{#!hs instance Bits Integer where -- ... shift x i@(I# i#) | i >= 0 = shiftLInteger x i# | otherwise = shiftRInteger x (negateInt# i#) shiftL x (I# i#) = shiftLInteger x i# shiftR x (I# i#) = shiftRInteger x i# -- ... }}} The simplest fix would be to simply rename `shift{L,R}` to `unsafeShift{L,R}` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 18:39:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 18:39:49 -0000 Subject: [GHC] #10580: rejected emails for Trac registrations from https://ghc.haskell.org/trac/haskell-prime Message-ID: <042.fca6bf75ceadc97246c14a092e17cda4@haskell.org> #10580: rejected emails for Trac registrations from https://ghc.haskell.org/trac /haskell-prime -------------------------------------+------------------------------------- Reporter: imz | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I can't receive the confirmation email for my registration as i_m_z_ (with email address imz at altlinux.org) from https://ghc.haskell.org/trac /haskell-prime . The reason apparently is the one that often comes up with automatically sent confirmation email from such site, and has been described at http://en.altlinux.org/Non- delivery_of_email_sent_by_automated_services_to_altlinux.org : your server doesn't pass "sender-callback-verification" Please make your service better and make possible for more people to receive their confirmation messages needed to complete their registration -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 19:26:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 19:26:09 -0000 Subject: [GHC] #10521: Wrong results in strict Word8 storage on x64 In-Reply-To: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> References: <055.06bb34dbe22dd199ce902b666aaeeb6e@haskell.org> Message-ID: <070.10f44e360f7717c1179f3e6f31c6532c@haskell.org> #10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: VincentBerthoux2 | Owner: rwbarton Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D993 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 19:26:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 19:26:37 -0000 Subject: [GHC] #10545: Deadlock in the threaded RTS In-Reply-To: <047.a8d38e087211dfddaa8ecbe3c62bb848@haskell.org> References: <047.a8d38e087211dfddaa8ecbe3c62bb848@haskell.org> Message-ID: <062.a361b461c7f352a4941af7555277b9ac@haskell.org> #10545: Deadlock in the threaded RTS -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (I also pulled in be0ce8718ea40b091e69dd48fe6bc62b6b551154). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 19:26:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 19:26:48 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.f57861541098998bf78c2cb6756103fb@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: rwbarton Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Test Suite | Version: 7.8.3 Resolution: fixed | Keywords: cpp Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: enum01.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D957 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.2 Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 20:13:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 20:13:53 -0000 Subject: [GHC] #10547: feature request: expanding type synonyms in error messages In-Reply-To: <043.c20ed6dece31f72a0d7c2a22033dd48e@haskell.org> References: <043.c20ed6dece31f72a0d7c2a22033dd48e@haskell.org> Message-ID: <058.9e3e8b90ef0b39aafe70d5b16183ec0e@haskell.org> #10547: feature request: expanding type synonyms in error messages -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D1016 -------------------------------------+------------------------------------- Changes (by osa1): * differential: => D1016 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 20:22:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 20:22:51 -0000 Subject: [GHC] #10581: Recommend ScopedTypeVariables Message-ID: <047.ebee173d1dfb8530d61c89de5afef934@haskell.org> #10581: Recommend ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The !ScopedTypeVariables extension is one of the few that doesn't recommend itself when it should be used. I recognize that this may be hard to do, but here is a strawman proposal: Always behave as if !ScopedTypeVariables is on at binding sites for type variables (in an annotation with `forall`). Then, at ''occurrences'' of type variables, check if the extension is on. If a type variable is in scope but the extension is off, remember that the user probably wants the extension, but then rename the type variable occurrence away from the in- scope one. If a type error ensues, we've remembered that the lack of !ScopedTypeVariables may be to blame, and we recommend turning it on. There may be better approaches, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 20:27:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 20:27:52 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.a6cff6d436af3aead282e0876fb72333@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by slyfox): Replying to [comment:18 rwbarton]: > If we do so should we apply the options from `-optc-foo` when doing this detection? I think we need to ignore -optc during autodetection and should check only vanilla pgmC. It should simplify meaning of ghc -fPIC -optc-fno-PIC. I would say ghc -fno-PIC should disable PIC for both gcc/ghc even if fPIC is a default. > I was going to object that the C compiler options can vary between input files in a single compilation (with `OPTIONS_GHC`) though technically the same is true of the C compiler program and it looks like we don't currently handle that correctly either. Probably it would not be unreasonably difficult to redo the detection only when the program/options have actually changed. > > Does the Debian (or Fedora/Gentoo) build system have some extra magic that makes all invocations of gcc produce PIC/PIE by default? Otherwise `ghc -optl-fPIE -optl-pie -optl-Wl,-z,relro -optl-Wl,-z,now` is not going to get the job done in any case, and the build systems will have to learn about how to specify either `-fPIC` or `-optc-fPIC` to `ghc` even if we do this autodetection and it uses the C compiler options. Hardened gentoo patches gcc to default to -fPIC -fPIE -pie. Defaults there: {{{ # gcc -dM -E - < /dev/null | grep -E -i 'pic|pie' #define __pie__ 2 #define __PIE__ 2 #define __pic__ 2 #define __PIC__ 2 }}} What bothers me is -optl-pie seems not to work even for -split-objs case on vanilla gcc/ghc: {{{ $ echo 'main = print "hello"' > a.hs $ ghc --make -optl-pie -fPIC -optc-fPIC -dynamic a.hs -fforce-recomp [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... $ ghc --make -optl-pie -fPIC -optc-fPIC -dynamic a.hs -fforce-recomp -split-objs [1 of 1] Compiling Main ( a.hs, a.o ) /usr/lib/gcc/x86_64-pc-linux-gnu/5.1.0/../../../../x86_64-pc-linux- gnu/bin/ld: -r and -shared may not be used together collect2: error: ld returned 1 exit status }}} An evil corner case as we use ld for partial linking. Can be an argument for native fPIE/pie support in ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 20:37:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 20:37:22 -0000 Subject: [GHC] #10577: Use empty cases where appropriate when deriving instances for empty types In-Reply-To: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> References: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> Message-ID: <062.dcad4b9fcb271fa458a4dc345164cee3@haskell.org> #10577: Use empty cases where appropriate when deriving instances for empty types -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by osa1): * cc: omeragacan@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 26 23:58:13 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Jun 2015 23:58:13 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.d9dad3cf4caa75852d74aa665df26681@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by Rydgel): Disclaimer: I'm not a pro on "linking" subjects but I did use otool (not sure if it's the way to do it properly on os x): {{{ otool -L .cabal-sandbox/lib/x86_64-osx- ghc-7.10.1/GLUT-2.7.0.1-0waW9bZutCf5s5H5zSV4Oh/libHSGLUT-2.7.0.1 -0waW9bZutCf5s5H5zSV4Oh-ghc7.10.1.dylib .cabal-sandbox/lib/x86_64-osx- ghc-7.10.1/GLUT-2.7.0.1-0waW9bZutCf5s5H5zSV4Oh/libHSGLUT-2.7.0.1 -0waW9bZutCf5s5H5zSV4Oh-ghc7.10.1.dylib: @rpath/libHSGLUT-2.7.0.1-0waW9bZutCf5s5H5zSV4Oh-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHScontainers-0.5.6.2-47ajk3tbda43DFWyeF3oHQ-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSOpenGL-2.12.0.1-EpjHCLjhm8PK9gj1WiMLLT-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHStext-1.2.0.4-IINWRW1LxFGIctooOLjJAI-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSbytestring-0.10.6.0-6vj5EoliHgNHISHCVCb069-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSdeepseq-1.4.1.1-FpR4obOZALU1lutWnrBldi-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSStateVar-1.1.0.0-FY7FZJIuVXGGZZi7Rs1xyW-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSstm-2.4.4-877J9sNBpfS5cK4JeYiRK0-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSarray-0.5.1.0-FaHmcBFfuRM8kmZLEY8D5S-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSObjectName-1.1.0.0-Fs9LwEoYTY29YOLwQayVnG-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSGLURaw-1.5.0.1-9IfVeAwyYToLvYIDA0QjxP-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSOpenGLRaw-2.5.0.0-GkhI7NuLynWIs968DbpvQs-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHStransformers-0.4.2.0-ALYlebOVzVI4kxbFX5SGhm-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSbase-4.8.0.0-I5BErHzyOm07EBNpKBEeUv-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSghc-prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) }}} I don't see any reference to GLUT framework though I don't think it is the issue. Let me explain: I checked a similar project with an OpenGL lib that use the Mac OS X OpenGL Framework. He does not show up inside the {{{libHSOpenGLRaw...dylib}}} too, but GHCI is working fine and the bindings work. ---- I also tried something else: instead of using GLUT as a library for a project, I cloned the project itself and tried to load it up on GHCI. Building seems fine but the result of loading the lib in the repl is the same though the error is slightly different: {{{ cabal repl Resolving dependencies... Configuring GLUT-2.7.0.1... Preprocessing library GLUT-2.7.0.1... GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/gb/2s37knjd0kjg9w40npfwkh0c0000gn/T/ghc92017_0/libghc92017_1.dylib, 5): Symbol not found: _glutBitmap8By13 Referenced from: /var/folders/gb/2s37knjd0kjg9w40npfwkh0c0000gn/T/ghc92017_0/libghc92017_1.dylib Expected in: flat namespace in /var/folders/gb/2s37knjd0kjg9w40npfwkh0c0000gn/T/ghc92017_0/libghc92017_1.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 02:44:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 02:44:24 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.c3eaf6b9b35dda7d90b4db785c248acc@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): I've only seen this Ticket today, but the exit code has been bugging me. Getting a 127 on a SEH error is odd. Building the files I was able to re-produce the error using a fresh Win 2008 R2 VM. However running the application outside of a console or using dependencywalker that 127 became clear. I was missing the proper visual c++ runtime file. Hence the 127 which is usually "missing command" or "missing file". Can you try running dependency walker to see if you have any missing dependencies? Installing the proper VCRedist solved the first problem for me and the application then threw an unhandled exception resulting in a APPLICATION_FAULT_SEHOP and another crash. but the first part of the result is written. I have issues remote debugging on the VM so I didn't look further into this. I currently get: {{{ PS E:\> .\TestExceptions.exe Called foo() with bar=0 PS E:\> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 03:02:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 03:02:02 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.c590cece37ddb7d80189f949f29e2914@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 03:03:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 03:03:56 -0000 Subject: [GHC] #7662: Improve GC of mutable objects In-Reply-To: <045.1df59d879ca14d9200a5a4cc6e9474e1@haskell.org> References: <045.1df59d879ca14d9200a5a4cc6e9474e1@haskell.org> Message-ID: <060.6cefe3d18937b284eddc228b2d12d80c@haskell.org> #7662: Improve GC of mutable objects -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 04:19:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 04:19:49 -0000 Subject: [GHC] #10582: Tiny bug in lexer around lexing banana brackets Message-ID: <047.08a52be5ab9ac23a1408480f99ba99e9@haskell.org> #10582: Tiny bug in lexer around lexing banana brackets -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If I say {{{ {-# LANGUAGE Arrows #-} (|:) :: Int -> Int -> Int (|:) = (+) }}} I get {{{ /Users/rae/temp/Bug.hs:3:3: parse error on input ?:? }}} Trying this with other operators, like `(|+)`, works fine. The problem is that `notFollowedBySymbol` in Lexer.x is slightly wrong. I will fix in ongoing (mostly unrelated) work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 06:24:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 06:24:52 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.04e803ccdabebc9adf3025e2a790594f@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Just tried compiling with SMP disabled (removing `arm` from `ArchSupportsSMP` in `mk/config.mk.in`) and GHCi fails just like before. This is however proof that this issue is not SMP related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 06:44:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 06:44:48 -0000 Subject: [GHC] #10530: Update transformers library In-Reply-To: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> References: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> Message-ID: <067.f768d546536f1fb90a78fc21db73a260@haskell.org> #10530: Update transformers library -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries | Version: 7.10.2-rc1 (other) | Keywords: Resolution: | transformers Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Right, but as I said before, this release simply added instances - which I think ''is'' a minimal burden (via `MIN_VERSION_transformers` or whatnot). Of course, people are free to disagree. If it was a bugfix release, I'd probably feel differently (indeed, `binary` underwent a bump for 7.10.2 precisely because it had 2 real bugfixes). But here I don't think a bump is really necessary for a minor orphan addition in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 06:47:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 06:47:27 -0000 Subject: [GHC] #10564: GHC 7.10.2 RC cannot build HList-0.4.0.0 In-Reply-To: <047.d3b7b31aab7749db694d46171b616686@haskell.org> References: <047.d3b7b31aab7749db694d46171b616686@haskell.org> Message-ID: <062.5e63ae02c9b6f488d473e8d56efbd9ca@haskell.org> #10564: GHC 7.10.2 RC cannot build HList-0.4.0.0 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 07:34:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 07:34:22 -0000 Subject: [GHC] #10576: REPL returns list of all imported names when operator completion requested In-Reply-To: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> References: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> Message-ID: <062.08d432f554e963c8e54b69a8d38dc40e@haskell.org> #10576: REPL returns list of all imported names when operator completion requested -------------------------------------+------------------------------------- Reporter: Geraldus | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | completions complete command Type of failure: Incorrect result | operator at runtime | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9996 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by Geraldus: Old description: > When querying completions for operators GHCi returns a list containing > all imported names rather than suitable completions. > > For example, if you simply start GHCi and run `:complete repl ">>"` > command it will give you all names from base and Prelude. Then if you > import something else, for example `:m +Data.Text`, the result of query > will contain names from Data.Text also. > > In case of projects (`cabal repl`) things are worst, because returned > list contains all names imported project-wise and it could be really > huge. > > GHCi behaves similarly with following queries: > :complete repl "(>>" > :complete repl "Prelude.>>" > :complete repl "Prelude.(>>" > > I only tested this on OS X 10.9, GHC 7.8.4 New description: When querying completions for operators GHCi returns a list containing all imported names rather than suitable completions. For example, if you simply start GHCi and run `:complete repl ">>"` command it will give you all names from base and Prelude. Then if you import something else, for example `:m +Data.Text`, the result of query will contain names from Data.Text also. In case of projects (`cabal repl`) things are worst, because returned list contains all names imported project-wise and it could be really huge. GHCi behaves similarly with following queries: {{{ :complete repl "(>>" :complete repl "Prelude.>>" :complete repl "Prelude.(>>" }}} I only tested this on OS X 10.9, GHC 7.8.4 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 08:53:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 08:53:17 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.5ca60c1062dbc3c7a72fa5d334d41ece@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): The whittled down test case can be found here, https://github.com/bgamari/ghc-T10527/blob/master/Bug3.hs. It've been testing with, {{{ ghc -fforce-recomp -O Bug3.hs -fsimpl-tick-factor=4 -dshow-passes -dverbose-core2core -ddump-rule-firings -ddump-rules -ddump-rule-rewrites -dsuppress-coercions -ddump-inlinings -ddump-to-file >|ghc.log 2>&1; }}} With both the current state of the `ghc-7.10` branch and `ghc-7.10.1-release`. Note that this test case been reduced to the bare minimum to reproduce on 7.10.2 yet not on 7.10.1. Lowering `simpl-tick- factor` to 3 causes it to fail on both. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 11:48:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 11:48:16 -0000 Subject: [GHC] #10513: ghc 7.6.3 Compiler panic with Generics In-Reply-To: <051.c09e61e0961a632608f776aed9796e7c@haskell.org> References: <051.c09e61e0961a632608f776aed9796e7c@haskell.org> Message-ID: <066.ff8c178b9a15e796cfc52dd399988687@haskell.org> #10513: ghc 7.6.3 Compiler panic with Generics -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by andreas.abel): See also https://code.google.com/p/agda/issues/detail?id=1585 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 12:10:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 12:10:00 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.b2f23c8125ac0e55054ac856b6e212dc@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Changes (by George): * version: 7.10.1 => 7.10.2-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 12:33:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 12:33:39 -0000 Subject: [GHC] #7478: setSessionDynFlags does not always work In-Reply-To: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> References: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> Message-ID: <059.545e8eaaf37cfac73e6ce883374192ef@haskell.org> #7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------- Reporter: edsko | Owner: bherzog Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: ghc- Related Tickets: | api/T7478 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bherzog): * owner: => bherzog -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 13:55:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 13:55:10 -0000 Subject: [GHC] #10530: Update transformers library In-Reply-To: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> References: <052.0c31d10f46f9c718da9cede6af3f558b@haskell.org> Message-ID: <067.88c0f89b21ea383d7de18aa23622cdd4@haskell.org> #10530: Update transformers library -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries | Version: 7.10.2-rc1 (other) | Keywords: Resolution: | transformers Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by asr): I don't want to block the release of GHC 7.10.2 for this ticket, so I won't open thick again if you close it again. An issue was reported in the Agda bug tracker yesterday (see [https://code.google.com/p/agda/issues/detail?id=1590 Issue 1590]). It seems the issue is related to a ''missing instance'' in transformers 0.3.0.0. This is exactly the class of problems I want to avoid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 14:00:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 14:00:24 -0000 Subject: [GHC] #10513: ghc 7.6.3 Compiler panic with Generics In-Reply-To: <051.c09e61e0961a632608f776aed9796e7c@haskell.org> References: <051.c09e61e0961a632608f776aed9796e7c@haskell.org> Message-ID: <066.fbdebb701e3b4dfaf3ad03fc7b8eee63@haskell.org> #10513: ghc 7.6.3 Compiler panic with Generics -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 14:17:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 14:17:20 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.05c300779ff75247ac892e6e48266a8d@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I've put up some of my notes tracing through the inlinings here, https://github.com/bgamari/ghc-T10527/blob/master/trace-inlines.mkd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 14:24:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 14:24:57 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.f0565a894ecf0cfd9ab86316b5f082c9@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Another thing I have noticed is that the good commit considers some inlining contexts to be `RuleArgCtxts` which the bad commits considers `BoringCtxt`. This difference may be due to the good commit's eagerness to inline `$fFoldableIndentity2` and friends. Consider, for instance, this inlinig which occurs in a `RuleArgCtxt` (which directly follows an inlining of `fFoldableIdentity2`), {{{#!hs Considering inlining: $s$crsubset_s2eb arg infos [ValueArg, ValueArg, TrivArg] interesting continuation RuleArgCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [30 60 0] 70 0 discounted size = -105 ANSWER = YES Inlining done: $s$crsubset Inlined fn: \ (@ (g :: * -> *)) ($dFunctor_a211 [Occ=Once] :: GHC.Base.Functor g) (eta_B2 [Occ=Once!] :: Bug.Rec '[] -> g (Bug.Rec '[])) (eta_B1 [Occ=OnceL] :: Bug.Rec '["id" Bug.:-> Bug.Expr GHC.Types.Int, "id" Bug.:-> Bug.Expr GHC.Types.Int, "event_type" Bug.:-> Bug.Expr GHC.Types.Int, "field1" Bug.:-> Bug.Expr GHC.Types.Int]) -> GHC.Base.fmap @ g $dFunctor_a211 @ (Bug.Rec '[]) @ (Bug.Rec '["id" Bug.:-> Bug.Expr GHC.Types.Int, "id" Bug.:-> Bug.Expr GHC.Types.Int, "event_type" Bug.:-> Bug.Expr GHC.Types.Int, "field1" Bug.:-> Bug.Expr GHC.Types.Int]) (\ _ [Occ=Dead] -> eta_B1) (eta_B2 Bug.$WRNil) Cont: ApplyToTy Data.Functor.Identity.Identity ApplyToVal nodup Data.Functor.Identity.$fFunctorIdentity ApplyToVal nodup ((\ _ [Occ=Dead] -> rs `cast` ...) `cast` ...) ApplyToVal nodup eta_B1 CastIt Nth:1 ((forall a4. _R -> Data.Functor.Identity.NTCo:Identity[0] _R)@Bug.Rec '["id" Bug.:-> Bug.Expr GHC.Types.Int, "id" Bug.:-> Bug.Expr GHC.Types.Int, "event_type" Bug.:-> Bug.Expr GHC.Types.Int, "field1" Bug.:-> Bug.Expr GHC.Types.Int]) Stop[RuleArgCtxt] Bug.Rec '["id" Bug.:-> Bug.Expr GHC.Types.Int, "id" Bug.:-> Bug.Expr GHC.Types.Int, "event_type" Bug.:-> Bug.Expr GHC.Types.Int, "field1" Bug.:-> Bug.Expr GHC.Types.Int] }}} Compared to the bad commit, which has not yet inlined `$fFoldableIdentity2` and does the same inlining in roughly the same context (up to some casts), {{{#!hs Considering inlining: $s$crsubset_s2eb arg infos [ValueArg, ValueArg, TrivArg] interesting continuation BoringCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [30 60 0] 70 0 discounted size = -105 ANSWER = YES Inlining done: $s$crsubset Inlined fn: \ (@ (g :: * -> *)) ($dFunctor_a211 [Occ=Once] :: GHC.Base.Functor g) (eta_B2 [Occ=Once!] :: Bug.Rec '[] -> g (Bug.Rec '[])) (eta_B1 [Occ=OnceL] :: Bug.Rec '["id" Bug.:-> Bug.Expr GHC.Types.Int, "id" Bug.:-> Bug.Expr GHC.Types.Int, "event_type" Bug.:-> Bug.Expr GHC.Types.Int, "field1" Bug.:-> Bug.Expr GHC.Types.Int]) -> GHC.Base.fmap @ g $dFunctor_a211 @ (Bug.Rec '[]) @ (Bug.Rec '["id" Bug.:-> Bug.Expr GHC.Types.Int, "id" Bug.:-> Bug.Expr GHC.Types.Int, "event_type" Bug.:-> Bug.Expr GHC.Types.Int, "field1" Bug.:-> Bug.Expr GHC.Types.Int]) (\ _ [Occ=Dead] -> eta_B1) (eta_B2 Bug.$WRNil) Cont: ApplyToTy Data.Functor.Identity.Identity ApplyToVal nodup Data.Functor.Identity.$fFunctorIdentity ApplyToVal nodup ((\ _ [Occ=Dead] -> rs) `cast` ...) ApplyToVal nodup eta_B1 Stop[BoringCtxt] Data.Functor.Identity.Identity (Bug.Rec '["id" Bug.:-> Bug.Expr GHC.Types.Int, "id" Bug.:-> Bug.Expr GHC.Types.Int, "event_type" Bug.:-> Bug.Expr GHC.Types.Int, "field1" Bug.:-> Bug.Expr GHC.Types.Int]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 14:28:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 14:28:01 -0000 Subject: [GHC] #10583: Chaos in Lexeme.hs Message-ID: <047.ca228b2a0d43586fb2828ecd680f46fc@haskell.org> #10583: Chaos in Lexeme.hs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've been looking at the `Lexeme` module (in `basicTypes`), where -- as far as I can tell -- utter chaos reigns. (Full disclosure: I wrote this module some time ago, inheriting its code from various places. But I clearly did a poor job of it.) Here is a sampling of the chaos: * `isLexConSym` claims to recognize type and data constructor infix symbols. But it requires symbols to start with a `:` (or be `->`). This is out-of-date with respect to the change in type constructor infix symbols in 7.6(?), which now do not need to start with a `:`. * `isVarSymChar` and `okSymChar` both purport to recognize characters that are valid parts of symbolic identifiers. But they have entirely different, unrelated implementations. These should be the '''same''' function, I believe. * The `notFollowedBySymbol` function defined in `parser/Lexer.x` overlaps with the functions above. But it has a '''third''' implementation, different than either of these other two. * The `isLexXXX` functions all just look at first characters, except for `isLexVarSym`, which looks at all characters. There is a reason for this -- that GHC-generated names start with a `$` but should be printed prefix -- but I'm not sure I buy it. Is it sufficient to look at the first two characters instead of the first one? I'm happy to make the code changes around this, but I need some advice from someone who has more knowledge about both Haskell's lexical structure and quite possibly Unicode. Happily, the function in `Lexeme` are not used much. But it would be awfully nice if they did the right thing when they are used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 14:32:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 14:32:55 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.557c89ad828b9e7f54bf4bf317ea78b0@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Also interesting is that inlining of `$fFunctorIdentity2` is completely unchanged between the two commits other than IdInfo of a binding in the context. Namely, both have a context entry that look like this, {{{ ApplyToVal simpl ((case xs `cast` ... of _ [Occ=Dead] { Bug.:& @ r @ rs dt_X2fs x xs -> case xs `cast` ... of _ [Occ=Dead] { Bug.:& @ r @ rs dt_d2bT x xs -> case r `cast` ... of nt_s2fs { Bug.Expr ipv ipv -> let { dt_X1PT :: Bug.Rec '["field1" Bug.:-> Bug.Expr GHC.Types.Int] [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] dt_X1PT = Bug.:& @ '["field1" Bug.:-> Bug.Expr GHC.Types.Int] @ ("field1" Bug.:-> Bug.Expr GHC.Types.Int) @ '[] @~ <'["field1" Bug.:-> Bug.Expr GHC.Types.Int]>_N (nt_s2fs `cast` ...) (xs `cast` ...) } in (Bug.:& @ '["event_type" Bug.:-> Bug.Expr GHC.Types.Int, "field1" Bug.:-> Bug.Expr GHC.Types.Int] @ ("event_type" Bug.:-> Bug.Expr GHC.Types.Int) @ '["field1" Bug.:-> Bug.Expr GHC.Types.Int] @~ <'["event_type" Bug.:-> Bug.Expr GHC.Types.Int, "field1" Bug.:-> Bug.Expr GHC.Types.Int]>_N (x `cast` ...) dt_X1PT) `cast` ... } } }) `cast` ...) }}} where the bad commit has the Unfolding and the good commit does not. Smells very suspicious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 14:51:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 14:51:30 -0000 Subject: [GHC] #10582: Tiny bug in lexer around lexing banana brackets In-Reply-To: <047.08a52be5ab9ac23a1408480f99ba99e9@haskell.org> References: <047.08a52be5ab9ac23a1408480f99ba99e9@haskell.org> Message-ID: <062.ef9377b5c556cacd8cbd2c12e027fed0@haskell.org> #10582: Tiny bug in lexer around lexing banana brackets -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"8d221bbd7af9610ded3071df53adecad72b0fc2e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8d221bbd7af9610ded3071df53adecad72b0fc2e" Test #10582 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 14:52:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 14:52:04 -0000 Subject: [GHC] #10582: Tiny bug in lexer around lexing banana brackets In-Reply-To: <047.08a52be5ab9ac23a1408480f99ba99e9@haskell.org> References: <047.08a52be5ab9ac23a1408480f99ba99e9@haskell.org> Message-ID: <062.bb294b3e415f5fdeeec92ee87cb0e5ee@haskell.org> #10582: Tiny bug in lexer around lexing banana brackets -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 10583 | Test Case: Related Tickets: | parser/should_compile/T10582 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => parser/should_compile/T10582 * blockedby: => 10583 Comment: This should be fixed with #10583. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 15:58:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 15:58:27 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.a2819f382157a9998a63549703a6450b@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): The above notes are getting to be a bit of a mess. Here's something of a summary of the current state of things. I have established that the memory leak patch is the source of the regression. Below I will refer to the commit directly before this patch (9b406cc65cdb5db6b294a63301aed52a02bcbaf5) as the working commit and the regression commit (8af219adb914b292d0f8c737fe0a1e3f7fb19cf3) as the failing commit. Looking at verbose-core2core output, it seems there is no difference in the compilation up to the `Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False})` phase. It is apparently during this phase that the simplifier blows up. At this point it's not clear to me whether one or more of these differences are the key to the issue or simply inconsequential fall-out due to the move away from `CoreSubst`. In particular the differences are, * One often sees that terms in the context of inlinings that are marked as `NoDup` in 7.10.1 are marked as `Simplified` in 7.10.2. The new implementation of `simplArg` appears to touch this logic but my tests suggest that this isn't the cause of the difference. * `$fFoldableIdentity2` and `$fGeneric1Const` are both inlined sooner in the working commit than in the failing commit. (comment:16 and comment:7) This results in a rather obvious pattern in the differences between the contexts of the inlinings performed by the two commits. For instance, in the working commit one often sees contexts ending with, {{{ CastIt Nth:1 (((forall a6 b. _R -> Control.Applicative.NTCo:Const[0] _R _P) @ "field1" :-> Expr Int) @ Rec '["field1" :-> .Expr Int, "field2" :-> .Expr Int, "id" :-> .Expr Int, "event_type" :-> .Expr Int] ) Stop[BoringCtxt] "field1" Bug.:-> Bug.Expr GHC.Types.Int }}} whereas the context of the corresponding inlining in the failing commit ends simply with, {{{ Stop[BoringCtxt] Control.Applicative.Const ("field1" :-> Expr Int) (Rec '["field1" :-> Expr Int, "field2" :-> Expr Int, "id" :-> Expr Int, "event_type" :-> Expr Int]) }}} Several inlinings further are performed in this state until eventually `$fFoldableIdentity2` or `$fGeneric1Const` are inlined by the bad commit, which wipes away the difference. * One sees `let` bindings in inlining contexts which have unfoldings in the bad commit and no inlinings in the good commit. (comment:17) * One occasionally sees inlinings being consider in continuations which are considered interesting for different reasons: namely the good commit often considers continuations to be `RuleArgCtxt` while the bad commit considers it to be. `BoringCtxt` * Interesting but unlikely to be the cause: the failing commit considers (and rejects) a few inlinings that the working commit does not. These typically look like, {{{ Considering inlining: g_a2cv arg infos [TrivArg] interesting continuation BoringCtxt some_benefit True is exp: False is work-free: False guidance IF_ARGS [] 50 0 discounted size = 40 ANSWER = NO }}} `g_a2cv` is a let binding defined in several different bindings (namely `$dmrreplace`, `$dmrcast`, and `$dmrput` . It appears always be of the form `Rec ss_a1LQ -> m (Rec ss_a1LQ)` with `m` of either `Const _` or `Identity` depending upon the context. It's interesting that the failing commit considers and rejects inlining this binding in all three cases, whereas the working commit doesn't even consider it. There are a few other bindings (e.g. variants of `lens`) which also exhibit this difference. Anyways, all of this is likely very difficult to grasp without playing around with it. The whittled down test case can be found here, https://github.com/bgamari/ghc-T10527/blob/master/Bug3.hs. I have been testing with, {{{ ghc -fforce-recomp -O Bug3.hs -fsimpl-tick-factor=4 -dshow-passes \ -dverbose-core2core -ddump-rule-firings -ddump-rules -ddump-rule- rewrites \ -dsuppress-coercions -ddump-inlinings -ddump-to-file >|ghc.log 2>&1 }}} With both the good and bad commit. Note that this test case been reduced to the bare minimum to reproduce on the bad commit yet not on the good commit. However, it is very sensitive: lowering `simpl-tick-factor` to 3 causes it to fail on both. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 18:19:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 18:19:27 -0000 Subject: [GHC] #8317: Optimize tagToEnum# at Core level In-Reply-To: <048.d63000c93a1f7da8d9258ca78bbef37a@haskell.org> References: <048.d63000c93a1f7da8d9258ca78bbef37a@haskell.org> Message-ID: <063.a05e9d710965acf78a9a6a05286efd12@haskell.org> #8317: Optimize tagToEnum# at Core level -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 8326 | Test Case: Related Tickets: #6135 | Blocking: | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: jstolarek => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 18:22:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 18:22:21 -0000 Subject: [GHC] #7478: setSessionDynFlags does not always work In-Reply-To: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> References: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> Message-ID: <059.50ed5b3556b75f8a4380a8dc0df5953c@haskell.org> #7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------- Reporter: edsko | Owner: bherzog Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: ghc- Related Tickets: | api/T7478 | Blocking: | Differential Revisions: Phab:D1017 -------------------------------------+------------------------------------- Changes (by bherzog): * differential: => Phab:D1017 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 19:20:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 19:20:23 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.1d15635e421d14381b14e3b458856e53@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): The other issue Rydgel mentions really is #10322, and I can reproduce it on Linux (though the particular offending symbol is different). I don't understand why that otool output doesn't mention the GLUT framework (or why it lists libHSGLUT itself) or why libHSOpenGLRaw apparently works without its otool output mentioning the OpenGL framework. Maybe it would help to see the final link command when building the GLUT package though? (`cabal build -v`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 20:08:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 20:08:18 -0000 Subject: [GHC] #10577: Use empty cases where appropriate when deriving instances for empty types In-Reply-To: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> References: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> Message-ID: <062.5cb17323bde6c82babf1db2345bda143@haskell.org> #10577: Use empty cases where appropriate when deriving instances for empty types -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): One thing to note: We have two ways to derive instances, using `deriving (..)` syntax and StandaloneDeriving. If we want to make changes described here and also keep this two methods of instance deriving consistent with each other(currently they're not), it means breaking change. IMHO, StandaloneDeriving and `deriving (..)` should work the same, so we should either do this breaking change or merge https://phabricator.haskell.org/D978. Also, I'm not sure how relevant it is, but `Data.Void.Void`s methods are currently not forcing the arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 20:15:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 20:15:10 -0000 Subject: [GHC] #10584: Installation of SFML failed Message-ID: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> #10584: Installation of SFML failed -------------------------------------+------------------------------------- Reporter: SoleSoul | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This report is bad because I have no idea what I'm reporting but the compiler asked me to so there you go: % cabal install sfml :( Resolving dependencies... Configuring SFML-0.2.0.0... Building SFML-0.2.0.0... Failed to install SFML-0.2.0.0 Build log ( /home/user/.cabal/logs/SFML-0.2.0.0.log ): Configuring SFML-0.2.0.0... Building SFML-0.2.0.0... Preprocessing library SFML-0.2.0.0... [ 1 of 71] Compiling SFML.Window.WindowHandle ( src/SFML/Window/WindowHandle.hs, dist/build/SFML/Window/WindowHandle.o ) [ 2 of 71] Compiling SFML.SFDisplayable ( src/SFML/SFDisplayable.hs, dist/build/SFML/SFDisplayable.o ) [ 3 of 71] Compiling SFML.SFCopyable ( src/SFML/SFCopyable.hs, dist/build/SFML/SFCopyable.o ) [ 4 of 71] Compiling SFML.System.InputStream ( dist/build/SFML/System/InputStream.hs, dist/build/SFML/System/InputStream.o ) [ 5 of 71] Compiling SFML.SFResource ( src/SFML/SFResource.hs, dist/build/SFML/SFResource.o ) [ 6 of 71] Compiling SFML.Utils ( src/SFML/Utils.hs, dist/build/SFML/Utils.o ) [ 7 of 71] Compiling SFML.Window.VideoMode ( dist/build/SFML/Window/VideoMode.hs, dist/build/SFML/Window/VideoMode.o ) [ 8 of 71] Compiling SFML.Window.Types ( src/SFML/Window/Types.hs, dist/build/SFML/Window/Types.o ) [ 9 of 71] Compiling SFML.Window.Keyboard ( dist/build/SFML/Window/Keyboard.hs, dist/build/SFML/Window/Keyboard.o ) [10 of 71] Compiling SFML.Window.Joystick ( dist/build/SFML/Window/Joystick.hs, dist/build/SFML/Window/Joystick.o ) [11 of 71] Compiling SFML.Window.ContextSettings ( dist/build/SFML/Window/ContextSettings.hs, dist/build/SFML/Window/ContextSettings.o ) [12 of 71] Compiling SFML.Window.Context ( dist/build/SFML/Window/Context.hs, dist/build/SFML/Window/Context.o ) [13 of 71] Compiling SFML.System.Vector3 ( dist/build/SFML/System/Vector3.hs, dist/build/SFML/System/Vector3.o ) [14 of 71] Compiling SFML.System.Vector2 ( dist/build/SFML/System/Vector2.hs, dist/build/SFML/System/Vector2.o ) [15 of 71] Compiling SFML.Window.Mouse ( dist/build/SFML/Window/Mouse.hs, dist/build/SFML/Window/Mouse.o ) [16 of 71] Compiling SFML.Window.Event ( dist/build/SFML/Window/Event.hs, dist/build/SFML/Window/Event.o ) [17 of 71] Compiling SFML.Window.SFWindow ( src/SFML/Window/SFWindow.hs, dist/build/SFML/Window/SFWindow.o ) [18 of 71] Compiling SFML.Window.Window ( dist/build/SFML/Window/Window.hs, dist/build/SFML/Window/Window.o ) [19 of 71] Compiling SFML.System.Time ( dist/build/SFML/System/Time.hs, dist/build/SFML/System/Time.o ) [20 of 71] Compiling SFML.Audio.SFSoundBuffer ( src/SFML/Audio/SFSoundBuffer.hs, dist/build/SFML/Audio/SFSoundBuffer.o ) [21 of 71] Compiling SFML.System.Sleep ( dist/build/SFML/System/Sleep.hs, dist/build/SFML/System/Sleep.o ) [22 of 71] Compiling SFML.System.Clock ( src/SFML/System/Clock.hs, dist/build/SFML/System/Clock.o ) [23 of 71] Compiling SFML.System ( src/SFML/System.hs, dist/build/SFML/System.o ) [24 of 71] Compiling SFML.Window ( src/SFML/Window.hs, dist/build/SFML/Window.o ) [25 of 71] Compiling SFML.Graphics.Types ( src/SFML/Graphics/Types.hs, dist/build/SFML/Graphics/Types.o ) [26 of 71] Compiling SFML.Graphics.SFSmoothTexture ( src/SFML/Graphics/SFSmoothTexture.hs, dist/build/SFML/Graphics/SFSmoothTexture.o ) [27 of 71] Compiling SFML.Graphics.SFShapeResizable ( src/SFML/Graphics/SFShapeResizable.hs, dist/build/SFML/Graphics/SFShapeResizable.o ) [28 of 71] Compiling SFML.Graphics.SFCoordSpace ( src/SFML/Graphics/SFCoordSpace.hs, dist/build/SFML/Graphics/SFCoordSpace.o ) [29 of 71] Compiling SFML.Graphics.SFBindable ( src/SFML/Graphics/SFBindable.hs, dist/build/SFML/Graphics/SFBindable.o ) [30 of 71] Compiling SFML.Graphics.Rect ( dist/build/SFML/Graphics/Rect.hs, dist/build/SFML/Graphics/Rect.o ) [31 of 71] Compiling SFML.Graphics.SFBounded ( src/SFML/Graphics/SFBounded.hs, dist/build/SFML/Graphics/SFBounded.o ) [32 of 71] Compiling SFML.Graphics.SFViewable ( src/SFML/Graphics/SFViewable.hs, dist/build/SFML/Graphics/SFViewable.o ) [33 of 71] Compiling SFML.Graphics.Texture ( src/SFML/Graphics/Texture.hs, dist/build/SFML/Graphics/Texture.o ) [34 of 71] Compiling SFML.Graphics.Transform ( dist/build/SFML/Graphics/Transform.hs, dist/build/SFML/Graphics/Transform.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $j_sJFj To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 190129 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: SFML-0.2.0.0 failed during the building phase. The exception was: ExitFailure 1 cabal install sfml 7.18s user 0.76s system 93% cpu 8.460 total -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 21:04:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 21:04:26 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.ea6a4f647c1bfabd1ca6709a2a3f502a@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by Rydgel): Replying to [comment:15 rwbarton]: > Maybe it would help to see the final link command when building the GLUT package though? (`cabal build -v`) Here we go https://gist.githubusercontent.com/Rydgel/8ad7cb3b50fd98909900/raw/b727b43d00f89d23b425e1458ebc647006c0e2b7/gistfile1.txt -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 21:50:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 21:50:10 -0000 Subject: [GHC] #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts In-Reply-To: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> References: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> Message-ID: <061.616cc9eaff9747e7669b81105cef4367@haskell.org> #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts -------------------------------------+------------------------------------- Reporter: anders_ | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I know `unsafeShiftL` has "unsafe" in the name, but it seems irresponsible to segfault on a negative argument when it would take one additional instruction to test for a negative shift (`shiftLInteger` already checks whether the shift is 0) in a function that is not cheap to begin with and is exposed as a "public" part of the `Data.Bits` API. The `Int` instance of `unsafeShiftL` is sensible because the cost of testing whether the shift is in range could exceed the cost of actually doing the shift. That doesn't apply here to `Integer`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 22:05:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 22:05:50 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.644be4f0f078ae31df419232eb34de7d@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): Thanks. Hmm, there is no `-framework` option at all there, so that's definitely incorrect, no? Maybe Cabal linking against OS X frameworks broke when support for relocatable sandboxes was added? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 22:33:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 22:33:10 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.b9c20069ae5c5067b2b65682590d5b92@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+----------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by rwbarton): We should probably just go ahead with that fix anyways since this breakage is rather severe. Let's keep this ticket open after doing so though, to see whether it causes any issues like #8935 and perhaps take a moment to see if we can find a simpler way to handle this whole situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 23:22:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 23:22:08 -0000 Subject: [GHC] #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts In-Reply-To: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> References: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> Message-ID: <061.d2c791960f05b5d146e45023b5a50655@haskell.org> #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts -------------------------------------+------------------------------------- Reporter: anders_ | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): BTW, I'm curious why the program is segfaulting, rather than reporting an out-of-memory condition like it does if I try to evaluate {{{2 `shiftL` 1000000000000000}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 27 23:25:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Jun 2015 23:25:51 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.bf1ce707cc411c7a21bc72e9c0735928@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): I'm very puzzled. I can see exactly where in the source Cabal is supposed to add `-framework foo` options to the link step of ghc, and yet it's not doing so. Rydgel, what version of Cabal are you using? Would you be able to test with older versions of Cabal and/or GHC to see if they have different behavior (either in terms of being able to load GLUT into ghci, or in terms of the Cabal link command including `-framework GLUT`)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 28 00:00:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Jun 2015 00:00:24 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.9589d738bff918aecc264141ca84159c@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Hmph. Another terrible error message from the linker, too (who said anything about `-shared`?) I think I need to understand the exact behavior of the Debian build system at this point, the more I look into this the more confused I get. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 28 00:34:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Jun 2015 00:34:02 -0000 Subject: [GHC] #10564: GHC 7.10.2 RC cannot build HList-0.4.0.0 In-Reply-To: <047.d3b7b31aab7749db694d46171b616686@haskell.org> References: <047.d3b7b31aab7749db694d46171b616686@haskell.org> Message-ID: <062.42e69c8de6408a6fe1fef2055f9cb0d4@haskell.org> #10564: GHC 7.10.2 RC cannot build HList-0.4.0.0 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 28 01:52:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Jun 2015 01:52:19 -0000 Subject: [GHC] #10585: Implement proper bidirectional type inference Message-ID: <047.d9317282c6b0be672717b58e6191b767@haskell.org> #10585: Implement proper bidirectional type inference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The [http://research.microsoft.com/en-us/um/people/simonpj/papers/higher- rank/putting.pdf Practical Type Inference paper] (JFP '07) lays out a nice, relatively straightforward bidirectional type inference algorithm for GHC. The problem is that there is not great hygiene practiced around transitions between "down" checking and "up" checking, neither in the paper nor in the implementation. Examine Figure 8 of the paper, which presents the bidirectional typing rules. There are several syntactic forms which are fundamentally "up" forms -- forms that cannot gain any benefit from any type information being propagated downwards. Examples include App, Var, and Annot. Other forms propagate the very direction they are operated in, such as Let. And then some forms depend somewhat delicately on direction, such as the Abs rules. I propose changing these rules to be more in the style of Figure 4 from Dunfield & Krishnaswami's ICFP'13 paper [http://arxiv.org/pdf/1306.6032v1 here]. The particular rule I'm interested in is DeclSub, paraphrased here: {{{ G |-up e : s1 s1 <= s2 --------------- G |-down e : s2 }}} (I'm not advocating other aspects of their approach, just the general idea around this rule being the only transition between down and up.) In GHC, mediating between "down" checking and "up" checking is done in an ad-hoc manner, made even more difficult by the fact that it takes two separate steps to pull off properly: we must first `deeplyInstantiate` the "up" type that we get and then call `tcSubType` (or one of its variants). And, because this has to be done for each "up" expression form (forms that cannot use down-propagated type information), it's easy to miss a case. As a case in point, consider the following code: {{{ foo :: forall b. b -> (Int -> Int) -> b foo = undefined bar :: ((forall a. a -> a) -> Int) -> Int bar = undefined baz = bar (foo 3) bum = bar (3 `foo`) }}} In 7.10.1, `baz` is accepted, while `bum` is not. This is because the code for left-sections doesn't ever call `tcSubType` -- it uses `unifyType`. While that one case is easy enough to fix, I advocate a redesign of `tcExpr` to break it into two functions: one for "down" forms and one for "up" forms. These would, of course, be mutually recursive in order so that both can handle all expression forms. But these transitions could then be policed more easily. I don't actually think this would entail all that much work, and it would structurally remove the possibility of bugs such as the one above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 28 01:53:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Jun 2015 01:53:10 -0000 Subject: [GHC] #10585: Implement proper bidirectional type inference In-Reply-To: <047.d9317282c6b0be672717b58e6191b767@haskell.org> References: <047.d9317282c6b0be672717b58e6191b767@haskell.org> Message-ID: <062.4c4ad25a5f97813e5a65ad0eb7db60f7@haskell.org> #10585: Implement proper bidirectional type inference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: If others (particularly, Simon) think this is a good idea, I'm happy to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 28 10:39:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Jun 2015 10:39:00 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.b35d76f7d01dc388d015f9a9cd3f8858@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by Rydgel): This is my current version of cabal {{{ cabal --version cabal-install version 1.22.6.0 using version 1.22.4.0 of the Cabal library }}} This is the full build and the error with GHC 7.10.1 && cabal 1.22.0 https://gist.githubusercontent.com/Rydgel/96ba8626d1e18274502d/raw/0ff07b54915c4283294fa3c7f0e0e308f8ed810b/gistfile1.txt I installed GHC 7.8.4 && cabal 1.22.0 Here is the full build of the lib https://gist.githubusercontent.com/Rydgel/3d2c1b0555338b210df3/raw/4975551dd5699120130b0505be0d84f20c70a780/gistfile1.txt Now I tried with GHC 7.8.4 && cabal 1.20 Here is the full build of the lib: https://gist.githubusercontent.com/Rydgel/bf6dc245b410e90828ff/raw/b28d952a2824ed69abe079a853d739d314298a39/gistfile1.txt So far every configuration failed to load the GLUT project in the cabal repl when building it in a sandbox. ---- Now this is maybe a related problem with the package not configured to use it with way. So I did some new tests with installing the GLUT package outside a sandbox and try load it with ghci -package GLUT (which was the steps reported first in this page). So far after install (I totally nuked ~/.cabal and ~/.ghc for each steps): GHC 7.8.4 - Cabal 1.20 {{{ ghci -package GLUT GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package OpenGLRaw-2.5.1.0 ... linking ... done. Loading package GLURaw-1.5.0.1 ... linking ... done. Loading package ObjectName-1.1.0.0 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package stm-2.4.4 ... linking ... done. Loading package StateVar-1.1.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package text-1.2.1.1 ... linking ... done. Loading package OpenGL-2.12.0.1 ... linking ... done. Loading package GLUT-2.7.0.1 ... linking ... done. Prelude> }}} GHC 7.8.4 && Cabal 1.22.0.0 {{{ ghci -package GLUT GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package OpenGLRaw-2.5.1.0 ... linking ... done. Loading package GLURaw-1.5.0.1 ... linking ... done. Loading package ObjectName-1.1.0.0 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package stm-2.4.4 ... linking ... done. Loading package StateVar-1.1.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package text-1.2.1.1 ... linking ... done. Loading package OpenGL-2.12.0.1 ... linking ... done. Loading package GLUT-2.7.0.1 ... linking ... done. Prelude> }}} [https://gist.githubusercontent.com/Rydgel/64b539dc71935b053b0b/raw/59803bf05a7d361d1d7d768360ea4afcbdd6b7fd/gistfile1.txt GLUT-2.7.0.1.log] GHC 7.10.1 && Cabal 1.22.0.0 {{{ ghci -package GLUT GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help : can't load .so/.DLL for: /Users/rydgel/.cabal/lib/x86_64 -osx-ghc-7.10.1/GLUT_J0mPc7fsMRk1qun4O7kCoA/libHSGLUT-2.7.0.1 -Go4T8lnmeY31g3GsnJ9sQu-ghc7.10.1.dylib (dlopen(/Users/rydgel/.cabal/lib/x86_64-osx- ghc-7.10.1/GLUT_J0mPc7fsMRk1qun4O7kCoA/libHSGLUT-2.7.0.1 -Go4T8lnmeY31g3GsnJ9sQu-ghc7.10.1.dylib, 5): Symbol not found: _glutBitmap8By13 Referenced from: /Users/rydgel/.cabal/lib/x86_64-osx- ghc-7.10.1/GLUT_J0mPc7fsMRk1qun4O7kCoA/libHSGLUT-2.7.0.1 -Go4T8lnmeY31g3GsnJ9sQu-ghc7.10.1.dylib Expected in: flat namespace in /Users/rydgel/.cabal/lib/x86_64-osx- ghc-7.10.1/GLUT_J0mPc7fsMRk1qun4O7kCoA/libHSGLUT-2.7.0.1 -Go4T8lnmeY31g3GsnJ9sQu-ghc7.10.1.dylib) }}} [https://gist.githubusercontent.com/Rydgel/3285488a32e1d6752c20/raw/f194edfe69032d485b3cc8be5064dee488b1845c/gistfile1.txt GLUT-2.7.0.1.log] I provided the complete logs of the installs too. In all cases above otool didn't showed a link to GLUT framework (for the lib itself). So this tool is maybe useless in our case or the link is done elsewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 28 13:08:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Jun 2015 13:08:06 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.8799bc9616390264ba7bc72d812d07bd@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by trommler): I think linking `libHSGLUT...dylib` without framework GLUT ist just plain wrong. `cbits/HsGLUT.c` refers to symbols in the GLUT framework so we must link against framework GLUT. The reason it works with older ghci is that shared libraries were loaded (`dlopen`ed) with global scope (see #8935) and another package might have loaded GLUT before. In conclusion I agree with @rwbarton that we need to fix Cabal so it runs the final link with the appropriate `-framework` options. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 28 13:18:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Jun 2015 13:18:32 -0000 Subject: [GHC] #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts In-Reply-To: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> References: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> Message-ID: <061.53de84b9603611c1ace6c67d37632467@haskell.org> #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts -------------------------------------+------------------------------------- Reporter: anders_ | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:4 rwbarton]: > BTW, I'm curious why the program is segfaulting, rather than reporting an out-of-memory condition like it does if I try to evaluate {{{2 `shiftL` 1000000000000000}}}. Most likely because `integer_gmp_mpn_lshift` gets called with unsound parameters, leading to `memset(3)` overwriting memory it isn't supposed to touch... The low-level api in `integer-gmp` has very little safeguards (for one to avoid having to check the same conditions multiple times, but also because we can't report errors), I've tried to document all pre-conditions on input-arguments which are required to be satisfied to avoid segfaults. To some degree this also a result of having to use `Int#` for quantities which then are converted into a `Word#` rightaway... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 28 15:27:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Jun 2015 15:27:09 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) In-Reply-To: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> References: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> Message-ID: <059.d55b61c0134e2e01e5d33e59e9368909@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I inlined the relevant parts of the parallel package into michaelt's example for the sake of testing across multiple versions of GHC. In the process I discovered that building with `-feager-blackholing` is necessary to reproduce the bug. Well, not surprising. (The parallel package specifies this flag in its cabal file.) To be specific, I am building it as {{{ ghc -threaded -O -rtsopts par -fforce-recomp -feager-blackholing }}} and running as {{{ while ./par 8 +RTS -N4; do :; done }}} until it fails (which is usually immediately). I managed to bisect the failure down to these three commits between 7.6 and 7.8 which added cardinality analysis: https://github.com/ghc/ghc/compare/da4ff650ae77930a5a10d4886c8bc7d37f081db7...62653122f3cf2d48a475cadecc9b4483488c9769 Interestingly in the versions that have cardinality analysis, the program still loops even when built with `-fkill-absence`. Hopefully this provides some clues to someone... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 28 16:31:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Jun 2015 16:31:29 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.d8a7da5709253915149ef3b239f0f663@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"89834d6d99da564aa14e63f2f801f50a615ce322/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="89834d6d99da564aa14e63f2f801f50a615ce322" Add -fcross-module-specialise flag Summary: As of 7.10.1 we specialize INLINEABLE identifiers defined in other modules. This can expose issues (compiler bugs or otherwise) in some cases (e.g. Trac #10491) and therefore we now provide a way for the user to disable this optimization. Test Plan: Successfully compile Splice.hs from Trac #10491. Reviewers: simonpj, austin Reviewed By: simonpj Subscribers: simonpj, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D999 GHC Trac Issues: #10491 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 28 16:31:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Jun 2015 16:31:29 -0000 Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround In-Reply-To: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org> Message-ID: <062.ab1da270a14e055c499696169dbceb4c@haskell.org> #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"302d937782ccb3068244e948d49daff3435e05c0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="302d937782ccb3068244e948d49daff3435e05c0" Add -fcross-module-specialise flag Summary: As of 7.10.1 we specialize INLINEABLE identifiers defined in other modules. This can expose issues (compiler bugs or otherwise) in some cases (e.g. Trac #10491) and therefore we now provide a way for the user to disable this optimization. Test Plan: Successfully compile Splice.hs from Trac #10491. Reviewers: simonpj, austin Reviewed By: simonpj Subscribers: simonpj, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D999 GHC Trac Issues: #10491 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 06:54:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 06:54:29 -0000 Subject: [GHC] #9665: Add "since" information to LANGUAGE extensions in GHC user guide In-Reply-To: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> References: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> Message-ID: <066.fbcdc154268e999d892c1457b4dfa9e2@haskell.org> #9665: Add "since" information to LANGUAGE extensions in GHC user guide -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: rasen Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rasen): * owner: => rasen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 07:36:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 07:36:08 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) In-Reply-To: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> References: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> Message-ID: <059.fd0b8e617a4d8693df04bf2d0206b94b@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): That's extremely helpful, thank you Reid. I'm guessing that the culprit, somehow, is this code in `CoreToStg`: {{{ upd_flag | isSingleUsed (idDemandInfo bndr) = SingleEntry | otherwise = Updatable }}} This arranges not to black-hole a thunk that is used at most once. Can you try with `-fkill-one-shot`? That switches off this optimisation, and I bet it'll make the program work. Assuming that does fix it, the next question is: is it just the `CoreToStg` `upd_flag`? (`-fkill-one-shot` affects more things than just that one spot.) The next thing I'd do would be just to comment out the `SingleEntry` case above, rebuild the compiler, and check that the bug is gone. I'm 95% sure that it'll will, but worth checking. Next. If some thunk is being marked `SingleEntry`, and that that is causing the bug: * Which thunk is it? * Is it really single-entry? (I.e. is the analysis right or not) If you `-ddump-stg` and look for thunks marked `\s`, those are the single- entry ones. There probably aren't very many. If it's very few, we could look at the "is the analysis right?" question. If it's many, we'll need to find a way to narrow it down somehow. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 07:47:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 07:47:55 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) In-Reply-To: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> References: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> Message-ID: <059.444eeb2207087c3b9714304db5b7e614@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): BTW is is the overloading of `Traversable` important. Eliminate it from the single-module reproducer? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 08:07:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 08:07:30 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) In-Reply-To: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> References: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> Message-ID: <059.cd76a6433dc6805d7ba184f4b76a7d04@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): Lazy blackholing will still take place for thunks that are not blackholed by eager blackholing, because we have no way to distinguish between an eager-blackholed and a lazy-blackholed thunk in the runtime. We had bugs in this area in the past, see #5226. I'm not sure this helps, but it's possible that the cardinality analysis is correct and this is a runtime bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 08:15:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 08:15:17 -0000 Subject: [GHC] #10585: Implement proper bidirectional type inference In-Reply-To: <047.d9317282c6b0be672717b58e6191b767@haskell.org> References: <047.d9317282c6b0be672717b58e6191b767@haskell.org> Message-ID: <062.a126ce1b8da7bba5bd02361a763148f2@haskell.org> #10585: Implement proper bidirectional type inference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): 1. Even if we had two `tcExpr` functions (one for "up" and one for "down") why would that structurally remove the possibility of bugs? Presumably each expression form occurs in one but not the other, and you could get that wrong, just as now. In the current code, that's like missing out a subsumption check, which is a bug to be sure. 2. I think that GHC does a mixture of up and down in one blow. Consider {{{ tcExpr ((\y x. (x True, x 'x')) 3) (forall a. a->a) -> (Bool, Char)) }}} This is an APP; so we must infer the argument type of the function; but know the result type of the function, and THAT can be useful, as here. So recursively calling {{{ tcExpr (\y x. (x True, x 'x')) (alpha -> (forall a. a->a) -> (Bool, Char))) }}} is good. Here `alpha` is the `ReturnTv` that is filled in by inference. Admittedly none of this is described in the paper! 3. Lastly we need to revisit all this when we talk about [https://ghc.haskell.org/trac/ghc/wiki/ImpredicativePolymorphism/Impredicative-2015 impredicativity]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 08:17:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 08:17:05 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.e5810970219760facbbb61e62be4dc7b@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by malcolmw): I don't see any missing VC runtime. But running the .exe outside the Cygwin shell was a good idea. I then see a popup console which contains the expected (partial) output "Called foo() with bar=0", but then throws a popup error dialogue telling me ""TestExceptions.exe has stopped working" with the following extra info: {{{ Problem signature: Problem Event Name: APPCRASH Application Name: TestExceptions.exe Application Version: 0.0.0.0 Application Timestamp: 5587dbd2 Fault Module Name: KERNELBASE.dll Fault Module Version: 6.1.7601.23002 Fault Module Timestamp: 5507b1dc Exception Code: e06d7363 Exception Offset: 0000c44d OS Version: 6.1.7601.2.1.0.274.10 Locale ID: 2057 Additional Information 1: 0271 Additional Information 2: 02712a14bbb8bb18ca2af857dbc5b852 Additional Information 3: d1b4 Additional Information 4: d1b4e576b897fdc9bfef974c5ac3140c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 08:20:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 08:20:46 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.2b6d331d97e5174fdc5d963ab6c71c04@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) Comment: I don't have any expectations on the effect of -f / -O ordering. Would be nice to have an option to dump final option effect on GHC as gcc does it with: {{{ gcc --help=optimizers -Q }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 08:31:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 08:31:05 -0000 Subject: [GHC] #10583: Chaos in Lexeme.hs In-Reply-To: <047.ca228b2a0d43586fb2828ecd680f46fc@haskell.org> References: <047.ca228b2a0d43586fb2828ecd680f46fc@haskell.org> Message-ID: <062.b43c6aa69db86ad1b03d37b9ce5864c9@haskell.org> #10583: Chaos in Lexeme.hs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: 10582 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Cleaning this up looks like a great service, thank you. I don't have an opinions of my own; it's not an area I've been working in. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 08:39:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 08:39:59 -0000 Subject: [GHC] #10547: feature request: expanding type synonyms in error messages In-Reply-To: <043.c20ed6dece31f72a0d7c2a22033dd48e@haskell.org> References: <043.c20ed6dece31f72a0d7c2a22033dd48e@haskell.org> Message-ID: <058.df3854775897c80e31d21107b3ce8b08@haskell.org> #10547: feature request: expanding type synonyms in error messages -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D1016 -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for doing this, but I think we can do better without too much difficulty. The trouble here is that * You will often display types that are identical to the ones originally reported {{{ Couldn't match type ?Int? with ?Bool? Expected type: Int Actual type: Bool Type synonyms expanded: Expected type: Int Actual type: Bool }}} That would not be helpful! * You will expand synonyms that make it more, not less obscure: {{{ Couldn't match type ?Int? with ?Bool? Expected type: T Int Actual type: T Bool Type synonyms expanded: Expected type: big -> blab -> wibble -> Int -> wottle Actual type: big -> blab -> wibble -> Bool -> wottle }}} So, what you really want to do is to walk down the two types together, expanding synonyms in the one to make it match the other, and vice versa, until you get to the actual error. A function like {{{ expandSynonymsToMatch :: Type -> Type -> (Type, Type) }}} I suppose you could return a `Maybe` to say if any expansion at all happened; or you can do a type-equality test afterwards which is perhaps easier. Make sense? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 08:40:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 08:40:52 -0000 Subject: [GHC] #10584: Installation of SFML failed In-Reply-To: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> References: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> Message-ID: <062.63cf5c54d2d4111fb84192b6c6d4c537@haskell.org> #10584: Installation of SFML failed -------------------------------------+------------------------------------- Reporter: SoleSoul | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Thanks. What happens if you increase the limit? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 08:48:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 08:48:07 -0000 Subject: [GHC] #10586: GHC 7.10.1 panic due to wildcard in data family instance Message-ID: <051.1ad24f379aa873ec60f60cfdaf86ad2c@haskell.org> #10586: GHC 7.10.1 panic due to wildcard in data family instance -------------------------------------+------------------------------------- Reporter: | Owner: WrenThornton | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following simple program causes GHC 7.10.1 (for x86_64-apple-darwin) to panic (rnHsTyKi HsWildcardTy): {{{#!hs {-# LANGUAGE TypeFamilies, GADTs, DataKinds, PolyKinds #-} data MyKind = A | B data family Sing (a :: k) data instance Sing (_ :: MyKind) where SingA :: Sing A SingB :: Sing B }}} Because data family instances must be fully saturated, we must give some name to the parameter; but because our instance is a GADT, the name of that parameter is meaningless, so using the wildcard makes complete sense here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 08:50:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 08:50:38 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.91349ca0a160f417e2a1e1ac092f9a59@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10561 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): OK, so I fixed comment:7. But the original bug report remains {{{ newtype Compose f g a = Compose (f (g a)) deriving Functor }}} should be fine, but elicits {{{ T10524.hs:5:52: error: Couldn't match kind ?k? with ?*? arising from the first field of ?Compose? (type ?f (g a)?) When deriving the instance for (Functor (Compose f g)) }}} After all, this explicit instance declaration typechecks fine {{{ instance (Functor f, Functor g) => Functor (Compose f g) where fmap fn (Compose x) = Compose (fmap (fmap fn) x) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 08:56:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 08:56:10 -0000 Subject: [GHC] #10482: Not enough unboxing happens on data-family function argument In-Reply-To: <043.b6b30783c65ab27e97e75d03aac8ab21@haskell.org> References: <043.b6b30783c65ab27e97e75d03aac8ab21@haskell.org> Message-ID: <058.0a3fee38fd636e76ff4e2767804fad74@haskell.org> #10482: Not enough unboxing happens on data-family function argument -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The patch in comment:2 fixes the original bug report but gives perf failures on {{{ > haddock.Cabal > haddock.compiler }}} Joachim says: I can confirm this, if you look at https://perf.haskell.org/ghc/ you see that that commit is the only in red Here is the report for that commit: https://perf.haskell.org/ghc/#revision/0b7e538a09bc958474ec704063eaa08836e9270e and you can fetch the numbers from there, or from the full build log at https://raw.githubusercontent.com/nomeata/ghc-speed- logs/master/0b7e538a09bc958474ec704063eaa08836e9270e.log It looks very reproducible as well: https://perf.haskell.org/ghc/#graph/tests/alloc/haddock.Cabal;hl=0b7e538a09bc958474ec704063eaa08836e9270e So we have to discover why this is happening. Sigh. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 09:28:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 09:28:40 -0000 Subject: [GHC] #10017: signal handlers are invoked multiple times when the threaded rts is used In-Reply-To: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> References: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> Message-ID: <060.04bf6f7e136a2be6e8c8c8a01941a1cb@haskell.org> #10017: signal handlers are invoked multiple times when the threaded rts is used -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: bug | AndreasVoellmy Priority: highest | Status: closed Component: Runtime System | Milestone: 7.10.1 Resolution: fixed | Version: 7.10.1-rc1 Operating System: Linux | Keywords: Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9423 | Blocking: | Differential Revisions: Phab:D641 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"bb0e462b6cff02737d67f496d8172207042c22b5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bb0e462b6cff02737d67f496d8172207042c22b5" Mask to avoid uncaught ^C exceptions Summary: It was possible to kill GHCi with a carefully-timed ^C Test Plan: The bug in #10017 exposed this Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1015 GHC Trac Issues: #10017 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 11:20:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 11:20:02 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.042bebad02c755b3701f65cd8cbc41d8@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): Replying to [comment:18 slyfox]: > I don't have any expectations on the effect of -f / -O ordering. > Would be nice to have an option to dump final option effect on > GHC as gcc does it with: > {{{ > gcc --help=optimizers -Q > }}} I agree that it would be nice to see "what you said" on the command line, maybe the -v option could give that output? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 11:46:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 11:46:05 -0000 Subject: [GHC] #9665: Add "since" information to LANGUAGE extensions in GHC user guide In-Reply-To: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> References: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> Message-ID: <066.735f0f457c3cff0bb5e00044a6af16cc@haskell.org> #9665: Add "since" information to LANGUAGE extensions in GHC user guide -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: rasen Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Thanks, @rasen, for taking this on! It might also be helpful in your work to note major changes made to extensions, such as the fact that 7.8's `TypeFamilies` includes closed type families, while previously the extension worked only for open ones. (There was actually some debate at the time about whether we should create a new extension.) Tracking these changes may be challenging, though -- don't let this request hold you up from getting a baseline "since x.x.x" working. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 11:54:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 11:54:46 -0000 Subject: [GHC] #9665: Add "since" information to LANGUAGE extensions in GHC user guide In-Reply-To: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> References: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> Message-ID: <066.8714cecd62af467bdea1282418a54d22@haskell.org> #9665: Add "since" information to LANGUAGE extensions in GHC user guide -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: rasen Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rasen): For now, I'm more worried about changes that were not documented on time. For example, I know `TupleSections` and `PatternSynonyms` work on 7.8.4 but were first documented in 7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 12:05:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 12:05:53 -0000 Subject: [GHC] #10585: Implement proper bidirectional type inference In-Reply-To: <047.d9317282c6b0be672717b58e6191b767@haskell.org> References: <047.d9317282c6b0be672717b58e6191b767@haskell.org> Message-ID: <062.35c4679f64d430ad8fdae0293f626d3c@haskell.org> #10585: Implement proper bidirectional type inference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:2 simonpj]: > 1. Even if we had two `tcExpr` functions (one for "up" and one for "down") why would that structurally remove the possibility of bugs? Presumably each expression form occurs in one but not the other, and you could get that wrong, just as now. In the current code, that's like missing out a subsumption check, which is a bug to be sure. Good point. Right now, the "up" rules should end in a `tcWrapResult`, and contain a `deeplyInstantiate` if there's a possibility the inference will yield a polytype. My proposed refactoring would mean these checks would happen in one place, instead of scattered throughout the rules. But it would still be very easy for a syntactic form to be mentioned in the wrong `tcExpr`, or perhaps in both. So my claim to eliminating problems structurally is overstated. > > 2. I think that GHC does a mixture of up and down in one blow. Consider > {{{ > tcExpr ((\y x. (x True, x 'x')) 3) > (forall a. a->a) -> (Bool, Char)) > }}} > This is an APP; so we must infer the argument type of the function; but know the result type of the function, and THAT can be useful, as here. So recursively calling > {{{ > tcExpr (\y x. (x True, x 'x')) > (alpha -> (forall a. a->a) -> (Bool, Char))) > }}} > is good. Here `alpha` is the `ReturnTv` that is filled in by inference. > > Admittedly none of this is described in the paper! Great example! Except that GHC doesn't do what you want: this fails in 7.10.1, and this is no surprise, looking at the code. `tcApp` calls `tcInferFun`, which doesn't propagate any "down" type information. It looks like you can profitably propagate information in your example, but I think writing inference rules for this propagation would require including unification variables in the rules. This would mean that the implementation would diverge even more from any specification you could write. > > 3. Lastly we need to revisit all this when we talk about [https://ghc.haskell.org/trac/ghc/wiki/ImpredicativePolymorphism/Impredicative-2015 impredicativity]. Indeed. I'm still in favor of this refactoring (though I don't have any understanding of how issue (3) affects us, and so could change my mind with more information there). If we decide to accommodate (2), we could easily do so by having the "App" rule in both `tcExpr`s. If we do this, we should make sure that sections are treated like applications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 12:10:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 12:10:07 -0000 Subject: [GHC] #9665: Add "since" information to LANGUAGE extensions in GHC user guide In-Reply-To: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> References: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> Message-ID: <066.eb92748808eb000af3e5b397855bc715@haskell.org> #9665: Add "since" information to LANGUAGE extensions in GHC user guide -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: rasen Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1019 -------------------------------------+------------------------------------- Changes (by rasen): * differential: => Phab:D1019 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 12:13:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 12:13:24 -0000 Subject: [GHC] #10586: GHC 7.10.1 panic due to wildcard in data family instance In-Reply-To: <051.1ad24f379aa873ec60f60cfdaf86ad2c@haskell.org> References: <051.1ad24f379aa873ec60f60cfdaf86ad2c@haskell.org> Message-ID: <066.3af2fb46edfb7c13f8324aaa20023db0@haskell.org> #10586: GHC 7.10.1 panic due to wildcard in data family instance -------------------------------------+------------------------------------- Reporter: WrenThornton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #3699 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #3699 Comment: Allowing underscores there would be nice. See ticket #3699. But we surely shouldn't panic here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 13:17:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 13:17:02 -0000 Subject: [GHC] #10547: feature request: expanding type synonyms in error messages In-Reply-To: <043.c20ed6dece31f72a0d7c2a22033dd48e@haskell.org> References: <043.c20ed6dece31f72a0d7c2a22033dd48e@haskell.org> Message-ID: <058.6c105cb4712e345dd90626418da5d80a@haskell.org> #10547: feature request: expanding type synonyms in error messages -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D1016 -------------------------------------+------------------------------------- Comment (by osa1): So let's say I have these synonyms: {{{ T5 = T4 T4 = T3 ... T0 = Int }}} and these types: {{{ (T5, T3, X) and (T3, T5, Y) }}} ideally I want to report as "Expected (T3, T3, X) Found (T3, T3, Y)", did I get this right? So it's not just walking down two types together, because that would give us `(Int, Int, X)` and `(Int, Int, Y)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 13:48:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 13:48:53 -0000 Subject: [GHC] #10587: Suspending and unsuspending ghci kills and spawns threads Message-ID: <046.86d123f20d63f11aba21b5ddb030dffb@haskell.org> #10587: Suspending and unsuspending ghci kills and spawns threads -----------------------------------------+--------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- When you run: {{{ ghci -j8 # in a different terminal: pidstat -t -p $(pidof ghc) | grep ghc_worker kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc) # SIGCONT doesn't really resume it, you have to run fg in the terminal where it runs pidstat -t -p $(pidof ghc) | grep ghc_worker kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc) pidstat -t -p $(pidof ghc) | grep ghc_worker kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc) pidstat -t -p $(pidof ghc) | grep ghc_worker }}} You get: {{{ $ pidstat -t -p $(pidof ghc) | grep ghc_worker 06:40:55 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:40:55 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:40:55 AM - 2848955 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:40:55 AM - 2848957 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:40:55 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:40:55 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker 06:40:55 AM - 2848960 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:40:55 AM - 2848961 0.00 0.00 0.00 0.00 2 |__ghc_worker 06:40:55 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker 06:40:55 AM - 2848963 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:40:55 AM - 2848964 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:40:55 AM - 2848965 0.00 0.00 0.00 0.00 11 |__ghc_worker 06:40:55 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker 06:40:55 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker 06:40:55 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker 06:40:55 AM - 2848969 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:40:55 AM - 2848970 0.00 0.00 0.00 0.00 31 |__ghc_worker }}} {{{ $ pidstat -t -p $(pidof ghc) | grep ghc_worker 06:41:37 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:41:37 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:41:37 AM - 2848955 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:41:37 AM - 2848957 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:41:37 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:41:37 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker 06:41:37 AM - 2848960 0.00 0.00 0.00 0.00 5 |__ghc_worker 06:41:37 AM - 2848961 0.00 0.00 0.00 0.00 5 |__ghc_worker 06:41:37 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker 06:41:37 AM - 2848963 0.00 0.00 0.00 0.00 7 |__ghc_worker 06:41:37 AM - 2848964 0.00 0.00 0.00 0.00 12 |__ghc_worker 06:41:37 AM - 2848965 0.00 0.00 0.00 0.00 11 |__ghc_worker 06:41:37 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker 06:41:37 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker 06:41:37 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker 06:41:37 AM - 2848969 0.00 0.00 0.00 0.00 8 |__ghc_worker 06:41:37 AM - 2848970 0.00 0.00 0.00 0.00 14 |__ghc_worker 06:41:37 AM - 2850193 0.00 0.00 0.00 0.00 32 |__ghc_worker 06:41:37 AM - 2850194 0.00 0.00 0.00 0.00 33 |__ghc_worker 06:41:37 AM - 2850196 0.00 0.00 0.00 0.00 34 |__ghc_worker 06:41:37 AM - 2850197 0.00 0.00 0.00 0.00 35 |__ghc_worker 06:41:37 AM - 2850198 0.00 0.00 0.00 0.00 10 |__ghc_worker 06:41:37 AM - 2850199 0.00 0.00 0.00 0.00 17 |__ghc_worker 06:41:37 AM - 2850294 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:41:37 AM - 2850295 0.00 0.00 0.00 0.00 31 |__ghc_worker }}} {{{ $ pidstat -t -p $(pidof ghc) | grep ghc_worker 06:42:43 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:42:43 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:42:43 AM - 2848955 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:42:43 AM - 2848957 0.00 0.00 0.00 0.00 7 |__ghc_worker 06:42:43 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:42:43 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker 06:42:43 AM - 2848960 0.00 0.00 0.00 0.00 9 |__ghc_worker 06:42:43 AM - 2848961 0.00 0.00 0.00 0.00 0 |__ghc_worker 06:42:43 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker 06:42:43 AM - 2848963 0.00 0.00 0.00 0.00 4 |__ghc_worker 06:42:43 AM - 2848964 0.00 0.00 0.00 0.00 12 |__ghc_worker 06:42:43 AM - 2848965 0.00 0.00 0.00 0.00 11 |__ghc_worker 06:42:43 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker 06:42:43 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker 06:42:43 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker 06:42:43 AM - 2848969 0.00 0.00 0.00 0.00 29 |__ghc_worker 06:42:43 AM - 2848970 0.00 0.00 0.00 0.00 14 |__ghc_worker 06:42:43 AM - 2850193 0.00 0.00 0.00 0.00 32 |__ghc_worker 06:42:43 AM - 2850196 0.00 0.00 0.00 0.00 34 |__ghc_worker 06:42:43 AM - 2850197 0.00 0.00 0.00 0.00 35 |__ghc_worker 06:42:43 AM - 2850198 0.00 0.00 0.00 0.00 10 |__ghc_worker 06:42:43 AM - 2850199 0.00 0.00 0.00 0.00 19 |__ghc_worker 06:42:43 AM - 2850295 0.00 0.00 0.00 0.00 13 |__ghc_worker 06:42:43 AM - 2861009 0.00 0.00 0.00 0.00 34 |__ghc_worker 06:42:43 AM - 2861010 0.00 0.00 0.00 0.00 35 |__ghc_worker }}} {{{ $ pidstat -t -p $(pidof ghc) | grep ghc_worker 06:43:37 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:43:37 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:43:37 AM - 2848955 0.00 0.00 0.00 0.00 9 |__ghc_worker 06:43:37 AM - 2848957 0.00 0.00 0.00 0.00 9 |__ghc_worker 06:43:37 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:43:37 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker 06:43:37 AM - 2848960 0.00 0.00 0.00 0.00 29 |__ghc_worker 06:43:37 AM - 2848961 0.00 0.00 0.00 0.00 20 |__ghc_worker 06:43:37 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker 06:43:37 AM - 2848963 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:43:37 AM - 2848964 0.00 0.00 0.00 0.00 12 |__ghc_worker 06:43:37 AM - 2848965 0.00 0.00 0.00 0.00 15 |__ghc_worker 06:43:37 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker 06:43:37 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker 06:43:37 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker 06:43:37 AM - 2848969 0.00 0.00 0.00 0.00 1 |__ghc_worker 06:43:37 AM - 2848970 0.00 0.00 0.00 0.00 19 |__ghc_worker 06:43:37 AM - 2850193 0.00 0.00 0.00 0.00 32 |__ghc_worker 06:43:37 AM - 2850196 0.00 0.00 0.00 0.00 34 |__ghc_worker 06:43:37 AM - 2850197 0.00 0.00 0.00 0.00 35 |__ghc_worker 06:43:37 AM - 2850198 0.00 0.00 0.00 0.00 30 |__ghc_worker 06:43:37 AM - 2861009 0.00 0.00 0.00 0.00 17 |__ghc_worker 06:43:37 AM - 2861010 0.00 0.00 0.00 0.00 19 |__ghc_worker 06:43:37 AM - 2862954 0.00 0.00 0.00 0.00 2 |__ghc_worker 06:43:37 AM - 2862956 0.00 0.00 0.00 0.00 26 |__ghc_worker }}} The sets of threads are changing on every suspend, unsuspend combination. This is really visible when running in gdb with -j40, gdb just spews threads getting spawned and killed: {{{ [Thread 0x7f0b767fc700 (LWP 2881933) exited] [New Thread 0x7f0b767fc700 (LWP 2881940)] [New Thread 0x7f0cc2cfd700 (LWP 2881941)] [Thread 0x7f0b76ffd700 (LWP 2881928) exited] [New Thread 0x7f0b7dffb700 (LWP 2881942)] [New Thread 0x7f0b76ffd700 (LWP 2881943)] [New Thread 0x7f0b7ffff700 (LWP 2881944)] [Thread 0x7f0b777fe700 (LWP 2881932) exited] [Thread 0x7f0b77fff700 (LWP 2881931) exited] [Thread 0x7f0b7d7fa700 (LWP 2881927) exited] [Thread 0x7f0b7f7fe700 (LWP 2881926) exited] [New Thread 0x7f0b7f7fe700 (LWP 2881945)] [New Thread 0x7f0b7d7fa700 (LWP 2881948)] [Thread 0x7f0cc2cfd700 (LWP 2881941) exited] [Thread 0x7f0b75ffb700 (LWP 2881938) exited] [New Thread 0x7f0cc2cfd700 (LWP 2881949)] [Thread 0x7f0b767fc700 (LWP 2881940) exited] [New Thread 0x7f0b767fc700 (LWP 2881950)] [New Thread 0x7f0b75ffb700 (LWP 2881951)] [New Thread 0x7f0b77fff700 (LWP 2881952)] [Thread 0x7f0b757fa700 (LWP 2881939) exited] [Thread 0x7f0b7d7fa700 (LWP 2881948) exited] [New Thread 0x7f0b757fa700 (LWP 2881953)] [Thread 0x7f0b7effd700 (LWP 2881936) exited] [Thread 0x7f0cc3cff700 (LWP 2881937) exited] [New Thread 0x7f0cc3cff700 (LWP 2881954)] [New Thread 0x7f0b7effd700 (LWP 2881955)] [New Thread 0x7f0b7d7fa700 (LWP 2881956)] [Thread 0x7f0b7dffb700 (LWP 2881942) exited] [New Thread 0x7f0b777fe700 (LWP 2881957)] [New Thread 0x7f0b7dffb700 (LWP 2881958)] [Thread 0x7f0b76ffd700 (LWP 2881943) exited] [New Thread 0x7f0b76ffd700 (LWP 2881959)] [Thread 0x7f0b7e7fc700 (LWP 2881935) exited] [Thread 0x7f0b7effd700 (LWP 2881955) exited] [New Thread 0x7f0b7effd700 (LWP 2881962)] [New Thread 0x7f0b7e7fc700 (LWP 2881963)] [Thread 0x7f0b7f7fe700 (LWP 2881945) exited] [New Thread 0x7f0b7f7fe700 (LWP 2881964)] [New Thread 0x7f0b7cff9700 (LWP 2881965)] [Thread 0x7f0b75ffb700 (LWP 2881951) exited] [Thread 0x7f0b7dffb700 (LWP 2881958) exited] [Thread 0x7f0cc3cff700 (LWP 2881954) exited] [New Thread 0x7f0cc3cff700 (LWP 2881967)] [New Thread 0x7f0b7dffb700 (LWP 2881968)] [Thread 0x7f0b777fe700 (LWP 2881957) exited] [Thread 0x7f0b757fa700 (LWP 2881953) exited] [Thread 0x7f0cc2cfd700 (LWP 2881949) exited] [Thread 0x7f0b7ffff700 (LWP 2881944) exited] [New Thread 0x7f0cc2cfd700 (LWP 2881969)] [Thread 0x7f0b7e7fc700 (LWP 2881963) exited] [Thread 0x7f0b767fc700 (LWP 2881950) exited] [New Thread 0x7f0b767fc700 (LWP 2881970)] [New Thread 0x7f0b7e7fc700 (LWP 2881971)] [Thread 0x7f0b77fff700 (LWP 2881952) exited] [New Thread 0x7f0b7ffff700 (LWP 2881972)] [New Thread 0x7f0b77fff700 (LWP 2881973)] [New Thread 0x7f0b757fa700 (LWP 2881974)] [Thread 0x7f0b7dffb700 (LWP 2881968) exited] [New Thread 0x7f0b7dffb700 (LWP 2881975)] [Thread 0x7f0cc2cfd700 (LWP 2881969) exited] [New Thread 0x7f0cc2cfd700 (LWP 2881976)] [Thread 0x7f0b76ffd700 (LWP 2881959) exited] [Thread 0x7f0b757fa700 (LWP 2881974) exited] [New Thread 0x7f0b76ffd700 (LWP 2881977)] [New Thread 0x7f0b757fa700 (LWP 2881978)] [New Thread 0x7f0b777fe700 (LWP 2881979)] [Thread 0x7f0b7effd700 (LWP 2881962) exited] [New Thread 0x7f0b7effd700 (LWP 2881980)] [Thread 0x7f0b7ffff700 (LWP 2881972) exited] [Thread 0x7f0b7e7fc700 (LWP 2881971) exited] [Thread 0x7f0b77fff700 (LWP 2881973) exited] [New Thread 0x7f0b77fff700 (LWP 2881981)] [Thread 0x7f0b7d7fa700 (LWP 2881956) exited] [New Thread 0x7f0b7d7fa700 (LWP 2881982)] [New Thread 0x7f0b7e7fc700 (LWP 2881983)] [Thread 0x7f0cc2cfd700 (LWP 2881976) exited] [New Thread 0x7f0cc2cfd700 (LWP 2881984)] [New Thread 0x7f0b7ffff700 (LWP 2881985)] [New Thread 0x7f0b75ffb700 (LWP 2881986)] [Thread 0x7f0b7dffb700 (LWP 2881975) exited] [New Thread 0x7f0b7dffb700 (LWP 2881987)] [New Thread 0x7f0b74ff9700 (LWP 2881988)] [Thread 0x7f0b777fe700 (LWP 2881979) exited] [Thread 0x7f0b7effd700 (LWP 2881980) exited] [Thread 0x7f0b76ffd700 (LWP 2881977) exited] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 14:11:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 14:11:40 -0000 Subject: [GHC] #10482: Not enough unboxing happens on data-family function argument In-Reply-To: <043.b6b30783c65ab27e97e75d03aac8ab21@haskell.org> References: <043.b6b30783c65ab27e97e75d03aac8ab21@haskell.org> Message-ID: <058.ce5c725311b07ba5913f3bd584524e19@haskell.org> #10482: Not enough unboxing happens on data-family function argument -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"9b5df2a401ba8f033cbbc80331f16ac8cf827c92/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9b5df2a401ba8f033cbbc80331f16ac8cf827c92" Update performance numbers due to #10482 The fix in 0b7e538a has regressed these benchmarks. I have recentered them rather than marking them as broken(10482), because nobody systematically watches the broken test cases, and we want to catch future regressions (or improvements!). #10482 is currently still open, presumably because this needs investigating. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 14:33:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 14:33:05 -0000 Subject: [GHC] #10587: Suspending and unsuspending ghci kills and spawns threads In-Reply-To: <046.86d123f20d63f11aba21b5ddb030dffb@haskell.org> References: <046.86d123f20d63f11aba21b5ddb030dffb@haskell.org> Message-ID: <061.ca7f66e0d93d04f18bc858e4426cd949@haskell.org> #10587: Suspending and unsuspending ghci kills and spawns threads ---------------------------------+----------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Description changed by niteria: Old description: > When you run: > > {{{ > ghci -j8 > > # in a different terminal: > pidstat -t -p $(pidof ghc) | grep ghc_worker > kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc) > # SIGCONT doesn't really resume it, you have to run fg in the terminal > where it runs > pidstat -t -p $(pidof ghc) | grep ghc_worker > kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc) > pidstat -t -p $(pidof ghc) | grep ghc_worker > kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc) > pidstat -t -p $(pidof ghc) | grep ghc_worker > }}} > > You get: > > {{{ > $ pidstat -t -p $(pidof ghc) | grep ghc_worker > 06:40:55 AM - 2848953 0.00 0.00 0.00 0.00 21 > |__ghc_worker > 06:40:55 AM - 2848954 0.00 0.00 0.00 0.00 31 > |__ghc_worker > 06:40:55 AM - 2848955 0.00 0.00 0.00 0.00 21 > |__ghc_worker > 06:40:55 AM - 2848957 0.00 0.00 0.00 0.00 21 > |__ghc_worker > 06:40:55 AM - 2848958 0.00 0.00 0.00 0.00 22 > |__ghc_worker > 06:40:55 AM - 2848959 0.00 0.00 0.00 0.00 37 > |__ghc_worker > 06:40:55 AM - 2848960 0.00 0.00 0.00 0.00 3 > |__ghc_worker > 06:40:55 AM - 2848961 0.00 0.00 0.00 0.00 2 > |__ghc_worker > 06:40:55 AM - 2848962 0.00 0.00 0.00 0.00 36 > |__ghc_worker > 06:40:55 AM - 2848963 0.00 0.00 0.00 0.00 21 > |__ghc_worker > 06:40:55 AM - 2848964 0.00 0.00 0.00 0.00 31 > |__ghc_worker > 06:40:55 AM - 2848965 0.00 0.00 0.00 0.00 11 > |__ghc_worker > 06:40:55 AM - 2848966 0.00 0.00 0.00 0.00 24 > |__ghc_worker > 06:40:55 AM - 2848967 0.00 0.00 0.00 0.00 38 > |__ghc_worker > 06:40:55 AM - 2848968 0.00 0.00 0.00 0.00 23 > |__ghc_worker > 06:40:55 AM - 2848969 0.00 0.00 0.00 0.00 22 > |__ghc_worker > 06:40:55 AM - 2848970 0.00 0.00 0.00 0.00 31 > |__ghc_worker > }}} > > {{{ > $ pidstat -t -p $(pidof ghc) | grep ghc_worker > 06:41:37 AM - 2848953 0.00 0.00 0.00 0.00 21 > |__ghc_worker > 06:41:37 AM - 2848954 0.00 0.00 0.00 0.00 31 > |__ghc_worker > 06:41:37 AM - 2848955 0.00 0.00 0.00 0.00 3 > |__ghc_worker > 06:41:37 AM - 2848957 0.00 0.00 0.00 0.00 3 > |__ghc_worker > 06:41:37 AM - 2848958 0.00 0.00 0.00 0.00 22 > |__ghc_worker > 06:41:37 AM - 2848959 0.00 0.00 0.00 0.00 37 > |__ghc_worker > 06:41:37 AM - 2848960 0.00 0.00 0.00 0.00 5 > |__ghc_worker > 06:41:37 AM - 2848961 0.00 0.00 0.00 0.00 5 > |__ghc_worker > 06:41:37 AM - 2848962 0.00 0.00 0.00 0.00 36 > |__ghc_worker > 06:41:37 AM - 2848963 0.00 0.00 0.00 0.00 7 > |__ghc_worker > 06:41:37 AM - 2848964 0.00 0.00 0.00 0.00 12 > |__ghc_worker > 06:41:37 AM - 2848965 0.00 0.00 0.00 0.00 11 > |__ghc_worker > 06:41:37 AM - 2848966 0.00 0.00 0.00 0.00 24 > |__ghc_worker > 06:41:37 AM - 2848967 0.00 0.00 0.00 0.00 38 > |__ghc_worker > 06:41:37 AM - 2848968 0.00 0.00 0.00 0.00 23 > |__ghc_worker > 06:41:37 AM - 2848969 0.00 0.00 0.00 0.00 8 > |__ghc_worker > 06:41:37 AM - 2848970 0.00 0.00 0.00 0.00 14 > |__ghc_worker > 06:41:37 AM - 2850193 0.00 0.00 0.00 0.00 32 > |__ghc_worker > 06:41:37 AM - 2850194 0.00 0.00 0.00 0.00 33 > |__ghc_worker > 06:41:37 AM - 2850196 0.00 0.00 0.00 0.00 34 > |__ghc_worker > 06:41:37 AM - 2850197 0.00 0.00 0.00 0.00 35 > |__ghc_worker > 06:41:37 AM - 2850198 0.00 0.00 0.00 0.00 10 > |__ghc_worker > 06:41:37 AM - 2850199 0.00 0.00 0.00 0.00 17 > |__ghc_worker > 06:41:37 AM - 2850294 0.00 0.00 0.00 0.00 21 > |__ghc_worker > 06:41:37 AM - 2850295 0.00 0.00 0.00 0.00 31 > |__ghc_worker > }}} > > {{{ > $ pidstat -t -p $(pidof ghc) | grep ghc_worker > 06:42:43 AM - 2848953 0.00 0.00 0.00 0.00 21 > |__ghc_worker > 06:42:43 AM - 2848954 0.00 0.00 0.00 0.00 31 > |__ghc_worker > 06:42:43 AM - 2848955 0.00 0.00 0.00 0.00 3 > |__ghc_worker > 06:42:43 AM - 2848957 0.00 0.00 0.00 0.00 7 > |__ghc_worker > 06:42:43 AM - 2848958 0.00 0.00 0.00 0.00 22 > |__ghc_worker > 06:42:43 AM - 2848959 0.00 0.00 0.00 0.00 37 > |__ghc_worker > 06:42:43 AM - 2848960 0.00 0.00 0.00 0.00 9 > |__ghc_worker > 06:42:43 AM - 2848961 0.00 0.00 0.00 0.00 0 > |__ghc_worker > 06:42:43 AM - 2848962 0.00 0.00 0.00 0.00 36 > |__ghc_worker > 06:42:43 AM - 2848963 0.00 0.00 0.00 0.00 4 > |__ghc_worker > 06:42:43 AM - 2848964 0.00 0.00 0.00 0.00 12 > |__ghc_worker > 06:42:43 AM - 2848965 0.00 0.00 0.00 0.00 11 > |__ghc_worker > 06:42:43 AM - 2848966 0.00 0.00 0.00 0.00 24 > |__ghc_worker > 06:42:43 AM - 2848967 0.00 0.00 0.00 0.00 38 > |__ghc_worker > 06:42:43 AM - 2848968 0.00 0.00 0.00 0.00 23 > |__ghc_worker > 06:42:43 AM - 2848969 0.00 0.00 0.00 0.00 29 > |__ghc_worker > 06:42:43 AM - 2848970 0.00 0.00 0.00 0.00 14 > |__ghc_worker > 06:42:43 AM - 2850193 0.00 0.00 0.00 0.00 32 > |__ghc_worker > 06:42:43 AM - 2850196 0.00 0.00 0.00 0.00 34 > |__ghc_worker > 06:42:43 AM - 2850197 0.00 0.00 0.00 0.00 35 > |__ghc_worker > 06:42:43 AM - 2850198 0.00 0.00 0.00 0.00 10 > |__ghc_worker > 06:42:43 AM - 2850199 0.00 0.00 0.00 0.00 19 > |__ghc_worker > 06:42:43 AM - 2850295 0.00 0.00 0.00 0.00 13 > |__ghc_worker > 06:42:43 AM - 2861009 0.00 0.00 0.00 0.00 34 > |__ghc_worker > 06:42:43 AM - 2861010 0.00 0.00 0.00 0.00 35 > |__ghc_worker > }}} > > {{{ > $ pidstat -t -p $(pidof ghc) | grep ghc_worker > 06:43:37 AM - 2848953 0.00 0.00 0.00 0.00 21 > |__ghc_worker > 06:43:37 AM - 2848954 0.00 0.00 0.00 0.00 31 > |__ghc_worker > 06:43:37 AM - 2848955 0.00 0.00 0.00 0.00 9 > |__ghc_worker > 06:43:37 AM - 2848957 0.00 0.00 0.00 0.00 9 > |__ghc_worker > 06:43:37 AM - 2848958 0.00 0.00 0.00 0.00 22 > |__ghc_worker > 06:43:37 AM - 2848959 0.00 0.00 0.00 0.00 37 > |__ghc_worker > 06:43:37 AM - 2848960 0.00 0.00 0.00 0.00 29 > |__ghc_worker > 06:43:37 AM - 2848961 0.00 0.00 0.00 0.00 20 > |__ghc_worker > 06:43:37 AM - 2848962 0.00 0.00 0.00 0.00 36 > |__ghc_worker > 06:43:37 AM - 2848963 0.00 0.00 0.00 0.00 3 > |__ghc_worker > 06:43:37 AM - 2848964 0.00 0.00 0.00 0.00 12 > |__ghc_worker > 06:43:37 AM - 2848965 0.00 0.00 0.00 0.00 15 > |__ghc_worker > 06:43:37 AM - 2848966 0.00 0.00 0.00 0.00 24 > |__ghc_worker > 06:43:37 AM - 2848967 0.00 0.00 0.00 0.00 38 > |__ghc_worker > 06:43:37 AM - 2848968 0.00 0.00 0.00 0.00 23 > |__ghc_worker > 06:43:37 AM - 2848969 0.00 0.00 0.00 0.00 1 > |__ghc_worker > 06:43:37 AM - 2848970 0.00 0.00 0.00 0.00 19 > |__ghc_worker > 06:43:37 AM - 2850193 0.00 0.00 0.00 0.00 32 > |__ghc_worker > 06:43:37 AM - 2850196 0.00 0.00 0.00 0.00 34 > |__ghc_worker > 06:43:37 AM - 2850197 0.00 0.00 0.00 0.00 35 > |__ghc_worker > 06:43:37 AM - 2850198 0.00 0.00 0.00 0.00 30 > |__ghc_worker > 06:43:37 AM - 2861009 0.00 0.00 0.00 0.00 17 > |__ghc_worker > 06:43:37 AM - 2861010 0.00 0.00 0.00 0.00 19 > |__ghc_worker > 06:43:37 AM - 2862954 0.00 0.00 0.00 0.00 2 > |__ghc_worker > 06:43:37 AM - 2862956 0.00 0.00 0.00 0.00 26 > |__ghc_worker > }}} > > The sets of threads are changing on every suspend, unsuspend combination. > > This is really visible when running in gdb with -j40, gdb just spews > threads getting spawned and killed: > {{{ > [Thread 0x7f0b767fc700 (LWP 2881933) exited] > [New Thread 0x7f0b767fc700 (LWP 2881940)] > [New Thread 0x7f0cc2cfd700 (LWP 2881941)] > [Thread 0x7f0b76ffd700 (LWP 2881928) exited] > [New Thread 0x7f0b7dffb700 (LWP 2881942)] > [New Thread 0x7f0b76ffd700 (LWP 2881943)] > [New Thread 0x7f0b7ffff700 (LWP 2881944)] > [Thread 0x7f0b777fe700 (LWP 2881932) exited] > [Thread 0x7f0b77fff700 (LWP 2881931) exited] > [Thread 0x7f0b7d7fa700 (LWP 2881927) exited] > [Thread 0x7f0b7f7fe700 (LWP 2881926) exited] > [New Thread 0x7f0b7f7fe700 (LWP 2881945)] > [New Thread 0x7f0b7d7fa700 (LWP 2881948)] > [Thread 0x7f0cc2cfd700 (LWP 2881941) exited] > [Thread 0x7f0b75ffb700 (LWP 2881938) exited] > [New Thread 0x7f0cc2cfd700 (LWP 2881949)] > [Thread 0x7f0b767fc700 (LWP 2881940) exited] > [New Thread 0x7f0b767fc700 (LWP 2881950)] > [New Thread 0x7f0b75ffb700 (LWP 2881951)] > [New Thread 0x7f0b77fff700 (LWP 2881952)] > [Thread 0x7f0b757fa700 (LWP 2881939) exited] > [Thread 0x7f0b7d7fa700 (LWP 2881948) exited] > [New Thread 0x7f0b757fa700 (LWP 2881953)] > [Thread 0x7f0b7effd700 (LWP 2881936) exited] > [Thread 0x7f0cc3cff700 (LWP 2881937) exited] > [New Thread 0x7f0cc3cff700 (LWP 2881954)] > [New Thread 0x7f0b7effd700 (LWP 2881955)] > [New Thread 0x7f0b7d7fa700 (LWP 2881956)] > [Thread 0x7f0b7dffb700 (LWP 2881942) exited] > [New Thread 0x7f0b777fe700 (LWP 2881957)] > [New Thread 0x7f0b7dffb700 (LWP 2881958)] > [Thread 0x7f0b76ffd700 (LWP 2881943) exited] > [New Thread 0x7f0b76ffd700 (LWP 2881959)] > [Thread 0x7f0b7e7fc700 (LWP 2881935) exited] > [Thread 0x7f0b7effd700 (LWP 2881955) exited] > [New Thread 0x7f0b7effd700 (LWP 2881962)] > [New Thread 0x7f0b7e7fc700 (LWP 2881963)] > [Thread 0x7f0b7f7fe700 (LWP 2881945) exited] > [New Thread 0x7f0b7f7fe700 (LWP 2881964)] > [New Thread 0x7f0b7cff9700 (LWP 2881965)] > [Thread 0x7f0b75ffb700 (LWP 2881951) exited] > [Thread 0x7f0b7dffb700 (LWP 2881958) exited] > [Thread 0x7f0cc3cff700 (LWP 2881954) exited] > [New Thread 0x7f0cc3cff700 (LWP 2881967)] > [New Thread 0x7f0b7dffb700 (LWP 2881968)] > [Thread 0x7f0b777fe700 (LWP 2881957) exited] > [Thread 0x7f0b757fa700 (LWP 2881953) exited] > [Thread 0x7f0cc2cfd700 (LWP 2881949) exited] > [Thread 0x7f0b7ffff700 (LWP 2881944) exited] > [New Thread 0x7f0cc2cfd700 (LWP 2881969)] > [Thread 0x7f0b7e7fc700 (LWP 2881963) exited] > [Thread 0x7f0b767fc700 (LWP 2881950) exited] > [New Thread 0x7f0b767fc700 (LWP 2881970)] > [New Thread 0x7f0b7e7fc700 (LWP 2881971)] > [Thread 0x7f0b77fff700 (LWP 2881952) exited] > [New Thread 0x7f0b7ffff700 (LWP 2881972)] > [New Thread 0x7f0b77fff700 (LWP 2881973)] > [New Thread 0x7f0b757fa700 (LWP 2881974)] > [Thread 0x7f0b7dffb700 (LWP 2881968) exited] > [New Thread 0x7f0b7dffb700 (LWP 2881975)] > [Thread 0x7f0cc2cfd700 (LWP 2881969) exited] > [New Thread 0x7f0cc2cfd700 (LWP 2881976)] > [Thread 0x7f0b76ffd700 (LWP 2881959) exited] > [Thread 0x7f0b757fa700 (LWP 2881974) exited] > [New Thread 0x7f0b76ffd700 (LWP 2881977)] > [New Thread 0x7f0b757fa700 (LWP 2881978)] > [New Thread 0x7f0b777fe700 (LWP 2881979)] > [Thread 0x7f0b7effd700 (LWP 2881962) exited] > [New Thread 0x7f0b7effd700 (LWP 2881980)] > [Thread 0x7f0b7ffff700 (LWP 2881972) exited] > [Thread 0x7f0b7e7fc700 (LWP 2881971) exited] > [Thread 0x7f0b77fff700 (LWP 2881973) exited] > [New Thread 0x7f0b77fff700 (LWP 2881981)] > [Thread 0x7f0b7d7fa700 (LWP 2881956) exited] > [New Thread 0x7f0b7d7fa700 (LWP 2881982)] > [New Thread 0x7f0b7e7fc700 (LWP 2881983)] > [Thread 0x7f0cc2cfd700 (LWP 2881976) exited] > [New Thread 0x7f0cc2cfd700 (LWP 2881984)] > [New Thread 0x7f0b7ffff700 (LWP 2881985)] > [New Thread 0x7f0b75ffb700 (LWP 2881986)] > [Thread 0x7f0b7dffb700 (LWP 2881975) exited] > [New Thread 0x7f0b7dffb700 (LWP 2881987)] > [New Thread 0x7f0b74ff9700 (LWP 2881988)] > [Thread 0x7f0b777fe700 (LWP 2881979) exited] > [Thread 0x7f0b7effd700 (LWP 2881980) exited] > [Thread 0x7f0b76ffd700 (LWP 2881977) exited] > }}} New description: When you run: {{{ ghci -j8 ghci> :set -package array # in a different terminal: pidstat -t -p $(pidof ghc) | grep ghc_worker kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc) # SIGCONT doesn't really resume it, you have to run fg in the terminal where it runs pidstat -t -p $(pidof ghc) | grep ghc_worker kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc) pidstat -t -p $(pidof ghc) | grep ghc_worker kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc) pidstat -t -p $(pidof ghc) | grep ghc_worker }}} You get: {{{ $ pidstat -t -p $(pidof ghc) | grep ghc_worker 06:40:55 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:40:55 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:40:55 AM - 2848955 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:40:55 AM - 2848957 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:40:55 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:40:55 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker 06:40:55 AM - 2848960 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:40:55 AM - 2848961 0.00 0.00 0.00 0.00 2 |__ghc_worker 06:40:55 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker 06:40:55 AM - 2848963 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:40:55 AM - 2848964 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:40:55 AM - 2848965 0.00 0.00 0.00 0.00 11 |__ghc_worker 06:40:55 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker 06:40:55 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker 06:40:55 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker 06:40:55 AM - 2848969 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:40:55 AM - 2848970 0.00 0.00 0.00 0.00 31 |__ghc_worker }}} {{{ $ pidstat -t -p $(pidof ghc) | grep ghc_worker 06:41:37 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:41:37 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:41:37 AM - 2848955 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:41:37 AM - 2848957 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:41:37 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:41:37 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker 06:41:37 AM - 2848960 0.00 0.00 0.00 0.00 5 |__ghc_worker 06:41:37 AM - 2848961 0.00 0.00 0.00 0.00 5 |__ghc_worker 06:41:37 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker 06:41:37 AM - 2848963 0.00 0.00 0.00 0.00 7 |__ghc_worker 06:41:37 AM - 2848964 0.00 0.00 0.00 0.00 12 |__ghc_worker 06:41:37 AM - 2848965 0.00 0.00 0.00 0.00 11 |__ghc_worker 06:41:37 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker 06:41:37 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker 06:41:37 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker 06:41:37 AM - 2848969 0.00 0.00 0.00 0.00 8 |__ghc_worker 06:41:37 AM - 2848970 0.00 0.00 0.00 0.00 14 |__ghc_worker 06:41:37 AM - 2850193 0.00 0.00 0.00 0.00 32 |__ghc_worker 06:41:37 AM - 2850194 0.00 0.00 0.00 0.00 33 |__ghc_worker 06:41:37 AM - 2850196 0.00 0.00 0.00 0.00 34 |__ghc_worker 06:41:37 AM - 2850197 0.00 0.00 0.00 0.00 35 |__ghc_worker 06:41:37 AM - 2850198 0.00 0.00 0.00 0.00 10 |__ghc_worker 06:41:37 AM - 2850199 0.00 0.00 0.00 0.00 17 |__ghc_worker 06:41:37 AM - 2850294 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:41:37 AM - 2850295 0.00 0.00 0.00 0.00 31 |__ghc_worker }}} {{{ $ pidstat -t -p $(pidof ghc) | grep ghc_worker 06:42:43 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:42:43 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:42:43 AM - 2848955 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:42:43 AM - 2848957 0.00 0.00 0.00 0.00 7 |__ghc_worker 06:42:43 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:42:43 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker 06:42:43 AM - 2848960 0.00 0.00 0.00 0.00 9 |__ghc_worker 06:42:43 AM - 2848961 0.00 0.00 0.00 0.00 0 |__ghc_worker 06:42:43 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker 06:42:43 AM - 2848963 0.00 0.00 0.00 0.00 4 |__ghc_worker 06:42:43 AM - 2848964 0.00 0.00 0.00 0.00 12 |__ghc_worker 06:42:43 AM - 2848965 0.00 0.00 0.00 0.00 11 |__ghc_worker 06:42:43 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker 06:42:43 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker 06:42:43 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker 06:42:43 AM - 2848969 0.00 0.00 0.00 0.00 29 |__ghc_worker 06:42:43 AM - 2848970 0.00 0.00 0.00 0.00 14 |__ghc_worker 06:42:43 AM - 2850193 0.00 0.00 0.00 0.00 32 |__ghc_worker 06:42:43 AM - 2850196 0.00 0.00 0.00 0.00 34 |__ghc_worker 06:42:43 AM - 2850197 0.00 0.00 0.00 0.00 35 |__ghc_worker 06:42:43 AM - 2850198 0.00 0.00 0.00 0.00 10 |__ghc_worker 06:42:43 AM - 2850199 0.00 0.00 0.00 0.00 19 |__ghc_worker 06:42:43 AM - 2850295 0.00 0.00 0.00 0.00 13 |__ghc_worker 06:42:43 AM - 2861009 0.00 0.00 0.00 0.00 34 |__ghc_worker 06:42:43 AM - 2861010 0.00 0.00 0.00 0.00 35 |__ghc_worker }}} {{{ $ pidstat -t -p $(pidof ghc) | grep ghc_worker 06:43:37 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:43:37 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:43:37 AM - 2848955 0.00 0.00 0.00 0.00 9 |__ghc_worker 06:43:37 AM - 2848957 0.00 0.00 0.00 0.00 9 |__ghc_worker 06:43:37 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:43:37 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker 06:43:37 AM - 2848960 0.00 0.00 0.00 0.00 29 |__ghc_worker 06:43:37 AM - 2848961 0.00 0.00 0.00 0.00 20 |__ghc_worker 06:43:37 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker 06:43:37 AM - 2848963 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:43:37 AM - 2848964 0.00 0.00 0.00 0.00 12 |__ghc_worker 06:43:37 AM - 2848965 0.00 0.00 0.00 0.00 15 |__ghc_worker 06:43:37 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker 06:43:37 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker 06:43:37 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker 06:43:37 AM - 2848969 0.00 0.00 0.00 0.00 1 |__ghc_worker 06:43:37 AM - 2848970 0.00 0.00 0.00 0.00 19 |__ghc_worker 06:43:37 AM - 2850193 0.00 0.00 0.00 0.00 32 |__ghc_worker 06:43:37 AM - 2850196 0.00 0.00 0.00 0.00 34 |__ghc_worker 06:43:37 AM - 2850197 0.00 0.00 0.00 0.00 35 |__ghc_worker 06:43:37 AM - 2850198 0.00 0.00 0.00 0.00 30 |__ghc_worker 06:43:37 AM - 2861009 0.00 0.00 0.00 0.00 17 |__ghc_worker 06:43:37 AM - 2861010 0.00 0.00 0.00 0.00 19 |__ghc_worker 06:43:37 AM - 2862954 0.00 0.00 0.00 0.00 2 |__ghc_worker 06:43:37 AM - 2862956 0.00 0.00 0.00 0.00 26 |__ghc_worker }}} The sets of threads are changing on every suspend, unsuspend combination. This is really visible when running in gdb with -j40, gdb just spews threads getting spawned and killed: {{{ [Thread 0x7f0b767fc700 (LWP 2881933) exited] [New Thread 0x7f0b767fc700 (LWP 2881940)] [New Thread 0x7f0cc2cfd700 (LWP 2881941)] [Thread 0x7f0b76ffd700 (LWP 2881928) exited] [New Thread 0x7f0b7dffb700 (LWP 2881942)] [New Thread 0x7f0b76ffd700 (LWP 2881943)] [New Thread 0x7f0b7ffff700 (LWP 2881944)] [Thread 0x7f0b777fe700 (LWP 2881932) exited] [Thread 0x7f0b77fff700 (LWP 2881931) exited] [Thread 0x7f0b7d7fa700 (LWP 2881927) exited] [Thread 0x7f0b7f7fe700 (LWP 2881926) exited] [New Thread 0x7f0b7f7fe700 (LWP 2881945)] [New Thread 0x7f0b7d7fa700 (LWP 2881948)] [Thread 0x7f0cc2cfd700 (LWP 2881941) exited] [Thread 0x7f0b75ffb700 (LWP 2881938) exited] [New Thread 0x7f0cc2cfd700 (LWP 2881949)] [Thread 0x7f0b767fc700 (LWP 2881940) exited] [New Thread 0x7f0b767fc700 (LWP 2881950)] [New Thread 0x7f0b75ffb700 (LWP 2881951)] [New Thread 0x7f0b77fff700 (LWP 2881952)] [Thread 0x7f0b757fa700 (LWP 2881939) exited] [Thread 0x7f0b7d7fa700 (LWP 2881948) exited] [New Thread 0x7f0b757fa700 (LWP 2881953)] [Thread 0x7f0b7effd700 (LWP 2881936) exited] [Thread 0x7f0cc3cff700 (LWP 2881937) exited] [New Thread 0x7f0cc3cff700 (LWP 2881954)] [New Thread 0x7f0b7effd700 (LWP 2881955)] [New Thread 0x7f0b7d7fa700 (LWP 2881956)] [Thread 0x7f0b7dffb700 (LWP 2881942) exited] [New Thread 0x7f0b777fe700 (LWP 2881957)] [New Thread 0x7f0b7dffb700 (LWP 2881958)] [Thread 0x7f0b76ffd700 (LWP 2881943) exited] [New Thread 0x7f0b76ffd700 (LWP 2881959)] [Thread 0x7f0b7e7fc700 (LWP 2881935) exited] [Thread 0x7f0b7effd700 (LWP 2881955) exited] [New Thread 0x7f0b7effd700 (LWP 2881962)] [New Thread 0x7f0b7e7fc700 (LWP 2881963)] [Thread 0x7f0b7f7fe700 (LWP 2881945) exited] [New Thread 0x7f0b7f7fe700 (LWP 2881964)] [New Thread 0x7f0b7cff9700 (LWP 2881965)] [Thread 0x7f0b75ffb700 (LWP 2881951) exited] [Thread 0x7f0b7dffb700 (LWP 2881958) exited] [Thread 0x7f0cc3cff700 (LWP 2881954) exited] [New Thread 0x7f0cc3cff700 (LWP 2881967)] [New Thread 0x7f0b7dffb700 (LWP 2881968)] [Thread 0x7f0b777fe700 (LWP 2881957) exited] [Thread 0x7f0b757fa700 (LWP 2881953) exited] [Thread 0x7f0cc2cfd700 (LWP 2881949) exited] [Thread 0x7f0b7ffff700 (LWP 2881944) exited] [New Thread 0x7f0cc2cfd700 (LWP 2881969)] [Thread 0x7f0b7e7fc700 (LWP 2881963) exited] [Thread 0x7f0b767fc700 (LWP 2881950) exited] [New Thread 0x7f0b767fc700 (LWP 2881970)] [New Thread 0x7f0b7e7fc700 (LWP 2881971)] [Thread 0x7f0b77fff700 (LWP 2881952) exited] [New Thread 0x7f0b7ffff700 (LWP 2881972)] [New Thread 0x7f0b77fff700 (LWP 2881973)] [New Thread 0x7f0b757fa700 (LWP 2881974)] [Thread 0x7f0b7dffb700 (LWP 2881968) exited] [New Thread 0x7f0b7dffb700 (LWP 2881975)] [Thread 0x7f0cc2cfd700 (LWP 2881969) exited] [New Thread 0x7f0cc2cfd700 (LWP 2881976)] [Thread 0x7f0b76ffd700 (LWP 2881959) exited] [Thread 0x7f0b757fa700 (LWP 2881974) exited] [New Thread 0x7f0b76ffd700 (LWP 2881977)] [New Thread 0x7f0b757fa700 (LWP 2881978)] [New Thread 0x7f0b777fe700 (LWP 2881979)] [Thread 0x7f0b7effd700 (LWP 2881962) exited] [New Thread 0x7f0b7effd700 (LWP 2881980)] [Thread 0x7f0b7ffff700 (LWP 2881972) exited] [Thread 0x7f0b7e7fc700 (LWP 2881971) exited] [Thread 0x7f0b77fff700 (LWP 2881973) exited] [New Thread 0x7f0b77fff700 (LWP 2881981)] [Thread 0x7f0b7d7fa700 (LWP 2881956) exited] [New Thread 0x7f0b7d7fa700 (LWP 2881982)] [New Thread 0x7f0b7e7fc700 (LWP 2881983)] [Thread 0x7f0cc2cfd700 (LWP 2881976) exited] [New Thread 0x7f0cc2cfd700 (LWP 2881984)] [New Thread 0x7f0b7ffff700 (LWP 2881985)] [New Thread 0x7f0b75ffb700 (LWP 2881986)] [Thread 0x7f0b7dffb700 (LWP 2881975) exited] [New Thread 0x7f0b7dffb700 (LWP 2881987)] [New Thread 0x7f0b74ff9700 (LWP 2881988)] [Thread 0x7f0b777fe700 (LWP 2881979) exited] [Thread 0x7f0b7effd700 (LWP 2881980) exited] [Thread 0x7f0b76ffd700 (LWP 2881977) exited] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 15:05:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 15:05:27 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.527100b2e57a97a2f0bc5b1ac05c0271@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): So this crash happens because of `SEHOP`, on the Windows client versions (Vista+) it is '''off''' by default (Windows 8 has it on for Microsoft processes) but on Windows server 2008 SEHOP is '''on''' by default. `SEHOP` is a `SEH` exploit mitigation technique which among others checks that the `SEH` registration records ends with the default handler in `ntdll`. http://blogs.technet.com/b/srd/archive/2009/02/02/preventing-the- exploitation-of-seh-overwrites-with-sehop.aspx and https://www.exploit- db.com/docs/15379.pdf for how it works. This same error can be gotten on windows 7 (or 8) by opting in to `SEHOP` manually http://blogs.technet.com/b/srd/archive/2009/11/20/sehop-per- process-opt-in-support-in-windows-7.aspx . This can be done globally or per process. `MingW-w64` and `MSVC++` don't seem to have this problem, they both preserve the exception chain properly. But `GHC i686` seems to be using `Mingw` which has a different `crtmain`. But looking at it I can't figure out why it's going wrong, http://sourceforge.net/p/mingw/mingw-org- wsl/ci/21762bb4a1bd0c88c38eead03f59e8d994349e83/tree/src/libcrt/crt/crt1.c#l212 unless `SetUnhandledExceptionFilter` clears the exception chain. But that's doubtful (and calling it from `Mingw-w64 g++` didn't reproduce the error). This is looking like it's a bug in `libcrt` *somewhere* though I am not entirely sure, but there's nothing in GHC's `rts` that's manually modifying the exception chain (as far as I know). So on the short term, what can you do? I can think of two options: 1) compile the code to x86_64 2) opt your binary out of `SEHOP` on Windows 2008 R2 Second one is the easiest. For GHC, we should either find out what's causing the issue and report it upwards (but Mingw hasn't been maintained since 2012 on first glance) or switch to MingW-w64 for both x86 and x64_86 since they seem to do it right http://sourceforge.net/p/mingw-w64/mingw-w64/ci/8a67ab4541226a80b3ec2047347890d915126de1/tree/mingw-w64-headers/crt/excpt.h#l102 A bit more detail on what's happening: {{{ BUGCHECK_STR: APPLICATION_FAULT_APPLICATION_FAULT_SEHOP PRIMARY_PROBLEM_CLASS: APPLICATION_FAULT_SEHOP DEFAULT_BUCKET_ID: APPLICATION_FAULT_SEHOP LAST_CONTROL_TRANSFER: from 74059339 to 74efb727 STACK_TEXT: 00cedd78 74059339 e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x58 00ceddb8 741e106a 00ceddd4 741e2280 026021b4 msvcr120!_CxxThrowException+0x5b 00ceddf0 004015b6 741e2104 00000000 00000000 Exception_cpp!foo+0x6a WARNING: Stack unwind information not available. Following frames may be wrong. 00cedef0 76f9cbaf 00000000 00cee1a4 00000000 TestExceptions+0x15b6 74aba010 80000018 00000000 00000000 00000000 ntdll!LdrpResCompareResourceNames+0x1dc 74aba034 00000000 00010000 00000409 00000048 0x80000018 }}} When `RaiseException` is called it tried to walk the exception chain. On load, the exception chain is: {{{ 00cefb08: ntdll!_except_handler4+0 (77b274a0) CRT scope 0, filter: ntdll!LdrpDoDebuggerBreak+2e (77b43bf0) func: ntdll!LdrpDoDebuggerBreak+32 (77b43bf4) 00cefca8: ntdll!_except_handler4+0 (77b274a0) CRT scope 0, func: ntdll!LdrpInitializeProcess+16d4 (77b18e85) 00cefcf8: ntdll!_except_handler4+0 (77b274a0) CRT scope 0, filter: ntdll!_LdrpInitialize+42ace (77b2d4a4) func: ntdll!_LdrpInitialize+42ae1 (77b2d4b7) }}} But when the exception happens something's off: {{{ 0:000> gh ModLoad: 75470000 75497000 C:\WINDOWS\SysWOW64\IMM32.DLL ModLoad: 759b0000 75ac2000 C:\WINDOWS\SysWOW64\MSCTF.dll (2171c.203c4): C++ EH exception - code e06d7363 (first chance) (2171c.203c4): C++ EH exception - code e06d7363 (!!! second chance !!!) eax=00cedd10 ebx=004e6670 ecx=00000003 edx=00000000 esi=62602200 edi=00ceddc4 eip=75b04598 esp=00cedd10 ebp=00cedd68 iopl=0 nv up ei pl nz ac po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000212 KERNELBASE!RaiseException+0x48: 75b04598 8b4c2454 mov ecx,dword ptr [esp+54h] ss:002b:00cedd64=8a43e393 0:000> !exchain 00ceddd4: *** ERROR: Symbol file could not be found. Defaulted to export symbols for H:\Exception.cpp.dll - Exception_cpp!foo+ae0 (62601ae0) 00cefe88: 00000000 Invalid exception stack at 02603bc4 }}} Without SEHOP the invalid stack is ignored, with SEHOP that fault `(NTSTATUS) 0xe06d7363` is thrown and you get the crash you reported. For the record, the `mingw-w64` compilers return: {{{ 00eafdd4: msvcrt!_except_handler4+0 (773c7220) CRT scope 0, func: msvcrt!doexit+110 (773b3bcc) 00eaffcc: ntdll!_except_handler4+0 (77b274a0) CRT scope 0, filter: ntdll!__RtlUserThreadStart+54386 (77b3f076) func: ntdll!__RtlUserThreadStart+543cd (77b3f0bd) 00eaffe4: ntdll!FinalExceptionHandlerPad50+0 (77ad0241) }}} Which also correctly ends in `FinalExceptionHandler`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 15:27:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 15:27:04 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.b8b9f54e2f6ad1d41cc27d06cf9b6a05@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by darchon): Note that the following doesn't work: ghc-7.10.1, cabal-1.22 {{{ cabal install GLUT --ghc-options="-framework GLUT" -v --reinstall --jobs=1 }}} GHCi {{{ ~$ ghci -package GLUT GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help : can't load .so/.DLL for: /Users/baaijcpr/.cabal/lib/x86_64 -osx-ghc-7.10.1/GLUT_6oGfBpdyNXm6GXGpRB4gPs/libHSGLUT-2.7.0.1 -6oGfBpdyNXm6GXGpRB4gPs-ghc7.10.1.dylib (dlopen(/Users/baaijcpr/.cabal/lib/x86_64-osx- ghc-7.10.1/GLUT_6oGfBpdyNXm6GXGpRB4gPs/libHSGLUT-2.7.0.1 -6oGfBpdyNXm6GXGpRB4gPs-ghc7.10.1.dylib, 5): Symbol not found: _glutBitmap8By13 Referenced from: /Users/baaijcpr/.cabal/lib/x86_64-osx- ghc-7.10.1/GLUT_6oGfBpdyNXm6GXGpRB4gPs/libHSGLUT-2.7.0.1 -6oGfBpdyNXm6GXGpRB4gPs-ghc7.10.1.dylib Expected in: flat namespace in /Users/baaijcpr/.cabal/lib/x86_64-osx- ghc-7.10.1/GLUT_6oGfBpdyNXm6GXGpRB4gPs/libHSGLUT-2.7.0.1 -6oGfBpdyNXm6GXGpRB4gPs-ghc7.10.1.dylib) }}} But, the following: {{{ cabal install GLUT --ghc-options="-optl-Wl,-framework,GLUT" -v --reinstall --jobs=1 }}} does work: {{{ ~$ ghci -package GLUT GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> }}} Also note: {{{ ~$ otool -L /Users/baaijcpr/.cabal/lib/x86_64-osx- ghc-7.10.1/GLUT_6oGfBpdyNXm6GXGpRB4gPs/libHSGLUT-2.7.0.1 -6oGfBpdyNXm6GXGpRB4gPs-ghc7.10.1.dylib /Users/baaijcpr/.cabal/lib/x86_64-osx- ghc-7.10.1/GLUT_6oGfBpdyNXm6GXGpRB4gPs/libHSGLUT-2.7.0.1 -6oGfBpdyNXm6GXGpRB4gPs-ghc7.10.1.dylib: @rpath/libHSGLUT-2.7.0.1-6oGfBpdyNXm6GXGpRB4gPs-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/GLUT.framework/Versions/A/GLUT (compatibility version 1.0.0, current version 1.0.0) @rpath/libHScontainers-0.5.6.2-47ajk3tbda43DFWyeF3oHQ- ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSOpenGL-2.12.0.1-9zpp6vKdJq97sstSpFWLwQ-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHStext-1.2.0.3-FuxPCidOMu81GRnNfjdINK-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSbytestring-0.10.6.0-6vj5EoliHgNHISHCVCb069-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSdeepseq-1.4.1.1-FpR4obOZALU1lutWnrBldi-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSStateVar-1.1.0.0-FY7FZJIuVXGGZZi7Rs1xyW- ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSstm-2.4.4-877J9sNBpfS5cK4JeYiRK0-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSarray-0.5.1.0-FaHmcBFfuRM8kmZLEY8D5S-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSObjectName-1.1.0.0-Fs9LwEoYTY29YOLwQayVnG- ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSGLURaw-1.5.0.1-HqAsclS2A7s8JRekdgFMHg-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSOpenGLRaw-2.5.1.0-IAXjbJksiwTBy6GOuSpVcg- ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHStransformers-0.4.2.0-ALYlebOVzVI4kxbFX5SGhm- ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSbase-4.8.0.0-I5BErHzyOm07EBNpKBEeUv-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS- ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) }}} So my question is, does the `-framework` flag in GHC work at all?! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 15:43:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 15:43:59 -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.8ecdf9e6f78062497f943098ba5dab2a@haskell.org> #10510: Testsuite driver does not run tests in parallel on Windows -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): So what I know so far is that this seems to be a bug in the `msys-2.0` runtime that happens sporadically. In my case it manifests itself inside the `diff.exe` that is being called by the Python testsuite scripts. [[Image(http://i.imgur.com/IWciMQM.png)]] `diff.exe` gets stuck in an infinite loop while starting up. Eventually, you'll either run out of cores or the tests finish but it'll wait on the one that's stuck. Looking at the stack of the application shows: {{{ msys-2.0.dll!Ordinal1816+0x1b7 msys-2.0.dll!Ordinal208+0x3e984 msys-2.0.dll!Ordinal130+0x171c msys-2.0.dll!Ordinal1816+0x1b7 ntdll.dll!RtlInitializeCriticalSection+0x10e ntdll.dll!RtlInitializeCriticalSection+0x88 ntdll.dll!RtlIsCriticalSectionLockedByThread+0x2a5 ntdll.dll!RtlIsCriticalSectionLockedByThread+0x1ed ntdll.dll!RtlGetVersion+0x7c0 ntdll.dll!RtlInitializeHandleTable+0xe89 ntdll.dll!RtlInitializeHandleTable+0x45 ntdll.dll!LdrInitializeThunk+0x10 }}} and it never exits from `msys-2.0.dll!Ordinal1816`. Curiously `msys-2.0.dll` does not export anything with ordinal `1816` so I am not sure what happens here. Unfortunately because this is happening inside a critical section the debuggers won't attach. `strace`, `gdb` and `windbg` just wait to break in. Eventually `windbg` will time out and suspend the program to allow you to look, but it doesn't allow you to step to see what may be causing the loop. I'm currently attempting to find the `msys-2.0 runtime` version that introduced the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 15:44:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 15:44:09 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.4bec0415e5569a63dbc20dd7c0aeedc1@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): darchon, can you add `-v` to the ghc-options of those two cabal install commands and provide the verbose output of cabal and of ghc? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 15:56:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 15:56:55 -0000 Subject: [GHC] #10583: Chaos in Lexeme.hs In-Reply-To: <047.ca228b2a0d43586fb2828ecd680f46fc@haskell.org> References: <047.ca228b2a0d43586fb2828ecd680f46fc@haskell.org> Message-ID: <062.7d9c861af58c069098e0ff36bd730d74@haskell.org> #10583: Chaos in Lexeme.hs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: 10582 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Hello Richard, If you look at the types and the use-sites of the functions in question, you can get a clue what they are used for. * `isLexVarSym` operates on `FastString`s, and is primarily called by `isSymOcc` to do tests on `OccName`s. We variously need this to do things like check if a symbol name is valid (language check for `TypeOperators`) or make a decision about how to pretty-print a symbol, etc. * `okSymChar` operates on `String`s, and is used by the Template Haskell conversion interface to test that a TH-generated identifier looks like a valid symbol (if it is one.) * `notFollowedBySymbol` operates on the Alex state, and is used to make decisions in the Lexer. This one might be a bit more permissive than the others, since lexer errors are not nice for users but errors in the type- checker are much nicer. So probably `isLexVarSym` and `okSymChar` can and should be combined, but you'll have to do a goofy conversion from String to FastString to do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 17:03:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 17:03:38 -0000 Subject: [GHC] #10584: Installation of SFML failed In-Reply-To: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> References: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> Message-ID: <062.b72355866642927c7000c9e3f49061c7@haskell.org> #10584: Installation of SFML failed -------------------------------------+------------------------------------- Reporter: SoleSoul | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by SoleSoul): Cabal doesn't seem to look at this flag (and if it does, 10000 wasn't enough). I want to pass this flag to ghc but I don't know where cabal keeps the sources of the packages it downloads. Does it delete them on a failed build? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 17:05:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 17:05:24 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.d67ec504591b1b1711716f8ee6e2cba8@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: #9218 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Phyx-): * related: => #9218 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 17:10:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 17:10:00 -0000 Subject: [GHC] #10588: BangPat gets wrong SrcSpan. Message-ID: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> #10588: BangPat gets wrong SrcSpan. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In this simple file {{{#!hs {-# LANGUAGE BangPatterns #-} baz !"a" = bang }}} It can be seen that on line 28 the `BangPat` has the wrong `SrcSpan`. {{{#!hs annotations=lineno ({ typetest.hs:1:1 } Just (Ann (DP (0,0)) (ColDelta 1) DP (0,0) [] [((G AnnEofPos),DP (1,0))]) (HsModule (Nothing) (Nothing) [] [ ({ typetest.hs:3:1-15 } Just (Ann (DP (2,1)) (ColDelta 1) DP (2,1) [(Comment {commentPos = DP (0,29), commentContents = "{-# LANGUAGE BangPatterns #-}", commentIdentifier = RealSrcSpan SrcSpanOneLine "typetest.hs" 1 1 30, commentOrigin = Nothing},DP (0,0))] []) (ValD (FunBind ({ typetest.hs:3:1-3 } Just (Ann (DP (0,0)) (ColDelta 1) DP (0,0) [] [((G AnnVal),DP (0,0))]) (Unqual {OccName: baz})) (False) (MG [ ({ typetest.hs:3:1-15 } Just (Ann (DP (0,0)) (ColDelta 1) DP (0,0) [] [((G AnnEqual),DP (0,1)),((AnnList NotNeeded),DP (0,0))]) (Match (Just ((,) ({ typetest.hs:3:1-3 } Just (Ann (DP (0,0)) (ColDelta 1) DP (0,0) [] [((G AnnVal),DP (0,0))]) (Unqual {OccName: baz})) (False))) [ ({ typetest.hs:3:1-8 } Just (Ann (DP (0,-3)) (ColDelta 1) DP (0,-3) [] [((G AnnBang),DP (0,1))]) (BangPat ({ typetest.hs:3:6-8 } Just (Ann (DP (0,0)) (ColDelta 6) DP (0,0) [] [((G AnnVal),DP (0,0))]) (LitPat (HsString "\"a\"" {FastString: "a"})))))] (Nothing) (GRHSs [ ({ typetest.hs:3:10-15 } Just (Ann (DP (0,-1)) (ColDelta 10) DP (0,-1) [] []) (GRHS [] ({ typetest.hs:3:12-15 } Just (Ann (DP (0,1)) (ColDelta 12) DP (0,1) [] [((G AnnVal),DP (0,0))]) (HsVar (Unqual {OccName: bang})))))] (EmptyLocalBinds))))] [] (PlaceHolder) (FromSource)) (WpHole) (PlaceHolder) [])))] (Nothing) (Nothing))) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 17:11:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 17:11:15 -0000 Subject: [GHC] #10588: BangPat gets wrong SrcSpan. In-Reply-To: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> References: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> Message-ID: <064.53befa34615179912a1ac307bfcd0b49@haskell.org> #10588: BangPat gets wrong SrcSpan. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab: | D1020 -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab: D1020 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 17:12:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 17:12:55 -0000 Subject: [GHC] #10588: BangPat gets wrong SrcSpan. In-Reply-To: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> References: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> Message-ID: <064.b309b9f88eaac819f42d6ec3562b102b@haskell.org> #10588: BangPat gets wrong SrcSpan. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1020 -------------------------------------+------------------------------------- Changes (by mpickering): * differential: Phab: D1020 => Phab:D1020 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 17:13:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 17:13:12 -0000 Subject: [GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python In-Reply-To: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> References: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> Message-ID: <060.aedf97d7265e041be676b4c2fb1b5160@haskell.org> #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python ---------------------------------+----------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: 9218 Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by Phyx-): Aren't we hosting the tar-balls in a different git repository? we can just repackage it there which would be the least amount of work. Alternatively, we seem to be using Rubenvb's msys2 builds, so we could just modify the build scripts https://github.com/rubenvb/MinGW-w64-build- scripts and remove what we don't need and use these in the repo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 17:13:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 17:13:44 -0000 Subject: [GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python In-Reply-To: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> References: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> Message-ID: <060.6a535007b469b06ad3ead6057a896f54@haskell.org> #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python ---------------------------------+----------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: 9218 Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 17:15:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 17:15:24 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.f3bca944729449f9c7ce8bb87947d3e0@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): I am still missing an apple-Darwin test file, but I have started preparing the changes for review, but I need to figure out how to modify validate to carry out the testing. Does validate allow for testing other binaries than GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 17:22:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 17:22:18 -0000 Subject: [GHC] #10584: Installation of SFML failed In-Reply-To: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> References: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> Message-ID: <062.ba9d9a92109658422cf51a51addd057e@haskell.org> #10584: Installation of SFML failed -------------------------------------+------------------------------------- Reporter: SoleSoul | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): you can use `cabal unpack sfml` to ask it to put the sources in the $cwd for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 17:33:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 17:33:51 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.d7aa1cabf000b38d3aa0daa97c2f39b8@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: #9218 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by malcolmw): Thanks for tracking this down. I'm going to try some registry-hacking, as suggested at https://support.microsoft.com/en-us/kb/956607 to disable SEHOP on our W2008 R2 server, as a workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 17:41:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 17:41:19 -0000 Subject: [GHC] #10583: Chaos in Lexeme.hs In-Reply-To: <047.ca228b2a0d43586fb2828ecd680f46fc@haskell.org> References: <047.ca228b2a0d43586fb2828ecd680f46fc@haskell.org> Message-ID: <062.b4aaf0a72f63f1876d69d677e08567d9@haskell.org> #10583: Chaos in Lexeme.hs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: 10582 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): We use `isLexVarSym` to check if a symbol name is valid? That should be refactored, because quite clearly the other `isLexXXX` functions do not do validity checking. And I don't agree about the goofy conversion: I want to combine `isVarSymChar` and `okSymChar`, both of type `Char -> Bool`. As for `notFollowedBySymbol`: This needs to be spot on -- a mistake in either direction would lead to wrong behavior. One place it's used is to detect banana brackets for arrow notation; see #10582. In the end, I can figure out what these functions are used for by poking around, but I just don't quite know what their specification is -- as in, what (precisely) they should do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 17:41:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 17:41:32 -0000 Subject: [GHC] #10588: BangPat gets wrong SrcSpan. In-Reply-To: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> References: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> Message-ID: <064.413b97d858609eb5b86319c30c4453b6@haskell.org> #10588: BangPat gets wrong SrcSpan. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1020 -------------------------------------+------------------------------------- Changes (by mpickering): * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 17:41:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 17:41:41 -0000 Subject: [GHC] #10588: BangPat gets wrong SrcSpan. In-Reply-To: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> References: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> Message-ID: <064.4262d0bed1609289b6ebbd22f536123f@haskell.org> #10588: BangPat gets wrong SrcSpan. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1020 -------------------------------------+------------------------------------- Changes (by mpickering): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 17:41:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 17:41:53 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.9690a3ca6db43fe57bd1b5393f36c96a@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: #9218 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): I would suggest doing it per-process instead of globally if this is an internet facing server since SEH exploits seem to be fairly common exploit vectors. That's detailed http://blogs.technet.com/b/srd/archive/2009/11/20 /sehop-per-process-opt-in-support-in-windows-7.aspx Could you let me know if disabling `SEHOP` works for you too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 18:40:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 18:40:42 -0000 Subject: [GHC] #10584: Installation of SFML failed In-Reply-To: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> References: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> Message-ID: <062.2347e6f50c21c1b7b9243c3b8fe1b661@haskell.org> #10584: Installation of SFML failed -------------------------------------+------------------------------------- Reporter: SoleSoul | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by SoleSoul): Ok, I've got it! My system: 4770k 8GB RAM Intel SSD I ran cabal build --ghc-options=-fsimpl-tick-factor=10000 It succeeded! Although the whole build except for this part was done in a blink of an eye, this part took: 3.1 GB of RAM 8:32 minutes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 19:12:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 19:12:29 -0000 Subject: [GHC] #10588: BangPat gets wrong SrcSpan. In-Reply-To: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> References: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> Message-ID: <064.9b29c150c17a6027d5c1f4d421e3d7c5@haskell.org> #10588: BangPat gets wrong SrcSpan. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1020 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"c6bb2fc50716a2fc540d55ecddbc5c14e94979f7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c6bb2fc50716a2fc540d55ecddbc5c14e94979f7" Correct BangPat SrcSpan calculation Summary: Previously when the split was performed in splitBang, `BangPat` was given the same SrcSpan as the whole of the LHS of the declaration. This patch correctly calculates the value. Reviewers: alanz, austin Reviewed By: alanz, austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1020 GHC Trac Issues: #10588 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 19:24:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 19:24:06 -0000 Subject: [GHC] #10588: BangPat gets wrong SrcSpan. In-Reply-To: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> References: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> Message-ID: <064.be44bba65675dce1a71a6d430f02c4e0@haskell.org> #10588: BangPat gets wrong SrcSpan. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1020 -------------------------------------+------------------------------------- Changes (by mpickering): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 20:52:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 20:52:27 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.bfea84c158f4ac6f066056fdf57e147e@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1012 -------------------------------------+------------------------------------- Comment (by bgamari): Phab:D1012 appears to give a moderate improvement in compile time in this case. Take, for instance, a 1000-constructor testcase, {{{#!hs module Mod(F(..)) where data F = F0 { fldF0 :: ()} | F1 { fldF1 :: ()} ... | F1023 {fldF1023 :: ()} deriving (Read) }}} With 7.11 prior to the change `ghc -O` runs for about 140 seconds. After the change it runs for about 100 seconds. Moreover, one sees a substantial reduction in heap allocations. The previously non-linear performance degradation can be seen in the table below. ||= Number of constructors =||||||= allocated (MBytes) =||||||= time (seconds) =|| ||= n =||= Pre-D1012 =||= Post-D1012 =||= Delta (%) =||= Post-D1012 =||= Post-D1012 =||= Delta (%) =|| || 16|| 1.75 ? 0.03 || 1.69 ? 0.02 || -3%|| 1484.58 ? 0.75 || 1470.53 ? 0.77 || -1%|| || 64|| 6.62 ? 0.25 || 5.96 ? 0.06 || -10%|| 5466.96 ? 1.53 || 5248.22 ? 1.64 || -4%|| || 128|| 13.33 ? 0.82 || 12.00 ? 0.63 || -10%|| 11282.75 ? 1.55 || 10406.51 ? 1.99 || -8%|| || 256|| 26.68 ? 0.53 || 23.69 ? 0.81 || -11%|| 24680.84 ? 2.32 || 21137.36 ? 2.36 || -14%|| || 512|| 67.61 ? 2.69 || 47.99 ? 0.67 || -29%|| 58628.48 ? 30.32 || 44412.63 ? 0.36 || -24%|| || 1024|| 144.91 ? 4.07 || 102.19 ? 0.60 || -29%|| 156753.21 ? 374.40 || 99523.84 ? 121.99 || -37%|| || 2048|| 379.93 ? 6.77 || 236.63 ? 3.51 || -38%|| 478481.02 ? 287.23 || 248791.64 ? 233.84 || -48%|| || 4096|| 1379.47 ? 0.00 || 650.83 ? 5.65 || -53%|| 1690084.72 ? 0.00 || 759242.66 ? 42.84 || -55%|| -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 21:42:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 21:42:39 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.cccc7157d6693b890e14a606f3eacfad@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1012 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 22:42:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 22:42:21 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.f8946d46aa373cb225ab848c37f10567@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by Rydgel): Confirming this behavior, here are the logs: [https://gist.githubusercontent.com/Rydgel/8d2168970b94e3da53cb/raw/736be850796fb08a171b2a3133ea0daa69212926/gistfile1.txt cabal install GLUT --ghc-options="-framework GLUT" -v --reinstall --jobs=1 ] [https://gist.githubusercontent.com/Rydgel/7976599b5ebb809aea9b/raw/76b5ad90c8870d003e715feb7074633ea0b9a289/gistfile1.txt cabal install GLUT --ghc-options="-optl-Wl,-framework,GLUT" -v --reinstall --jobs=1] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 22:53:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 22:53:43 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.d913e4716824661b51c302e04acafb15@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): And what about the output with `--ghc-options="-framework GLUT -v"`? How does ghc invoke the linker (gcc)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 23:20:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 23:20:52 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.b505bc1daddcc206fb5b4cd61bd745d1@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): > Does validate allow for testing other binaries than GHC? You can try adding a `run_command` test. See Building/RunningTests/Adding. You'll need to tell the testsuite where to find the splitter. See find_tool and canonicaliseExecutable in `testsuite/mk/boilerplate.mk`. Alternatively, use a `compile` test that sets `-split-objs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 23:35:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 23:35:09 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.113e5ed198dfe19a1b1e0d66ed85f40f@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by Rydgel): Like this? [https://gist.githubusercontent.com/Rydgel/1438870bface7e9fe455/raw/2e1193b93c98ad68df3de167baf2fe8b82cb19bb/gistfile1.txt --ghc-options="-framework GLUT -v"] [https://gist.githubusercontent.com/Rydgel/488c2354f75a608015b8/raw/1c567f212428c85b3a494b7519730456f3f6ee65/gistfile1.txt --ghc-options="-optl-Wl,-framework,GLUT -v"] Indeed, no {{{-framework}}} in the first case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 23:41:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 23:41:19 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.9f0da9eaa9990d2e5bff700e2de4b062@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): That's just the command to build one of the individual object files. The command I'm looking for follows `*** Linker:` and should contain `-o dist/build/libHSGLUT-2.5.1.1-ghc7.8.4.so` and is very long. (Thanks for all your help by the way!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 23:49:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 23:49:05 -0000 Subject: [GHC] #10589: Core Lint error with LambdaCase Message-ID: <047.e92627c402f6d1706c28de3a321bc37c@haskell.org> #10589: Core Lint error with LambdaCase -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE LambdaCase, TypeFamilies #-} type family F a where F a = Bool -> a foo = (\case True -> 5 False -> 6) :: F Int }}} `-dcore-lint` tells me {{{ *** Core Lint errors : in result of Desugar (after optimization) *** /Users/rae/temp/Bug.hs:6:1: Warning: [RHS of foo :: Bool -> Int] From-type of Cast differs from type of enclosed expression ... }}} The problem is a missing `mkTcSymCo` in the relevant bit of `tcExpr`. Will fix in ongoing work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 23:52:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 23:52:11 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) In-Reply-To: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> References: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> Message-ID: <059.b7be4a62e3cc816d0e124eb8c83bc5f0@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Unfortunately `-fkill-one-shot` made no difference. My gut feeling is that this is a bug in the RTS that was uncovered (for this program) by the cardinality analysis patch, but I have no real evidence for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 23:55:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 23:55:22 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.b0f8280c1a0599c251d3508ac78e9f8e@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by Rydgel): Oops sorry my bad. [https://gist.githubusercontent.com/Rydgel/1438870bface7e9fe455/raw/a88de76f5517a8fafb0b71eb68d3997a58b01b7c/gistfile1.txt ?--ghc-options="-framework GLUT -v"] [https://gist.githubusercontent.com/Rydgel/488c2354f75a608015b8/raw/de681e62fc81b0fcc4ce03298ba03fa89fcb99ee/gistfile1.txt --ghc-options="-optl-Wl,-framework,GLUT -v"] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 29 23:58:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Jun 2015 23:58:17 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.9297348fff86275865e6f3a0d49a2291@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): Ah, thank you! I'll get started doing that! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 00:45:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 00:45:11 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.236f0bf3b22672abcca82d73b6034c10@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): OK thanks. I made a little progress in understanding what's going on here. The `-framework` option does work when building an executable. See the handling of `framework_opts` in `DriverPipeline.linkBinary'`. However building a shared library is done by `SysTools.linkDynLib`. This function uses `ldInputs dflags`, which is initially set by ghc's `-lfoo` flag, to link against ordinary shared libraries, but it does no processing of framework options. So, that would seem to be a bug in ghc. I still don't understand why Cabal doesn't actually pass ghc `-framework GLUT` automatically when `GLUT.cabal` contains `frameworks: GLUT`. There's code that clearly intends to do so, see https://github.com/ghc/packages- Cabal/blob/master/Cabal/Distribution/Simple/Program/GHC.hs#L348. I think the reason this all used to work in 7.8 is that Cabal records the fact that the GLUT package needs the GLUT framework in the package registration, and ghci checks this and loads the GLUT framework before loading the GLUT package. However since #8935 that no longer makes the framework visible to the package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 06:24:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 06:24:43 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.d6a92e8d700207ac0a9df896619ca0d0@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+----------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 07:34:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 07:34:35 -0000 Subject: [GHC] #10482: Not enough unboxing happens on data-family function argument In-Reply-To: <043.b6b30783c65ab27e97e75d03aac8ab21@haskell.org> References: <043.b6b30783c65ab27e97e75d03aac8ab21@haskell.org> Message-ID: <058.aa41bad4d8f6ef8ab82be8dd887cf19f@haskell.org> #10482: Not enough unboxing happens on data-family function argument -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes, I want this ticket to stay open because it seems likely that the main commit caused the around 7% regression in allocation numbers for these two Haddock tests. I found that surprising and want to investigate. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 07:49:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 07:49:47 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.4c8c135ac065f78a96edc13566a4c9e5@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1012 -------------------------------------+------------------------------------- Comment (by simonpj): OK so it's now looking roughly linear, which is great. It still seems like a lot for what started life as a pretty small program. What does the profile show now? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 07:55:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 07:55:47 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.9d56f785fb28cf99c263a693ea591d53@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: #9218 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by malcolmw): Confirmed: disabling SEHOP in the registry makes C++ exceptions work again, when called from a ghc-compiled Haskell program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 07:58:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 07:58:16 -0000 Subject: [GHC] #9665: Add "since" information to LANGUAGE extensions in GHC user guide In-Reply-To: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> References: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> Message-ID: <066.3c3f8f390642c6fe147cf39df67b4dcd@haskell.org> #9665: Add "since" information to LANGUAGE extensions in GHC user guide -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: rasen Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1019 -------------------------------------+------------------------------------- Comment (by andreas.abel): We at agda have been using TupleSections with ghc 7.0, they must be at least that old... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 08:26:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 08:26:02 -0000 Subject: [GHC] #10547: feature request: expanding type synonyms in error messages In-Reply-To: <043.c20ed6dece31f72a0d7c2a22033dd48e@haskell.org> References: <043.c20ed6dece31f72a0d7c2a22033dd48e@haskell.org> Message-ID: <058.df72c5fc30630d424c3c486c3b567434@haskell.org> #10547: feature request: expanding type synonyms in error messages -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D1016 -------------------------------------+------------------------------------- Comment (by simonpj): Ha ha. Yes, ideally so. But in practice I suspect it'll be infeasible to find the maximally-unexpanded version; as your example shows. I'd settle for: * If the head of the application matches (i.e. `T t1` vs `T t2`) then walk down `t1`,`t2`. * Otherwise expand both sides to a non-synonym type constructor. There is room for cleverness here. But a function with the above signature (for `expandSynonymsToMatch`) will serve the purpose, and we could start with a fairly simple one as above. Or do something cleverer if you like. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 08:53:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 08:53:51 -0000 Subject: [GHC] #10585: Implement proper bidirectional type inference In-Reply-To: <047.d9317282c6b0be672717b58e6191b767@haskell.org> References: <047.d9317282c6b0be672717b58e6191b767@haskell.org> Message-ID: <062.ba74f0b84591cbcb3521e7887840930c@haskell.org> #10585: Implement proper bidirectional type inference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): On (3), you can look at the wiki page and attached PDF; and at branch `wip/impredicativity`. I confess that I'm not clear exactly what "this refactoring" is in concrete terms. It's probably not massive, and it sounds promising to me, so if you'd like to sketch it out or just do it, that would be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 09:22:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 09:22:24 -0000 Subject: [GHC] #9839: RTS options parser silently accepts invalid flags In-Reply-To: <049.1ac180907787acdf75c140998b5b4263@haskell.org> References: <049.1ac180907787acdf75c140998b5b4263@haskell.org> Message-ID: <064.faa4486c32ad93d27f0378b64dbf4b55@haskell.org> #9839: RTS options parser silently accepts invalid flags -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #4243 | Differential Revisions: Phab:D748 -------------------------------------+------------------------------------- Changes (by thomie): * owner: carlostome => * priority: normal => high * status: closed => new * resolution: fixed => * milestone: => 7.12.1 Comment: This patch broke `+RTS -xc`, and probably also `+RTS -xt`. Running `make TEST=cgrun057` with a profiling compiler results in: "flag -x given an argument when none was expected: -xc" Carlos: could you try fixing it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 13:03:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 13:03:20 -0000 Subject: [GHC] #10588: BangPat gets wrong SrcSpan. In-Reply-To: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> References: <049.d9fbf4f29a2865bce68ff10657b72f11@haskell.org> Message-ID: <064.e13dff29aab0d9c9f800da76198d039f@haskell.org> #10588: BangPat gets wrong SrcSpan. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1020 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 13:09:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 13:09:44 -0000 Subject: [GHC] #9665: Add "since" information to LANGUAGE extensions in GHC user guide In-Reply-To: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> References: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> Message-ID: <066.3876579a1cd7846dd0dc57884bba2844@haskell.org> #9665: Add "since" information to LANGUAGE extensions in GHC user guide -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: rasen Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1019 -------------------------------------+------------------------------------- Comment (by hvr): Fyi, the list in LanguagePragmaHistory is complete; so everything that 7.10 supports but isn't mentioned in the list has been supported since before 7.0 I didn't include the list of pragmas supported in 6.12, but here is the output of `ghc-6.12 --supported-languages`: https://gist.github.com/anonymous/5b28a41345e0a59644c2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 14:07:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 14:07:01 -0000 Subject: [GHC] #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 In-Reply-To: <047.dce4788acf854b7c92bad29baf2c8a65@haskell.org> References: <047.dce4788acf854b7c92bad29baf2c8a65@haskell.org> Message-ID: <062.1bc14655fe6c9679470c28808a91d1b0@haskell.org> #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | tests/typecheck/should_compile/T10562 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * testcase: => tests/typecheck/should_compile/T10562 * resolution: => fixed * milestone: 7.10.2 => 7.12.1 Comment: After a quick discussion with Simon, due to the infeasibility of fixing this (and there being a workaround), we're going to punt this to 7.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 17:41:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 17:41:24 -0000 Subject: [GHC] #10590: RTS failing with removeThreadFromDeQueue: not found message Message-ID: <045.1d70a7521e31b555660aa59499823ca1@haskell.org> #10590: RTS failing with removeThreadFromDeQueue: not found message -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Under certain circumstances I'm facing RTS error, this happens when one thread is reading socket and another one closes it. Seems like that it happens when smth else is involved as I failed to trim this example Error that I see: {{{ % ./test nid://127.0.0.1:8080:0 1 test: internal error: removeThreadFromDeQueue: not found (GHC version 7.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort ./test }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 18:47:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 18:47:41 -0000 Subject: [GHC] #10590: RTS failing with removeThreadFromDeQueue: not found message In-Reply-To: <045.1d70a7521e31b555660aa59499823ca1@haskell.org> References: <045.1d70a7521e31b555660aa59499823ca1@haskell.org> Message-ID: <060.ba35291e00e03e570dfb81b31813a466@haskell.org> #10590: RTS failing with removeThreadFromDeQueue: not found message -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 20:12:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 20:12:27 -0000 Subject: [GHC] #10591: repeated field name allowed in constructor Message-ID: <048.c0e481200ccaadde16a1293295705c43@haskell.org> #10591: repeated field name allowed in constructor -------------------------------------+------------------------------------- Reporter: gladstein | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs data Foo = Bar {x :: Int} | Baz {x :: Int, x :: String } main = do let a = Bar 1 b = Baz 2 "3" print $ x a print $ x b }}} :load "p:/DSFP/sandbox/bug1.hs" GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> [1 of 1] Compiling Main ( P:\DSFP\sandbox\bug1.hs, interpreted ) Ok, modules loaded: Main. *Main> main 1 1729382256910738103 *Main> -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 21:04:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 21:04:50 -0000 Subject: [GHC] #10591: repeated field name allowed in constructor In-Reply-To: <048.c0e481200ccaadde16a1293295705c43@haskell.org> References: <048.c0e481200ccaadde16a1293295705c43@haskell.org> Message-ID: <063.04424cc1b6b639f5c3ae4f2998053b0a@haskell.org> #10591: repeated field name allowed in constructor -------------------------------------+------------------------------------- Reporter: gladstein | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Thank you for the report. This is fixed in GHC 7.10: #9156. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 21:37:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 21:37:06 -0000 Subject: [GHC] #10590: RTS failing with removeThreadFromDeQueue: not found message In-Reply-To: <045.1d70a7521e31b555660aa59499823ca1@haskell.org> References: <045.1d70a7521e31b555660aa59499823ca1@haskell.org> Message-ID: <060.6d57c9afc8215e981c1cabbd8342abea@haskell.org> #10590: RTS failing with removeThreadFromDeQueue: not found message -------------------------------------+------------------------------------- Reporter: qnikst | Owner: slyfox Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by slyfox): * owner: => slyfox Comment: Found a bug in excessive dequeueing. Fix is on the way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 22:36:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 22:36:04 -0000 Subject: [GHC] #10590: RTS failing with removeThreadFromDeQueue: not found message In-Reply-To: <045.1d70a7521e31b555660aa59499823ca1@haskell.org> References: <045.1d70a7521e31b555660aa59499823ca1@haskell.org> Message-ID: <060.c607fd37fd06f9a00285284b311d0d4a@haskell.org> #10590: RTS failing with removeThreadFromDeQueue: not found message -------------------------------------+------------------------------------- Reporter: qnikst | Owner: slyfox Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1024 -------------------------------------+------------------------------------- Changes (by slyfox): * cc: simonmar (added) * differential: => Phab:D1024 * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 23:19:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 23:19:23 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) In-Reply-To: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> References: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> Message-ID: <059.31d44a062ce1815f22a84a18018a49b0@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by michaelt): I reduced this a little further so that it just uses the Monad instance and the two basic combinators: {{{#!hs rparWith s a = Eval $ \s0 -> spark# r s0 where r = case s a of Eval f -> case f realWorld# of (# _, a' #) -> a' runEval :: Eval a -> a runEval (Eval x) = case x realWorld# of (# _, a #) -> a }}} and a non-recursive but monotonously layered concrete function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 30 23:22:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Jun 2015 23:22:51 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) In-Reply-To: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> References: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> Message-ID: <059.99cf1c5eee1312710bb6b8833db02bcb@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by michaelt): The mechanism for attaching source must be before my eyes, but here is the reduced module: {{{#!hs {-# LANGUAGE MagicHash, UnboxedTuples #-} import Control.Applicative import Control.Monad import GHC.Exts newtype Eval a = Eval (State# RealWorld -> (# State# RealWorld, a #)) instance Functor Eval where fmap = liftM instance Applicative Eval where (<*>) = ap; pure = return instance Monad Eval where return x = Eval $ \s -> (# s, x #) Eval x >>= k = Eval $ \s -> case x s of (# s', a #) -> case k a of Eval f -> f s' rparWith s a = Eval $ \s0 -> spark# r s0 where r = case s a of Eval f -> case f realWorld# of (# _, a' #) -> a' runEval :: Eval a -> a runEval (Eval x) = case x realWorld# of (# _, a #) -> a main :: IO () main = do -- print $ length (pf 'x') -- either statement works at least on and off print (program 'y') -- but I seem to lose the effect if I use both statements program = pchunk . concatMap (pchunk . concatMap (pchunk . concatMap (pchunk . show) . show) . show) . show where -- the effect seems to vanish if I eta expand pchunk pchunk = runEval . fmap concat . mapM (rparWith (mapM (\x -> Eval $ \s -> seq# x s) )) . chunk' -- the effect seems to disappear if I reject splitAt in favor -- of a pattern match chunk' (a:b:c:xs) = [a,b,c]: chunk' xs chunk' :: [a] -> [[a]] chunk' [] = [] chunk' xs = as : chunk' bs where (as,bs) = splitAt 3 xs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 15 12:16:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Jun 2015 12:16:22 -0000 Subject: [GHC] #10528: compile time performance regression on big literal Message-ID: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> #10528: compile time performance regression on big literal -------------------------------------+------------------------------------- Reporter: jakewheat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- There is a big performance regression in the compile time from ghc 7.10.1 to ghc 7.10.1.20150612 I believe it is in this file which has a huge literal value which also contains overloaded strings using Text: https://github.com/JakeWheat/hssqlppp/blob/master/hssqlppp/src/Database/HsSqlPpp/Internals/Catalog/DefaultTemplate1Catalog.lhs {{{ time cabal build with ghc 7.10.1 real 1m20.449s user 2m5.040s sys 0m48.504s time cabal build with ghc 7.10.1.20150612 real 9m3.447s user 12m19.704s sys 3m25.724s }}} I am running debian 64 bit unstable with the ghc binary tarballs from here: https://www.haskell.org/ghc/ Here is a transcript: {{{ jake at debian:~/wd/hssqlppp/trunk/hssqlppp$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 jake at debian:~/wd/hssqlppp/trunk/hssqlppp$ cabal sandbox init Writing a default package environment file to /home/jake/wd/hssqlppp/trunk/hssqlppp/cabal.sandbox.config Creating a new sandbox at /home/jake/wd/hssqlppp/trunk/hssqlppp/.cabal- sandbox jake at debian:~/wd/hssqlppp/trunk/hssqlppp$ time cabal install happy Resolving dependencies... Notice: installing into a sandbox located at /home/jake/wd/hssqlppp/trunk/hssqlppp/.cabal-sandbox Configuring mtl-2.2.1... Building mtl-2.2.1... Installed mtl-2.2.1 Configuring happy-1.19.5... Building happy-1.19.5... Installed happy-1.19.5 real 0m18.442s user 0m16.896s sys 0m0.940s jake at debian:~/wd/hssqlppp/trunk/hssqlppp$ time cabal install --only- dependencies Resolving dependencies... Notice: installing into a sandbox located at /home/jake/wd/hssqlppp/trunk/hssqlppp/.cabal-sandbox Configuring old-locale-1.0.0.7... Configuring syb-0.4.4... Configuring text-1.2.1.1... Building old-locale-1.0.0.7... Building syb-0.4.4... Building text-1.2.1.1... Installed old-locale-1.0.0.7 Configuring old-time-1.1.0.3... Building old-time-1.1.0.3... Installed syb-0.4.4 Installed old-time-1.1.0.3 Installed text-1.2.1.1 Configuring hashable-1.2.3.2... Configuring parsec-3.1.9... Configuring polyparse-1.11... Building hashable-1.2.3.2... Building polyparse-1.11... Building parsec-3.1.9... Installed hashable-1.2.3.2 Configuring scientific-0.3.3.8... Configuring unordered-containers-0.2.5.1... Building scientific-0.3.3.8... Building unordered-containers-0.2.5.1... Installed scientific-0.3.3.8 Configuring attoparsec-0.12.1.6... Installed parsec-3.1.9 Building attoparsec-0.12.1.6... Installed polyparse-1.11 Configuring cpphs-1.19... Installed unordered-containers-0.2.5.1 Configuring uniplate-1.6.12... Building cpphs-1.19... Building uniplate-1.6.12... Installed cpphs-1.19 Configuring haskell-src-exts-1.16.0.1... Installed uniplate-1.6.12 Building haskell-src-exts-1.16.0.1... Installed attoparsec-0.12.1.6 Installed haskell-src-exts-1.16.0.1 Configuring groom-0.1.2... Building groom-0.1.2... Installed groom-0.1.2 real 5m15.306s user 6m16.976s sys 0m5.476s jake at debian:~/wd/hssqlppp/trunk/hssqlppp$ time cabal build Package has never been configured. Configuring with default flags. If this fails, please run configure manually. Resolving dependencies... Configuring hssqlppp-0.5.18... Building hssqlppp-0.5.18... Preprocessing library hssqlppp-0.5.18... [ 1 of 23] Compiling Database.HsSqlPpp.Parsing.ParseErrors ( src/Database/HsSqlPpp/Parsing/ParseErrors.lhs, dist/build/Database/HsSqlPpp/Parsing/ParseErrors.o ) [ 2 of 23] Compiling Database.HsSqlPpp.Utils.Utils ( src/Database/HsSqlPpp/Utils/Utils.lhs, dist/build/Database/HsSqlPpp/Utils/Utils.o ) src/Database/HsSqlPpp/Utils/Utils.lhs:9:3: Warning: The import of ‘Control.Applicative’ is redundant except perhaps to import instances from ‘Control.Applicative’ To import instances alone, use: import Control.Applicative() [ 3 of 23] Compiling Database.HsSqlPpp.Internals.TypesInternal ( src/Database/HsSqlPpp/Internals/TypesInternal.lhs, dist/build/Database/HsSqlPpp/Internals/TypesInternal.o ) [ 4 of 23] Compiling Database.HsSqlPpp.Types ( src/Database/HsSqlPpp/Types.lhs, dist/build/Database/HsSqlPpp/Types.o ) [ 5 of 23] Compiling Database.HsSqlPpp.Internals.TypeChecking.OldTediousTypeUtils ( src/Database/HsSqlPpp/Internals/TypeChecking/OldTediousTypeUtils.lhs, dist/build/Database/HsSqlPpp/Internals/TypeChecking/OldTediousTypeUtils.o ) [ 6 of 23] Compiling Database.HsSqlPpp.SqlDialect ( src/Database/HsSqlPpp/SqlDialect.lhs, dist/build/Database/HsSqlPpp/SqlDialect.o ) [ 7 of 23] Compiling Database.HsSqlPpp.LexicalSyntax ( src/Database/HsSqlPpp/LexicalSyntax.lhs, dist/build/Database/HsSqlPpp/LexicalSyntax.o ) [ 8 of 23] Compiling Database.HsSqlPpp.Internals.Catalog.CatalogInternal ( src/Database/HsSqlPpp/Internals/Catalog/CatalogInternal.lhs, dist/build/Database/HsSqlPpp/Internals/Catalog/CatalogInternal.o ) [ 9 of 23] Compiling Database.HsSqlPpp.Internals.Catalog.DefaultTemplate1Catalog ( src/Database/HsSqlPpp/Internals/Catalog/DefaultTemplate1Catalog.lhs, dist/build/Database/HsSqlPpp/Internals/Catalog/DefaultTemplate1Catalog.o ) [10 of 23] Compiling Database.HsSqlPpp.Internals.Catalog.DefaultTSQLCatalog ( src/Database/HsSqlPpp/Internals/Catalog/DefaultTSQLCatalog.lhs, dist/build/Database/HsSqlPpp/Internals/Catalog/DefaultTSQLCatalog.o ) [11 of 23] Compiling Database.HsSqlPpp.Internals.TypeChecking.OldTypeConversion ( src/Database/HsSqlPpp/Internals/TypeChecking/OldTypeConversion.lhs, dist/build/Database/HsSqlPpp/Internals/TypeChecking/OldTypeConversion.o ) [12 of 23] Compiling Database.HsSqlPpp.Internals.TypeChecking.SqlTypeConversion ( src/Database/HsSqlPpp/Internals/TypeChecking/SqlTypeConversion.lhs, dist/build/Database/HsSqlPpp/Internals/TypeChecking/SqlTypeConversion.o ) [13 of 23] Compiling Database.HsSqlPpp.Internals.TypeChecking.TypeConversion ( src/Database/HsSqlPpp/Internals/TypeChecking/TypeConversion.lhs, dist/build/Database/HsSqlPpp/Internals/TypeChecking/TypeConversion.o ) src/Database/HsSqlPpp/Internals/TypeChecking/TypeConversion.lhs:22:8: Warning: The export item ‘MatchAppLiteralList(..)’ suggests that ‘MatchAppLiteralList’ has (in-scope) constructors or class methods, but it has none src/Database/HsSqlPpp/Internals/TypeChecking/TypeConversion.lhs:34:3: Warning: The import of ‘Control.Applicative’ is redundant except perhaps to import instances from ‘Control.Applicative’ To import instances alone, use: import Control.Applicative() src/Database/HsSqlPpp/Internals/TypeChecking/TypeConversion.lhs:43:3: Warning: The import of ‘Debug.Trace’ is redundant except perhaps to import instances from ‘Debug.Trace’ To import instances alone, use: import Debug.Trace() [14 of 23] Compiling Database.HsSqlPpp.Internals.TypeChecking.Environment ( src/Database/HsSqlPpp/Internals/TypeChecking/Environment.lhs, dist/build/Database/HsSqlPpp/Internals/TypeChecking/Environment.o ) src/Database/HsSqlPpp/Internals/TypeChecking/Environment.lhs:228:41: Warning: Defined but not used: ‘j’ [15 of 23] Compiling Database.HsSqlPpp.Catalog ( src/Database/HsSqlPpp/Catalog.lhs, dist/build/Database/HsSqlPpp/Catalog.o ) [16 of 23] Compiling Database.HsSqlPpp.Internals.AstInternal ( src/Database/HsSqlPpp/Internals/AstInternal.hs, dist/build/Database/HsSqlPpp/Internals/AstInternal.o ) hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:848:30: Warning: Defined but not used: data constructor ‘Inh_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:848:53: Warning: Defined but not used: ‘cat_Inh_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:848:90: Warning: Defined but not used: ‘flags_Inh_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:848:139: Warning: Defined but not used: ‘imCast_Inh_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:849:30: Warning: Defined but not used: data constructor ‘Syn_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:849:53: Warning: Defined but not used: ‘annotatedTree_Syn_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:849:110: Warning: Defined but not used: ‘originalTree_Syn_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:853:1: Warning: Defined but not used: ‘wrap_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1287:35: Warning: Defined but not used: data constructor ‘Inh_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1287:63: Warning: Defined but not used: ‘cat_Inh_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1287:105: Warning: Defined but not used: ‘flags_Inh_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1287:159: Warning: Defined but not used: ‘imCast_Inh_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1288:35: Warning: Defined but not used: data constructor ‘Syn_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1288:63: Warning: Defined but not used: ‘annotatedTree_Syn_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1288:130: Warning: Defined but not used: ‘originalTree_Syn_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1292:1: Warning: Defined but not used: ‘wrap_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1451:29: Warning: Defined but not used: data constructor ‘Inh_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1451:51: Warning: Defined but not used: ‘cat_Inh_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1451:87: Warning: Defined but not used: ‘flags_Inh_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1451:135: Warning: Defined but not used: ‘imCast_Inh_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1452:29: Warning: Defined but not used: data constructor ‘Syn_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1452:51: Warning: Defined but not used: ‘annotatedTree_Syn_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1452:106: Warning: Defined but not used: ‘originalTree_Syn_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1456:1: Warning: Defined but not used: ‘wrap_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1832:33: Warning: Defined but not used: data constructor ‘Inh_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1832:59: Warning: Defined but not used: ‘cat_Inh_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1832:99: Warning: Defined but not used: ‘flags_Inh_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1832:151: Warning: Defined but not used: ‘imCast_Inh_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1833:33: Warning: Defined but not used: data constructor ‘Syn_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1833:59: Warning: Defined but not used: ‘annotatedTree_Syn_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1833:122: Warning: Defined but not used: ‘originalTree_Syn_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1837:1: Warning: Defined but not used: ‘wrap_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2005:32: Warning: Defined but not used: data constructor ‘Inh_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2005:57: Warning: Defined but not used: ‘cat_Inh_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2005:96: Warning: Defined but not used: ‘flags_Inh_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2005:147: Warning: Defined but not used: ‘imCast_Inh_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2006:32: Warning: Defined but not used: data constructor ‘Syn_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2006:57: Warning: Defined but not used: ‘annotatedTree_Syn_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2006:118: Warning: Defined but not used: ‘originalTree_Syn_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2010:1: Warning: Defined but not used: ‘wrap_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2320:23: Warning: Defined but not used: data constructor ‘Inh_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2320:39: Warning: Defined but not used: ‘cat_Inh_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2320:69: Warning: Defined but not used: ‘flags_Inh_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2320:111: Warning: Defined but not used: ‘imCast_Inh_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2320:154: Warning: Defined but not used: ‘tpe_Inh_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2321:23: Warning: Defined but not used: data constructor ‘Syn_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2321:39: Warning: Defined but not used: ‘annotatedTree_Syn_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2321:82: Warning: Defined but not used: ‘originalTree_Syn_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2325:1: Warning: Defined but not used: ‘wrap_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2385:25: Warning: Defined but not used: data constructor ‘Inh_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2385:43: Warning: Defined but not used: ‘cat_Inh_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2385:75: Warning: Defined but not used: ‘flags_Inh_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2385:119: Warning: Defined but not used: ‘imCast_Inh_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2386:25: Warning: Defined but not used: data constructor ‘Syn_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2386:43: Warning: Defined but not used: ‘annotatedTree_Syn_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2386:90: Warning: Defined but not used: ‘originalTree_Syn_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2390:1: Warning: Defined but not used: ‘wrap_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2593:29: Warning: Defined but not used: data constructor ‘Inh_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2593:51: Warning: Defined but not used: ‘cat_Inh_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2593:87: Warning: Defined but not used: ‘flags_Inh_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2593:135: Warning: Defined but not used: ‘imCast_Inh_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2594:29: Warning: Defined but not used: data constructor ‘Syn_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2594:51: Warning: Defined but not used: ‘annotatedTree_Syn_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2594:106: Warning: Defined but not used: ‘originalTree_Syn_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2598:1: Warning: Defined but not used: ‘wrap_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2755:45: Warning: Defined but not used: data constructor ‘Inh_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2755:83: Warning: Defined but not used: ‘cat_Inh_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2755:135: Warning: Defined but not used: ‘downEnv_Inh_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2755:195: Warning: Defined but not used: ‘flags_Inh_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2755:259: Warning: Defined but not used: ‘imCast_Inh_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2755:324: Warning: Defined but not used: ‘thenExpectedType_Inh_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2755:399: Warning: Defined but not used: ‘whenExpectedType_Inh_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2756:45: Warning: Defined but not used: data constructor ‘Syn_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2756:83: Warning: Defined but not used: ‘annotatedTree_Syn_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2756:170: Warning: Defined but not used: ‘originalTree_Syn_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2756:256: Warning: Defined but not used: ‘thenType_Syn_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2756:323: Warning: Defined but not used: ‘upTypes_Syn_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2756:391: Warning: Defined but not used: ‘whenTypes_Syn_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2760:1: Warning: Defined but not used: ‘wrap_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2958:49: Warning: Defined but not used: data constructor ‘Inh_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2958:91: Warning: Defined but not used: ‘cat_Inh_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2958:147: Warning: Defined but not used: ‘downEnv_Inh_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2958:211: Warning: Defined but not used: ‘flags_Inh_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2958:279: Warning: Defined but not used: ‘imCast_Inh_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2958:348: Warning: Defined but not used: ‘thenExpectedType_Inh_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2958:427: Warning: Defined but not used: ‘whenExpectedType_Inh_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2959:49: Warning: Defined but not used: data constructor ‘Syn_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2959:91: Warning: Defined but not used: ‘annotatedTree_Syn_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2959:186: Warning: Defined but not used: ‘originalTree_Syn_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2959:280: Warning: Defined but not used: ‘thenTypes_Syn_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2959:354: Warning: Defined but not used: ‘upTypes_Syn_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2959:426: Warning: Defined but not used: ‘whenTypes_Syn_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2963:1: Warning: Defined but not used: ‘wrap_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3243:23: Warning: Defined but not used: data constructor ‘Inh_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3243:39: Warning: Defined but not used: ‘cat_Inh_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3243:69: Warning: Defined but not used: ‘flags_Inh_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3243:111: Warning: Defined but not used: ‘imCast_Inh_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3244:23: Warning: Defined but not used: data constructor ‘Syn_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3244:39: Warning: Defined but not used: ‘annotatedTree_Syn_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3244:82: Warning: Defined but not used: ‘originalTree_Syn_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3248:1: Warning: Defined but not used: ‘wrap_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3636:27: Warning: Defined but not used: data constructor ‘Inh_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3636:47: Warning: Defined but not used: ‘cat_Inh_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3636:81: Warning: Defined but not used: ‘flags_Inh_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3636:127: Warning: Defined but not used: ‘imCast_Inh_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3637:27: Warning: Defined but not used: data constructor ‘Syn_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3637:47: Warning: Defined but not used: ‘annotatedTree_Syn_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3637:98: Warning: Defined but not used: ‘originalTree_Syn_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3641:1: Warning: Defined but not used: ‘wrap_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3799:19: Warning: Defined but not used: data constructor ‘Inh_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3799:31: Warning: Defined but not used: ‘cat_Inh_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3799:57: Warning: Defined but not used: ‘flags_Inh_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3799:95: Warning: Defined but not used: ‘imCast_Inh_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3800:19: Warning: Defined but not used: data constructor ‘Syn_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3800:31: Warning: Defined but not used: ‘annotatedTree_Syn_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3800:66: Warning: Defined but not used: ‘originalTree_Syn_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3804:1: Warning: Defined but not used: ‘wrap_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4037:19: Warning: Defined but not used: data constructor ‘Inh_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4037:31: Warning: Defined but not used: ‘cat_Inh_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4037:57: Warning: Defined but not used: ‘downEnv_Inh_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4037:91: Warning: Defined but not used: ‘expectedCast_Inh_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4037:123: Warning: Defined but not used: ‘expectedType_Inh_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4037:168: Warning: Defined but not used: ‘flags_Inh_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4037:206: Warning: Defined but not used: ‘imCast_Inh_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4038:19: Warning: Defined but not used: data constructor ‘Syn_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4038:31: Warning: Defined but not used: ‘annotatedTree_Syn_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4038:66: Warning: Defined but not used: ‘listType_Syn_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4038:120: Warning: Defined but not used: ‘originalTree_Syn_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4042:1: Warning: Defined but not used: ‘wrap_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4347:21: Warning: Defined but not used: data constructor ‘Inh_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4347:35: Warning: Defined but not used: ‘cat_Inh_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4347:63: Warning: Defined but not used: ‘downEnv_Inh_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4347:99: Warning: Defined but not used: ‘flags_Inh_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4347:139: Warning: Defined but not used: ‘imCast_Inh_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4348:21: Warning: Defined but not used: data constructor ‘Syn_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4348:35: Warning: Defined but not used: ‘annotatedTree_Syn_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4348:74: Warning: Defined but not used: ‘originalTree_Syn_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4352:1: Warning: Defined but not used: ‘wrap_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4586:26: Warning: Defined but not used: data constructor ‘Inh_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4586:45: Warning: Defined but not used: ‘cat_Inh_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4586:78: Warning: Defined but not used: ‘downEnv_Inh_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4586:119: Warning: Defined but not used: ‘flags_Inh_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4586:164: Warning: Defined but not used: ‘imCast_Inh_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4587:26: Warning: Defined but not used: data constructor ‘Syn_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4587:45: Warning: Defined but not used: ‘annotatedTree_Syn_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4587:94: Warning: Defined but not used: ‘originalTree_Syn_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4591:1: Warning: Defined but not used: ‘wrap_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4720:1: Warning: Defined but not used: ‘sem_MaybeNameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4726:35: Warning: Defined but not used: data constructor ‘Inh_MaybeNameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4727:35: Warning: Defined but not used: data constructor ‘Syn_MaybeNameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4731:1: Warning: Defined but not used: ‘wrap_MaybeNameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4732:10: Warning: This pattern-binding binds no variables: () = sem hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4736:1: Warning: Defined but not used: ‘sem_MaybeNameComponentList_Just’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4736:33: Warning: Defined but not used: ‘just_’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4740:1: Warning: Defined but not used: ‘sem_MaybeNameComponentList_Nothing’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4784:28: Warning: Defined but not used: data constructor ‘Inh_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4784:49: Warning: Defined but not used: ‘cat_Inh_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4784:84: Warning: Defined but not used: ‘downEnv_Inh_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4784:127: Warning: Defined but not used: ‘expectedCast_Inh_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4784:168: Warning: Defined but not used: ‘expectedType_Inh_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4784:222: Warning: Defined but not used: ‘flags_Inh_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4784:269: Warning: Defined but not used: ‘imCast_Inh_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4785:28: Warning: Defined but not used: data constructor ‘Syn_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4785:49: Warning: Defined but not used: ‘annotatedTree_Syn_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4785:102: Warning: Defined but not used: ‘originalTree_Syn_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4785:154: Warning: Defined but not used: ‘upType_Syn_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4789:1: Warning: Defined but not used: ‘wrap_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4959:28: Warning: Defined but not used: data constructor ‘Inh_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4959:49: Warning: Defined but not used: ‘cat_Inh_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4959:84: Warning: Defined but not used: ‘flags_Inh_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4959:131: Warning: Defined but not used: ‘imCast_Inh_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4960:28: Warning: Defined but not used: data constructor ‘Syn_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4960:49: Warning: Defined but not used: ‘annotatedTree_Syn_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4960:102: Warning: Defined but not used: ‘originalTree_Syn_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4964:1: Warning: Defined but not used: ‘wrap_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5115:35: Warning: Defined but not used: data constructor ‘Inh_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5115:63: Warning: Defined but not used: ‘cat_Inh_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5115:105: Warning: Defined but not used: ‘flags_Inh_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5115:159: Warning: Defined but not used: ‘imCast_Inh_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5116:35: Warning: Defined but not used: data constructor ‘Syn_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5116:63: Warning: Defined but not used: ‘annotatedTree_Syn_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5116:130: Warning: Defined but not used: ‘originalTree_Syn_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5120:1: Warning: Defined but not used: ‘wrap_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5253:17: Warning: Defined but not used: data constructor ‘Inh_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5253:27: Warning: Defined but not used: ‘cat_Inh_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5253:51: Warning: Defined but not used: ‘flags_Inh_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5253:87: Warning: Defined but not used: ‘imCast_Inh_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5253:124: Warning: Defined but not used: ‘tpe_Inh_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5254:17: Warning: Defined but not used: data constructor ‘Syn_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5254:27: Warning: Defined but not used: ‘annotatedTree_Syn_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5254:58: Warning: Defined but not used: ‘originalTree_Syn_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5258:1: Warning: Defined but not used: ‘wrap_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5374:1: Warning: Defined but not used: ‘sem_NameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5378:30: Warning: Defined but not used: data constructor ‘Inh_NameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5379:30: Warning: Defined but not used: data constructor ‘Syn_NameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5383:1: Warning: Defined but not used: ‘wrap_NameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5384:10: Warning: This pattern-binding binds no variables: () = sem hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5389:1: Warning: Defined but not used: ‘sem_NameComponentList_Cons’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5389:28: Warning: Defined but not used: ‘hd_’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5389:32: Warning: Defined but not used: ‘tl_’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5393:1: Warning: Defined but not used: ‘sem_NameComponentList_Nil’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5425:33: Warning: Defined but not used: data constructor ‘Inh_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5425:59: Warning: Defined but not used: ‘cat_Inh_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5425:99: Warning: Defined but not used: ‘flags_Inh_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5425:151: Warning: Defined but not used: ‘imCast_Inh_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5426:33: Warning: Defined but not used: data constructor ‘Syn_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5426:59: Warning: Defined but not used: ‘annotatedTree_Syn_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5426:122: Warning: Defined but not used: ‘originalTree_Syn_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5430:1: Warning: Defined but not used: ‘wrap_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5557:37: Warning: Defined but not used: data constructor ‘Inh_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5557:67: Warning: Defined but not used: ‘cat_Inh_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5557:111: Warning: Defined but not used: ‘flags_Inh_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5557:167: Warning: Defined but not used: ‘imCast_Inh_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5558:37: Warning: Defined but not used: data constructor ‘Syn_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5558:67: Warning: Defined but not used: ‘annotatedTree_Syn_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5558:138: Warning: Defined but not used: ‘originalTree_Syn_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5562:1: Warning: Defined but not used: ‘wrap_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5717:19: Warning: Defined but not used: data constructor ‘Inh_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5717:31: Warning: Defined but not used: ‘cat_Inh_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5717:57: Warning: Defined but not used: ‘downEnv_Inh_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5717:91: Warning: Defined but not used: ‘flags_Inh_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5717:129: Warning: Defined but not used: ‘imCast_Inh_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5718:19: Warning: Defined but not used: data constructor ‘Syn_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5718:31: Warning: Defined but not used: ‘annotatedTree_Syn_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5718:66: Warning: Defined but not used: ‘originalTree_Syn_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5722:1: Warning: Defined but not used: ‘wrap_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5864:21: Warning: Defined but not used: data constructor ‘Inh_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5864:35: Warning: Defined but not used: ‘cat_Inh_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5864:63: Warning: Defined but not used: ‘flags_Inh_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5864:103: Warning: Defined but not used: ‘imCast_Inh_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5865:21: Warning: Defined but not used: data constructor ‘Syn_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5865:35: Warning: Defined but not used: ‘annotatedTree_Syn_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5865:74: Warning: Defined but not used: ‘originalTree_Syn_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5869:1: Warning: Defined but not used: ‘wrap_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6090:25: Warning: Defined but not used: data constructor ‘Inh_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6090:43: Warning: Defined but not used: ‘cat_Inh_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6090:75: Warning: Defined but not used: ‘flags_Inh_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6090:119: Warning: Defined but not used: ‘imCast_Inh_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6091:25: Warning: Defined but not used: data constructor ‘Syn_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6091:43: Warning: Defined but not used: ‘annotatedTree_Syn_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6091:90: Warning: Defined but not used: ‘originalTree_Syn_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6095:1: Warning: Defined but not used: ‘wrap_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6324:22: Warning: Defined but not used: data constructor ‘Inh_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6324:37: Warning: Defined but not used: ‘cat_Inh_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6324:66: Warning: Defined but not used: ‘expectedType_Inh_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6324:116: Warning: Defined but not used: ‘flags_Inh_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6324:157: Warning: Defined but not used: ‘imCast_Inh_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6324:199: Warning: Defined but not used: ‘outerDownEnv_Inh_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6325:22: Warning: Defined but not used: data constructor ‘Syn_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6325:37: Warning: Defined but not used: ‘annotatedTree_Syn_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6325:78: Warning: Defined but not used: ‘originalTree_Syn_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6325:118: Warning: Defined but not used: ‘upType_Syn_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6329:1: Warning: Defined but not used: ‘wrap_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7235:58: Warning: Defined but not used: ‘originalTree_Syn_Root’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7389:26: Warning: Defined but not used: data constructor ‘Inh_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7389:45: Warning: Defined but not used: ‘cat_Inh_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7389:78: Warning: Defined but not used: ‘flags_Inh_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7389:123: Warning: Defined but not used: ‘imCast_Inh_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7390:26: Warning: Defined but not used: data constructor ‘Syn_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7390:45: Warning: Defined but not used: ‘annotatedTree_Syn_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7390:94: Warning: Defined but not used: ‘originalTree_Syn_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7394:1: Warning: Defined but not used: ‘wrap_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7978:30: Warning: Defined but not used: data constructor ‘Inh_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7978:53: Warning: Defined but not used: ‘cat_Inh_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7978:90: Warning: Defined but not used: ‘flags_Inh_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7978:139: Warning: Defined but not used: ‘imCast_Inh_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7979:30: Warning: Defined but not used: data constructor ‘Syn_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7979:53: Warning: Defined but not used: ‘annotatedTree_Syn_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7979:110: Warning: Defined but not used: ‘originalTree_Syn_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7983:1: Warning: Defined but not used: ‘wrap_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8482:23: Warning: Defined but not used: data constructor ‘Inh_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8482:39: Warning: Defined but not used: ‘cat_Inh_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8482:69: Warning: Defined but not used: ‘downEnv_Inh_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8482:107: Warning: Defined but not used: ‘expectedCast_Inh_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8482:143: Warning: Defined but not used: ‘expectedType_Inh_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8482:192: Warning: Defined but not used: ‘flags_Inh_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8482:234: Warning: Defined but not used: ‘imCast_Inh_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8483:23: Warning: Defined but not used: data constructor ‘Syn_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8483:39: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8483:82: Warning: Defined but not used: ‘colExprs_Syn_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8483:156: Warning: Defined but not used: ‘originalTree_Syn_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8483:198: Warning: Defined but not used: ‘upType_Syn_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8487:1: Warning: Defined but not used: ‘wrap_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13383:36: Warning: Defined but not used: data constructor ‘Inh_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13383:65: Warning: Defined but not used: ‘cat_Inh_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13383:108: Warning: Defined but not used: ‘downEnv_Inh_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13383:159: Warning: Defined but not used: ‘flags_Inh_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13383:214: Warning: Defined but not used: ‘imCast_Inh_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13384:36: Warning: Defined but not used: data constructor ‘Syn_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13384:65: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13384:134: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13388:1: Warning: Defined but not used: ‘wrap_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13509:40: Warning: Defined but not used: data constructor ‘Inh_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13509:73: Warning: Defined but not used: ‘cat_Inh_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13509:120: Warning: Defined but not used: ‘downEnv_Inh_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13509:175: Warning: Defined but not used: ‘flags_Inh_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13509:234: Warning: Defined but not used: ‘imCast_Inh_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13510:40: Warning: Defined but not used: data constructor ‘Syn_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13510:73: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13510:150: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13514:1: Warning: Defined but not used: ‘wrap_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13689:27: Warning: Defined but not used: data constructor ‘Inh_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13689:47: Warning: Defined but not used: ‘cat_Inh_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13689:81: Warning: Defined but not used: ‘downEnv_Inh_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13689:123: Warning: Defined but not used: ‘expectedCast_Inh_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13689:163: Warning: Defined but not used: ‘expectedTypes_Inh_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13689:213: Warning: Defined but not used: ‘flags_Inh_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13689:259: Warning: Defined but not used: ‘imCast_Inh_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13690:27: Warning: Defined but not used: data constructor ‘Syn_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13690:47: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13690:98: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13690:148: Warning: Defined but not used: ‘upTypes_Syn_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13694:1: Warning: Defined but not used: ‘wrap_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13914:31: Warning: Defined but not used: data constructor ‘Inh_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13914:55: Warning: Defined but not used: ‘cat_Inh_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13914:93: Warning: Defined but not used: ‘downEnv_Inh_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13914:139: Warning: Defined but not used: ‘expectedCast_Inh_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13914:183: Warning: Defined but not used: ‘expectedType_Inh_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13914:242: Warning: Defined but not used: ‘flags_Inh_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13914:292: Warning: Defined but not used: ‘imCast_Inh_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13915:31: Warning: Defined but not used: data constructor ‘Syn_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13915:55: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13915:114: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13915:172: Warning: Defined but not used: ‘upType_Syn_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13919:1: Warning: Defined but not used: ‘wrap_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14139:44: Warning: Defined but not used: data constructor ‘Inh_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14139:81: Warning: Defined but not used: ‘cat_Inh_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14139:132: Warning: Defined but not used: ‘flags_Inh_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14139:195: Warning: Defined but not used: ‘imCast_Inh_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14140:44: Warning: Defined but not used: data constructor ‘Syn_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14140:81: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14140:166: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14144:1: Warning: Defined but not used: ‘wrap_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14286:48: Warning: Defined but not used: data constructor ‘Inh_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14286:89: Warning: Defined but not used: ‘cat_Inh_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14286:144: Warning: Defined but not used: ‘flags_Inh_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14286:211: Warning: Defined but not used: ‘imCast_Inh_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14287:48: Warning: Defined but not used: data constructor ‘Syn_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14287:89: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14287:182: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14291:1: Warning: Defined but not used: ‘wrap_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14440:98: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprRoot’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14557:40: Warning: Defined but not used: data constructor ‘Inh_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14557:73: Warning: Defined but not used: ‘cat_Inh_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14557:120: Warning: Defined but not used: ‘flags_Inh_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14557:179: Warning: Defined but not used: ‘imCast_Inh_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14558:40: Warning: Defined but not used: data constructor ‘Syn_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14558:73: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14558:150: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14562:1: Warning: Defined but not used: ‘wrap_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14705:44: Warning: Defined but not used: data constructor ‘Inh_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14705:81: Warning: Defined but not used: ‘cat_Inh_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14705:132: Warning: Defined but not used: ‘flags_Inh_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14705:195: Warning: Defined but not used: ‘imCast_Inh_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14706:44: Warning: Defined but not used: data constructor ‘Syn_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14706:81: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14706:166: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14710:1: Warning: Defined but not used: ‘wrap_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14867:37: Warning: Defined but not used: data constructor ‘Inh_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14867:67: Warning: Defined but not used: ‘cat_Inh_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14867:111: Warning: Defined but not used: ‘expectedCast_Inh_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14867:161: Warning: Defined but not used: ‘expectedType_Inh_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14867:226: Warning: Defined but not used: ‘flags_Inh_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14867:282: Warning: Defined but not used: ‘imCast_Inh_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14868:37: Warning: Defined but not used: data constructor ‘Syn_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14868:67: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14868:138: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14868:208: Warning: Defined but not used: ‘upType_Syn_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14872:1: Warning: Defined but not used: ‘wrap_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15094:23: Warning: Defined but not used: data constructor ‘Inh_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15094:39: Warning: Defined but not used: ‘cat_Inh_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15094:69: Warning: Defined but not used: ‘downEnv_Inh_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15094:107: Warning: Defined but not used: ‘expectedCast_Inh_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15094:143: Warning: Defined but not used: ‘expectedType_Inh_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15094:192: Warning: Defined but not used: ‘flags_Inh_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15094:234: Warning: Defined but not used: ‘imCast_Inh_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15095:23: Warning: Defined but not used: data constructor ‘Syn_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15095:39: Warning: Defined but not used: ‘annotatedTree_Syn_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15095:82: Warning: Defined but not used: ‘colExprs_Syn_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15095:156: Warning: Defined but not used: ‘originalTree_Syn_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15099:1: Warning: Defined but not used: ‘wrap_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15403:27: Warning: Defined but not used: data constructor ‘Inh_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15403:47: Warning: Defined but not used: ‘cat_Inh_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15403:81: Warning: Defined but not used: ‘downEnv_Inh_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15403:123: Warning: Defined but not used: ‘expectedCast_Inh_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15403:163: Warning: Defined but not used: ‘expectedType_Inh_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15403:218: Warning: Defined but not used: ‘flags_Inh_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15403:264: Warning: Defined but not used: ‘imCast_Inh_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15404:27: Warning: Defined but not used: data constructor ‘Syn_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15404:47: Warning: Defined but not used: ‘annotatedTree_Syn_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15404:98: Warning: Defined but not used: ‘colExprs_Syn_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15404:176: Warning: Defined but not used: ‘originalTree_Syn_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15404:226: Warning: Defined but not used: ‘upEnv_Syn_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15404:266: Warning: Defined but not used: ‘upType_Syn_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15408:1: Warning: Defined but not used: ‘wrap_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15688:23: Warning: Defined but not used: data constructor ‘Inh_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15688:39: Warning: Defined but not used: ‘cat_Inh_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15688:69: Warning: Defined but not used: ‘downEnv_Inh_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15688:107: Warning: Defined but not used: ‘expectedCast_Inh_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15688:143: Warning: Defined but not used: ‘expectedType_Inh_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15688:194: Warning: Defined but not used: ‘flags_Inh_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15688:236: Warning: Defined but not used: ‘imCast_Inh_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15689:23: Warning: Defined but not used: data constructor ‘Syn_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15689:39: Warning: Defined but not used: ‘annotatedTree_Syn_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15689:82: Warning: Defined but not used: ‘colExprs_Syn_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15689:156: Warning: Defined but not used: ‘originalTree_Syn_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15689:198: Warning: Defined but not used: ‘upEnv_Syn_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15689:234: Warning: Defined but not used: ‘upType_Syn_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15693:1: Warning: Defined but not used: ‘wrap_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15876:22: Warning: Defined but not used: data constructor ‘Inh_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15876:37: Warning: Defined but not used: ‘cat_Inh_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15876:66: Warning: Defined but not used: ‘flags_Inh_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15876:107: Warning: Defined but not used: ‘imCast_Inh_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15877:22: Warning: Defined but not used: data constructor ‘Syn_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15877:37: Warning: Defined but not used: ‘annotatedTree_Syn_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15877:78: Warning: Defined but not used: ‘originalTree_Syn_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15881:1: Warning: Defined but not used: ‘wrap_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16147:26: Warning: Defined but not used: data constructor ‘Inh_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16147:45: Warning: Defined but not used: ‘cat_Inh_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16147:78: Warning: Defined but not used: ‘flags_Inh_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16147:123: Warning: Defined but not used: ‘imCast_Inh_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16148:26: Warning: Defined but not used: data constructor ‘Syn_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16148:45: Warning: Defined but not used: ‘annotatedTree_Syn_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16148:94: Warning: Defined but not used: ‘originalTree_Syn_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16152:1: Warning: Defined but not used: ‘wrap_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16862:22: Warning: Defined but not used: data constructor ‘Inh_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16862:37: Warning: Defined but not used: ‘cat_Inh_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16862:66: Warning: Defined but not used: ‘flags_Inh_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16862:107: Warning: Defined but not used: ‘imCast_Inh_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16863:22: Warning: Defined but not used: data constructor ‘Syn_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16863:37: Warning: Defined but not used: ‘annotatedTree_Syn_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16863:78: Warning: Defined but not used: ‘originalTree_Syn_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16867:1: Warning: Defined but not used: ‘wrap_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23092:26: Warning: Defined but not used: data constructor ‘Inh_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23092:45: Warning: Defined but not used: ‘cat_Inh_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23092:78: Warning: Defined but not used: ‘flags_Inh_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23092:123: Warning: Defined but not used: ‘imCast_Inh_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23093:26: Warning: Defined but not used: data constructor ‘Syn_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23093:45: Warning: Defined but not used: ‘annotatedTree_Syn_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23093:94: Warning: Defined but not used: ‘originalTree_Syn_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23097:1: Warning: Defined but not used: ‘wrap_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23248:30: Warning: Defined but not used: data constructor ‘Inh_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23248:53: Warning: Defined but not used: ‘cat_Inh_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23248:90: Warning: Defined but not used: ‘flags_Inh_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23248:139: Warning: Defined but not used: ‘imCast_Inh_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23249:30: Warning: Defined but not used: data constructor ‘Syn_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23249:53: Warning: Defined but not used: ‘annotatedTree_Syn_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23249:110: Warning: Defined but not used: ‘originalTree_Syn_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23253:1: Warning: Defined but not used: ‘wrap_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23429:21: Warning: Defined but not used: data constructor ‘Inh_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23429:35: Warning: Defined but not used: ‘cat_Inh_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23429:63: Warning: Defined but not used: ‘flags_Inh_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23429:103: Warning: Defined but not used: ‘imCast_Inh_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23430:21: Warning: Defined but not used: data constructor ‘Syn_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23430:35: Warning: Defined but not used: ‘annotatedTree_Syn_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23430:74: Warning: Defined but not used: ‘originalTree_Syn_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23430:112: Warning: Defined but not used: ‘upEnv_Syn_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23434:1: Warning: Defined but not used: ‘wrap_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24450:25: Warning: Defined but not used: data constructor ‘Inh_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24450:43: Warning: Defined but not used: ‘cat_Inh_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24450:75: Warning: Defined but not used: ‘flags_Inh_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24450:119: Warning: Defined but not used: ‘imCast_Inh_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24451:25: Warning: Defined but not used: data constructor ‘Syn_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24451:43: Warning: Defined but not used: ‘annotatedTree_Syn_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24451:90: Warning: Defined but not used: ‘originalTree_Syn_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24451:136: Warning: Defined but not used: ‘upEnv_Syn_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24455:1: Warning: Defined but not used: ‘wrap_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24625:29: Warning: Defined but not used: data constructor ‘Inh_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24625:51: Warning: Defined but not used: ‘cat_Inh_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24625:87: Warning: Defined but not used: ‘flags_Inh_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24625:135: Warning: Defined but not used: ‘imCast_Inh_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24626:29: Warning: Defined but not used: data constructor ‘Syn_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24626:51: Warning: Defined but not used: ‘annotatedTree_Syn_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24626:106: Warning: Defined but not used: ‘originalTree_Syn_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24630:1: Warning: Defined but not used: ‘wrap_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24759:33: Warning: Defined but not used: data constructor ‘Inh_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24759:59: Warning: Defined but not used: ‘cat_Inh_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24759:99: Warning: Defined but not used: ‘flags_Inh_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24759:151: Warning: Defined but not used: ‘imCast_Inh_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24760:33: Warning: Defined but not used: data constructor ‘Syn_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24760:59: Warning: Defined but not used: ‘annotatedTree_Syn_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24760:122: Warning: Defined but not used: ‘originalTree_Syn_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24764:1: Warning: Defined but not used: ‘wrap_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24958:21: Warning: Defined but not used: data constructor ‘Inh_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24958:35: Warning: Defined but not used: ‘cat_Inh_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24958:63: Warning: Defined but not used: ‘flags_Inh_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24958:103: Warning: Defined but not used: ‘imCast_Inh_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24959:21: Warning: Defined but not used: data constructor ‘Syn_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24959:35: Warning: Defined but not used: ‘annotatedTree_Syn_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24959:74: Warning: Defined but not used: ‘namedType_Syn_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24959:118: Warning: Defined but not used: ‘originalTree_Syn_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24963:1: Warning: Defined but not used: ‘wrap_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25556:25: Warning: Defined but not used: data constructor ‘Inh_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25556:43: Warning: Defined but not used: ‘cat_Inh_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25556:75: Warning: Defined but not used: ‘flags_Inh_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25556:119: Warning: Defined but not used: ‘imCast_Inh_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25557:25: Warning: Defined but not used: data constructor ‘Syn_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25557:43: Warning: Defined but not used: ‘annotatedTree_Syn_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25557:90: Warning: Defined but not used: ‘originalTree_Syn_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25561:1: Warning: Defined but not used: ‘wrap_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25733:19: Warning: Defined but not used: data constructor ‘Inh_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25733:31: Warning: Defined but not used: ‘cat_Inh_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25733:57: Warning: Defined but not used: ‘flags_Inh_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25733:95: Warning: Defined but not used: ‘imCast_Inh_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25734:19: Warning: Defined but not used: data constructor ‘Syn_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25734:31: Warning: Defined but not used: ‘annotatedTree_Syn_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25734:66: Warning: Defined but not used: ‘originalTree_Syn_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25738:1: Warning: Defined but not used: ‘wrap_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26034:23: Warning: Defined but not used: data constructor ‘Inh_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26034:39: Warning: Defined but not used: ‘cat_Inh_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26034:69: Warning: Defined but not used: ‘flags_Inh_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26034:111: Warning: Defined but not used: ‘imCast_Inh_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26035:23: Warning: Defined but not used: data constructor ‘Syn_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26035:39: Warning: Defined but not used: ‘annotatedTree_Syn_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26035:82: Warning: Defined but not used: ‘originalTree_Syn_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26039:1: Warning: Defined but not used: ‘wrap_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26190:22: Warning: Defined but not used: data constructor ‘Inh_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26190:37: Warning: Defined but not used: ‘cat_Inh_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26190:66: Warning: Defined but not used: ‘flags_Inh_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26190:107: Warning: Defined but not used: ‘imCast_Inh_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26191:22: Warning: Defined but not used: data constructor ‘Syn_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26191:37: Warning: Defined but not used: ‘annotatedTree_Syn_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26191:78: Warning: Defined but not used: ‘originalTree_Syn_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26195:1: Warning: Defined but not used: ‘wrap_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26339:26: Warning: Defined but not used: data constructor ‘Inh_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26339:45: Warning: Defined but not used: ‘cat_Inh_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26339:78: Warning: Defined but not used: ‘flags_Inh_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26339:123: Warning: Defined but not used: ‘imCast_Inh_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26340:26: Warning: Defined but not used: data constructor ‘Syn_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26340:45: Warning: Defined but not used: ‘annotatedTree_Syn_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26340:94: Warning: Defined but not used: ‘originalTree_Syn_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26344:1: Warning: Defined but not used: ‘wrap_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/TypeChecking/TypeChecking.ag:75:38: Warning: Fields of ‘Inh_ScalarExprRoot’ not initialised: downEnv_Inh_ScalarExprRoot In the second argument of ‘wrap_ScalarExprRoot’, namely ‘Inh_ScalarExprRoot {cat_Inh_ScalarExprRoot = cat, flags_Inh_ScalarExprRoot = f}’ In the first argument of ‘annotatedTree_Syn_ScalarExprRoot’, namely ‘(wrap_ScalarExprRoot t (Inh_ScalarExprRoot {cat_Inh_ScalarExprRoot = cat, flags_Inh_ScalarExprRoot = f}))’ In the expression: (annotatedTree_Syn_ScalarExprRoot (wrap_ScalarExprRoot t (Inh_ScalarExprRoot {cat_Inh_ScalarExprRoot = cat, flags_Inh_ScalarExprRoot = f}))) hssqlppp/src/Database/HsSqlPpp/Internals/TypeChecking/TypeChecking.ag:260:1: Warning: Tab character hssqlppp/src/Database/HsSqlPpp/Internals/TypeChecking/TypeChecking.ag:261:1: Warning: Tab character hssqlppp/src/Database/HsSqlPpp/Internals/TypeChecking/TypeChecking.ag:262:1: Warning: Tab character hssqlppp/src/Database/HsSqlPpp/Internals/TypeChecking/TypeChecking.ag:268:1: Warning: Tab character hssqlppp/src/Database/HsSqlPpp/Internals/TypeChecking/TypeChecking.ag:269:1: Warning: Tab character hssqlppp/src/Database/HsSqlPpp/Internals/TypeChecking/TypeChecking.ag:270:1: Warning: Tab character src/Database/HsSqlPpp/Internals/AstInternal.hs:119:1: Warning: The import of ‘Control.Applicative’ is redundant except perhaps to import instances from ‘Control.Applicative’ To import instances alone, use: import Control.Applicative() [17 of 23] Compiling Database.HsSqlPpp.Annotation ( src/Database/HsSqlPpp/Annotation.lhs, dist/build/Database/HsSqlPpp/Annotation.o ) [18 of 23] Compiling Database.HsSqlPpp.TypeChecker ( src/Database/HsSqlPpp/TypeChecker.lhs, dist/build/Database/HsSqlPpp/TypeChecker.o ) [19 of 23] Compiling Database.HsSqlPpp.Ast ( src/Database/HsSqlPpp/Ast.lhs, dist/build/Database/HsSqlPpp/Ast.o ) [20 of 23] Compiling Database.HsSqlPpp.Parsing.ParserInternal ( src/Database/HsSqlPpp/Parsing/ParserInternal.lhs, dist/build/Database/HsSqlPpp/Parsing/ParserInternal.o ) src/Database/HsSqlPpp/Parsing/ParserInternal.lhs:38:3: Warning: The import of ‘Control.Applicative’ is redundant except perhaps to import instances from ‘Control.Applicative’ To import instances alone, use: import Control.Applicative() [21 of 23] Compiling Database.HsSqlPpp.Parser ( src/Database/HsSqlPpp/Parser.lhs, dist/build/Database/HsSqlPpp/Parser.o ) [22 of 23] Compiling Database.HsSqlPpp.Utility ( src/Database/HsSqlPpp/Utility.lhs, dist/build/Database/HsSqlPpp/Utility.o ) [23 of 23] Compiling Database.HsSqlPpp.Pretty ( src/Database/HsSqlPpp/Pretty.lhs, dist/build/Database/HsSqlPpp/Pretty.o ) src/Database/HsSqlPpp/Pretty.lhs:103:3: Warning: Pattern match(es) are non-exhaustive In an equation for ‘statement’: Patterns not matched: _ _ _ (CreateUser _ _ _) _ _ _ (CreateLogin _ _ _) _ _ _ (AlterUser _ _ _) _ _ _ (AlterLogin _ _ _) src/Database/HsSqlPpp/Pretty.lhs:781:31: Warning: Pattern match(es) are overlapped In a case alternative: _ -> ... In-place registering hssqlppp-0.5.18... real 1m20.449s user 2m5.040s sys 0m48.504s jake at debian:~/wd/hssqlppp/trunk/hssqlppp$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150612 jake at debian:~/wd/hssqlppp/trunk/hssqlppp$ cabal clean cleaning... jake at debian:~/wd/hssqlppp/trunk/hssqlppp$ cabal sandbox delete Deleting the sandbox located at /home/jake/wd/hssqlppp/trunk/hssqlppp/.cabal-sandbox jake at debian:~/wd/hssqlppp/trunk/hssqlppp$ cabal sandbox init Writing a default package environment file to /home/jake/wd/hssqlppp/trunk/hssqlppp/cabal.sandbox.config Creating a new sandbox at /home/jake/wd/hssqlppp/trunk/hssqlppp/.cabal- sandbox jake at debian:~/wd/hssqlppp/trunk/hssqlppp$ time cabal install happy Resolving dependencies... Notice: installing into a sandbox located at /home/jake/wd/hssqlppp/trunk/hssqlppp/.cabal-sandbox Configuring mtl-2.2.1... Building mtl-2.2.1... Installed mtl-2.2.1 Configuring happy-1.19.5... Building happy-1.19.5... Installed happy-1.19.5 real 0m17.994s user 0m16.496s sys 0m0.852s jake at debian:~/wd/hssqlppp/trunk/hssqlppp$ time cabal install --only- dependencies Resolving dependencies... Notice: installing into a sandbox located at /home/jake/wd/hssqlppp/trunk/hssqlppp/.cabal-sandbox Configuring old-locale-1.0.0.7... Configuring syb-0.4.4... Configuring text-1.2.1.1... Building syb-0.4.4... Building old-locale-1.0.0.7... Building text-1.2.1.1... Installed old-locale-1.0.0.7 Configuring old-time-1.1.0.3... Building old-time-1.1.0.3... Installed syb-0.4.4 Installed old-time-1.1.0.3 Installed text-1.2.1.1 Configuring hashable-1.2.3.2... Configuring parsec-3.1.9... Configuring polyparse-1.11... Building parsec-3.1.9... Building hashable-1.2.3.2... Building polyparse-1.11... Installed hashable-1.2.3.2 Configuring scientific-0.3.3.8... Configuring unordered-containers-0.2.5.1... Building scientific-0.3.3.8... Building unordered-containers-0.2.5.1... Installed scientific-0.3.3.8 Configuring attoparsec-0.12.1.6... Installed parsec-3.1.9 Building attoparsec-0.12.1.6... Installed polyparse-1.11 Configuring cpphs-1.19... Installed unordered-containers-0.2.5.1 Configuring uniplate-1.6.12... Building cpphs-1.19... Building uniplate-1.6.12... Installed cpphs-1.19 Configuring haskell-src-exts-1.16.0.1... Installed uniplate-1.6.12 Building haskell-src-exts-1.16.0.1... Installed attoparsec-0.12.1.6 Installed haskell-src-exts-1.16.0.1 Configuring groom-0.1.2... Building groom-0.1.2... Installed groom-0.1.2 real 4m42.127s user 5m45.548s sys 0m5.040s jake at debian:~/wd/hssqlppp/trunk/hssqlppp$ time cabal build Package has never been configured. Configuring with default flags. If this fails, please run configure manually. Resolving dependencies... Configuring hssqlppp-0.5.18... Building hssqlppp-0.5.18... Preprocessing library hssqlppp-0.5.18... [ 1 of 23] Compiling Database.HsSqlPpp.Parsing.ParseErrors ( src/Database/HsSqlPpp/Parsing/ParseErrors.lhs, dist/build/Database/HsSqlPpp/Parsing/ParseErrors.o ) [ 2 of 23] Compiling Database.HsSqlPpp.Utils.Utils ( src/Database/HsSqlPpp/Utils/Utils.lhs, dist/build/Database/HsSqlPpp/Utils/Utils.o ) src/Database/HsSqlPpp/Utils/Utils.lhs:9:3: Warning: The import of ‘Control.Applicative’ is redundant except perhaps to import instances from ‘Control.Applicative’ To import instances alone, use: import Control.Applicative() [ 3 of 23] Compiling Database.HsSqlPpp.Internals.TypesInternal ( src/Database/HsSqlPpp/Internals/TypesInternal.lhs, dist/build/Database/HsSqlPpp/Internals/TypesInternal.o ) [ 4 of 23] Compiling Database.HsSqlPpp.Types ( src/Database/HsSqlPpp/Types.lhs, dist/build/Database/HsSqlPpp/Types.o ) [ 5 of 23] Compiling Database.HsSqlPpp.Internals.TypeChecking.OldTediousTypeUtils ( src/Database/HsSqlPpp/Internals/TypeChecking/OldTediousTypeUtils.lhs, dist/build/Database/HsSqlPpp/Internals/TypeChecking/OldTediousTypeUtils.o ) [ 6 of 23] Compiling Database.HsSqlPpp.SqlDialect ( src/Database/HsSqlPpp/SqlDialect.lhs, dist/build/Database/HsSqlPpp/SqlDialect.o ) [ 7 of 23] Compiling Database.HsSqlPpp.LexicalSyntax ( src/Database/HsSqlPpp/LexicalSyntax.lhs, dist/build/Database/HsSqlPpp/LexicalSyntax.o ) [ 8 of 23] Compiling Database.HsSqlPpp.Internals.Catalog.CatalogInternal ( src/Database/HsSqlPpp/Internals/Catalog/CatalogInternal.lhs, dist/build/Database/HsSqlPpp/Internals/Catalog/CatalogInternal.o ) [ 9 of 23] Compiling Database.HsSqlPpp.Internals.Catalog.DefaultTemplate1Catalog ( src/Database/HsSqlPpp/Internals/Catalog/DefaultTemplate1Catalog.lhs, dist/build/Database/HsSqlPpp/Internals/Catalog/DefaultTemplate1Catalog.o ) [10 of 23] Compiling Database.HsSqlPpp.Internals.Catalog.DefaultTSQLCatalog ( src/Database/HsSqlPpp/Internals/Catalog/DefaultTSQLCatalog.lhs, dist/build/Database/HsSqlPpp/Internals/Catalog/DefaultTSQLCatalog.o ) [11 of 23] Compiling Database.HsSqlPpp.Internals.TypeChecking.OldTypeConversion ( src/Database/HsSqlPpp/Internals/TypeChecking/OldTypeConversion.lhs, dist/build/Database/HsSqlPpp/Internals/TypeChecking/OldTypeConversion.o ) [12 of 23] Compiling Database.HsSqlPpp.Internals.TypeChecking.SqlTypeConversion ( src/Database/HsSqlPpp/Internals/TypeChecking/SqlTypeConversion.lhs, dist/build/Database/HsSqlPpp/Internals/TypeChecking/SqlTypeConversion.o ) [13 of 23] Compiling Database.HsSqlPpp.Internals.TypeChecking.TypeConversion ( src/Database/HsSqlPpp/Internals/TypeChecking/TypeConversion.lhs, dist/build/Database/HsSqlPpp/Internals/TypeChecking/TypeConversion.o ) src/Database/HsSqlPpp/Internals/TypeChecking/TypeConversion.lhs:22:8: Warning: The export item ‘MatchAppLiteralList(..)’ suggests that ‘MatchAppLiteralList’ has (in-scope) constructors or class methods, but it has none src/Database/HsSqlPpp/Internals/TypeChecking/TypeConversion.lhs:34:3: Warning: The import of ‘Control.Applicative’ is redundant except perhaps to import instances from ‘Control.Applicative’ To import instances alone, use: import Control.Applicative() src/Database/HsSqlPpp/Internals/TypeChecking/TypeConversion.lhs:43:3: Warning: The import of ‘Debug.Trace’ is redundant except perhaps to import instances from ‘Debug.Trace’ To import instances alone, use: import Debug.Trace() [14 of 23] Compiling Database.HsSqlPpp.Internals.TypeChecking.Environment ( src/Database/HsSqlPpp/Internals/TypeChecking/Environment.lhs, dist/build/Database/HsSqlPpp/Internals/TypeChecking/Environment.o ) src/Database/HsSqlPpp/Internals/TypeChecking/Environment.lhs:228:41: Warning: Defined but not used: ‘j’ [15 of 23] Compiling Database.HsSqlPpp.Catalog ( src/Database/HsSqlPpp/Catalog.lhs, dist/build/Database/HsSqlPpp/Catalog.o ) [16 of 23] Compiling Database.HsSqlPpp.Internals.AstInternal ( src/Database/HsSqlPpp/Internals/AstInternal.hs, dist/build/Database/HsSqlPpp/Internals/AstInternal.o ) hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:848:30: Warning: Defined but not used: data constructor ‘Inh_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:848:53: Warning: Defined but not used: ‘cat_Inh_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:848:90: Warning: Defined but not used: ‘flags_Inh_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:848:139: Warning: Defined but not used: ‘imCast_Inh_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:849:30: Warning: Defined but not used: data constructor ‘Syn_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:849:53: Warning: Defined but not used: ‘annotatedTree_Syn_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:849:110: Warning: Defined but not used: ‘originalTree_Syn_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:853:1: Warning: Defined but not used: ‘wrap_AlterColumnAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1287:35: Warning: Defined but not used: data constructor ‘Inh_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1287:63: Warning: Defined but not used: ‘cat_Inh_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1287:105: Warning: Defined but not used: ‘flags_Inh_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1287:159: Warning: Defined but not used: ‘imCast_Inh_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1288:35: Warning: Defined but not used: data constructor ‘Syn_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1288:63: Warning: Defined but not used: ‘annotatedTree_Syn_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1288:130: Warning: Defined but not used: ‘originalTree_Syn_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1292:1: Warning: Defined but not used: ‘wrap_AlterDatabaseOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1451:29: Warning: Defined but not used: data constructor ‘Inh_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1451:51: Warning: Defined but not used: ‘cat_Inh_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1451:87: Warning: Defined but not used: ‘flags_Inh_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1451:135: Warning: Defined but not used: ‘imCast_Inh_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1452:29: Warning: Defined but not used: data constructor ‘Syn_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1452:51: Warning: Defined but not used: ‘annotatedTree_Syn_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1452:106: Warning: Defined but not used: ‘originalTree_Syn_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1456:1: Warning: Defined but not used: ‘wrap_AlterTableAction’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1832:33: Warning: Defined but not used: data constructor ‘Inh_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1832:59: Warning: Defined but not used: ‘cat_Inh_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1832:99: Warning: Defined but not used: ‘flags_Inh_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1832:151: Warning: Defined but not used: ‘imCast_Inh_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1833:33: Warning: Defined but not used: data constructor ‘Syn_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1833:59: Warning: Defined but not used: ‘annotatedTree_Syn_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1833:122: Warning: Defined but not used: ‘originalTree_Syn_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:1837:1: Warning: Defined but not used: ‘wrap_AlterTableActionList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2005:32: Warning: Defined but not used: data constructor ‘Inh_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2005:57: Warning: Defined but not used: ‘cat_Inh_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2005:96: Warning: Defined but not used: ‘flags_Inh_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2005:147: Warning: Defined but not used: ‘imCast_Inh_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2006:32: Warning: Defined but not used: data constructor ‘Syn_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2006:57: Warning: Defined but not used: ‘annotatedTree_Syn_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2006:118: Warning: Defined but not used: ‘originalTree_Syn_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2010:1: Warning: Defined but not used: ‘wrap_AlterTableOperation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2320:23: Warning: Defined but not used: data constructor ‘Inh_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2320:39: Warning: Defined but not used: ‘cat_Inh_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2320:69: Warning: Defined but not used: ‘flags_Inh_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2320:111: Warning: Defined but not used: ‘imCast_Inh_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2320:154: Warning: Defined but not used: ‘tpe_Inh_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2321:23: Warning: Defined but not used: data constructor ‘Syn_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2321:39: Warning: Defined but not used: ‘annotatedTree_Syn_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2321:82: Warning: Defined but not used: ‘originalTree_Syn_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2325:1: Warning: Defined but not used: ‘wrap_Annotation’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2385:25: Warning: Defined but not used: data constructor ‘Inh_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2385:43: Warning: Defined but not used: ‘cat_Inh_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2385:75: Warning: Defined but not used: ‘flags_Inh_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2385:119: Warning: Defined but not used: ‘imCast_Inh_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2386:25: Warning: Defined but not used: data constructor ‘Syn_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2386:43: Warning: Defined but not used: ‘annotatedTree_Syn_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2386:90: Warning: Defined but not used: ‘originalTree_Syn_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2390:1: Warning: Defined but not used: ‘wrap_AttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2593:29: Warning: Defined but not used: data constructor ‘Inh_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2593:51: Warning: Defined but not used: ‘cat_Inh_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2593:87: Warning: Defined but not used: ‘flags_Inh_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2593:135: Warning: Defined but not used: ‘imCast_Inh_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2594:29: Warning: Defined but not used: data constructor ‘Syn_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2594:51: Warning: Defined but not used: ‘annotatedTree_Syn_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2594:106: Warning: Defined but not used: ‘originalTree_Syn_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2598:1: Warning: Defined but not used: ‘wrap_AttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2755:45: Warning: Defined but not used: data constructor ‘Inh_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2755:83: Warning: Defined but not used: ‘cat_Inh_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2755:135: Warning: Defined but not used: ‘downEnv_Inh_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2755:195: Warning: Defined but not used: ‘flags_Inh_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2755:259: Warning: Defined but not used: ‘imCast_Inh_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2755:324: Warning: Defined but not used: ‘thenExpectedType_Inh_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2755:399: Warning: Defined but not used: ‘whenExpectedType_Inh_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2756:45: Warning: Defined but not used: data constructor ‘Syn_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2756:83: Warning: Defined but not used: ‘annotatedTree_Syn_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2756:170: Warning: Defined but not used: ‘originalTree_Syn_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2756:256: Warning: Defined but not used: ‘thenType_Syn_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2756:323: Warning: Defined but not used: ‘upTypes_Syn_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2756:391: Warning: Defined but not used: ‘whenTypes_Syn_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2760:1: Warning: Defined but not used: ‘wrap_CaseScalarExprListScalarExprPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2958:49: Warning: Defined but not used: data constructor ‘Inh_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2958:91: Warning: Defined but not used: ‘cat_Inh_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2958:147: Warning: Defined but not used: ‘downEnv_Inh_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2958:211: Warning: Defined but not used: ‘flags_Inh_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2958:279: Warning: Defined but not used: ‘imCast_Inh_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2958:348: Warning: Defined but not used: ‘thenExpectedType_Inh_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2958:427: Warning: Defined but not used: ‘whenExpectedType_Inh_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2959:49: Warning: Defined but not used: data constructor ‘Syn_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2959:91: Warning: Defined but not used: ‘annotatedTree_Syn_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2959:186: Warning: Defined but not used: ‘originalTree_Syn_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2959:280: Warning: Defined but not used: ‘thenTypes_Syn_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2959:354: Warning: Defined but not used: ‘upTypes_Syn_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2959:426: Warning: Defined but not used: ‘whenTypes_Syn_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:2963:1: Warning: Defined but not used: ‘wrap_CaseScalarExprListScalarExprPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3243:23: Warning: Defined but not used: data constructor ‘Inh_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3243:39: Warning: Defined but not used: ‘cat_Inh_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3243:69: Warning: Defined but not used: ‘flags_Inh_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3243:111: Warning: Defined but not used: ‘imCast_Inh_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3244:23: Warning: Defined but not used: data constructor ‘Syn_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3244:39: Warning: Defined but not used: ‘annotatedTree_Syn_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3244:82: Warning: Defined but not used: ‘originalTree_Syn_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3248:1: Warning: Defined but not used: ‘wrap_Constraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3636:27: Warning: Defined but not used: data constructor ‘Inh_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3636:47: Warning: Defined but not used: ‘cat_Inh_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3636:81: Warning: Defined but not used: ‘flags_Inh_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3636:127: Warning: Defined but not used: ‘imCast_Inh_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3637:27: Warning: Defined but not used: data constructor ‘Syn_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3637:47: Warning: Defined but not used: ‘annotatedTree_Syn_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3637:98: Warning: Defined but not used: ‘originalTree_Syn_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3641:1: Warning: Defined but not used: ‘wrap_ConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3799:19: Warning: Defined but not used: data constructor ‘Inh_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3799:31: Warning: Defined but not used: ‘cat_Inh_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3799:57: Warning: Defined but not used: ‘flags_Inh_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3799:95: Warning: Defined but not used: ‘imCast_Inh_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3800:19: Warning: Defined but not used: data constructor ‘Syn_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3800:31: Warning: Defined but not used: ‘annotatedTree_Syn_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3800:66: Warning: Defined but not used: ‘originalTree_Syn_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:3804:1: Warning: Defined but not used: ‘wrap_FnBody’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4037:19: Warning: Defined but not used: data constructor ‘Inh_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4037:31: Warning: Defined but not used: ‘cat_Inh_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4037:57: Warning: Defined but not used: ‘downEnv_Inh_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4037:91: Warning: Defined but not used: ‘expectedCast_Inh_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4037:123: Warning: Defined but not used: ‘expectedType_Inh_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4037:168: Warning: Defined but not used: ‘flags_Inh_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4037:206: Warning: Defined but not used: ‘imCast_Inh_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4038:19: Warning: Defined but not used: data constructor ‘Syn_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4038:31: Warning: Defined but not used: ‘annotatedTree_Syn_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4038:66: Warning: Defined but not used: ‘listType_Syn_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4038:120: Warning: Defined but not used: ‘originalTree_Syn_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4042:1: Warning: Defined but not used: ‘wrap_InList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4347:21: Warning: Defined but not used: data constructor ‘Inh_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4347:35: Warning: Defined but not used: ‘cat_Inh_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4347:63: Warning: Defined but not used: ‘downEnv_Inh_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4347:99: Warning: Defined but not used: ‘flags_Inh_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4347:139: Warning: Defined but not used: ‘imCast_Inh_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4348:21: Warning: Defined but not used: data constructor ‘Syn_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4348:35: Warning: Defined but not used: ‘annotatedTree_Syn_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4348:74: Warning: Defined but not used: ‘originalTree_Syn_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4352:1: Warning: Defined but not used: ‘wrap_JoinExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4586:26: Warning: Defined but not used: data constructor ‘Inh_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4586:45: Warning: Defined but not used: ‘cat_Inh_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4586:78: Warning: Defined but not used: ‘downEnv_Inh_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4586:119: Warning: Defined but not used: ‘flags_Inh_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4586:164: Warning: Defined but not used: ‘imCast_Inh_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4587:26: Warning: Defined but not used: data constructor ‘Syn_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4587:45: Warning: Defined but not used: ‘annotatedTree_Syn_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4587:94: Warning: Defined but not used: ‘originalTree_Syn_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4591:1: Warning: Defined but not used: ‘wrap_MaybeBoolExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4720:1: Warning: Defined but not used: ‘sem_MaybeNameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4726:35: Warning: Defined but not used: data constructor ‘Inh_MaybeNameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4727:35: Warning: Defined but not used: data constructor ‘Syn_MaybeNameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4731:1: Warning: Defined but not used: ‘wrap_MaybeNameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4732:10: Warning: This pattern-binding binds no variables: () = sem hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4736:1: Warning: Defined but not used: ‘sem_MaybeNameComponentList_Just’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4736:33: Warning: Defined but not used: ‘just_’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4740:1: Warning: Defined but not used: ‘sem_MaybeNameComponentList_Nothing’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4784:28: Warning: Defined but not used: data constructor ‘Inh_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4784:49: Warning: Defined but not used: ‘cat_Inh_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4784:84: Warning: Defined but not used: ‘downEnv_Inh_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4784:127: Warning: Defined but not used: ‘expectedCast_Inh_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4784:168: Warning: Defined but not used: ‘expectedType_Inh_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4784:222: Warning: Defined but not used: ‘flags_Inh_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4784:269: Warning: Defined but not used: ‘imCast_Inh_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4785:28: Warning: Defined but not used: data constructor ‘Syn_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4785:49: Warning: Defined but not used: ‘annotatedTree_Syn_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4785:102: Warning: Defined but not used: ‘originalTree_Syn_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4785:154: Warning: Defined but not used: ‘upType_Syn_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4789:1: Warning: Defined but not used: ‘wrap_MaybeScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4959:28: Warning: Defined but not used: data constructor ‘Inh_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4959:49: Warning: Defined but not used: ‘cat_Inh_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4959:84: Warning: Defined but not used: ‘flags_Inh_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4959:131: Warning: Defined but not used: ‘imCast_Inh_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4960:28: Warning: Defined but not used: data constructor ‘Syn_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4960:49: Warning: Defined but not used: ‘annotatedTree_Syn_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4960:102: Warning: Defined but not used: ‘originalTree_Syn_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:4964:1: Warning: Defined but not used: ‘wrap_MaybeSelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5115:35: Warning: Defined but not used: data constructor ‘Inh_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5115:63: Warning: Defined but not used: ‘cat_Inh_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5115:105: Warning: Defined but not used: ‘flags_Inh_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5115:159: Warning: Defined but not used: ‘imCast_Inh_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5116:35: Warning: Defined but not used: data constructor ‘Syn_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5116:63: Warning: Defined but not used: ‘annotatedTree_Syn_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5116:130: Warning: Defined but not used: ‘originalTree_Syn_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5120:1: Warning: Defined but not used: ‘wrap_MaybeTablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5253:17: Warning: Defined but not used: data constructor ‘Inh_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5253:27: Warning: Defined but not used: ‘cat_Inh_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5253:51: Warning: Defined but not used: ‘flags_Inh_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5253:87: Warning: Defined but not used: ‘imCast_Inh_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5253:124: Warning: Defined but not used: ‘tpe_Inh_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5254:17: Warning: Defined but not used: data constructor ‘Syn_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5254:27: Warning: Defined but not used: ‘annotatedTree_Syn_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5254:58: Warning: Defined but not used: ‘originalTree_Syn_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5258:1: Warning: Defined but not used: ‘wrap_Name’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5374:1: Warning: Defined but not used: ‘sem_NameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5378:30: Warning: Defined but not used: data constructor ‘Inh_NameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5379:30: Warning: Defined but not used: data constructor ‘Syn_NameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5383:1: Warning: Defined but not used: ‘wrap_NameComponentList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5384:10: Warning: This pattern-binding binds no variables: () = sem hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5389:1: Warning: Defined but not used: ‘sem_NameComponentList_Cons’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5389:28: Warning: Defined but not used: ‘hd_’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5389:32: Warning: Defined but not used: ‘tl_’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5393:1: Warning: Defined but not used: ‘sem_NameComponentList_Nil’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5425:33: Warning: Defined but not used: data constructor ‘Inh_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5425:59: Warning: Defined but not used: ‘cat_Inh_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5425:99: Warning: Defined but not used: ‘flags_Inh_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5425:151: Warning: Defined but not used: ‘imCast_Inh_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5426:33: Warning: Defined but not used: data constructor ‘Syn_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5426:59: Warning: Defined but not used: ‘annotatedTree_Syn_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5426:122: Warning: Defined but not used: ‘originalTree_Syn_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5430:1: Warning: Defined but not used: ‘wrap_NameTypeNameListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5557:37: Warning: Defined but not used: data constructor ‘Inh_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5557:67: Warning: Defined but not used: ‘cat_Inh_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5557:111: Warning: Defined but not used: ‘flags_Inh_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5557:167: Warning: Defined but not used: ‘imCast_Inh_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5558:37: Warning: Defined but not used: data constructor ‘Syn_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5558:67: Warning: Defined but not used: ‘annotatedTree_Syn_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5558:138: Warning: Defined but not used: ‘originalTree_Syn_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5562:1: Warning: Defined but not used: ‘wrap_NameTypeNameListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5717:19: Warning: Defined but not used: data constructor ‘Inh_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5717:31: Warning: Defined but not used: ‘cat_Inh_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5717:57: Warning: Defined but not used: ‘downEnv_Inh_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5717:91: Warning: Defined but not used: ‘flags_Inh_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5717:129: Warning: Defined but not used: ‘imCast_Inh_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5718:19: Warning: Defined but not used: data constructor ‘Syn_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5718:31: Warning: Defined but not used: ‘annotatedTree_Syn_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5718:66: Warning: Defined but not used: ‘originalTree_Syn_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5722:1: Warning: Defined but not used: ‘wrap_OnExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5864:21: Warning: Defined but not used: data constructor ‘Inh_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5864:35: Warning: Defined but not used: ‘cat_Inh_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5864:63: Warning: Defined but not used: ‘flags_Inh_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5864:103: Warning: Defined but not used: ‘imCast_Inh_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5865:21: Warning: Defined but not used: data constructor ‘Syn_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5865:35: Warning: Defined but not used: ‘annotatedTree_Syn_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5865:74: Warning: Defined but not used: ‘originalTree_Syn_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:5869:1: Warning: Defined but not used: ‘wrap_ParamDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6090:25: Warning: Defined but not used: data constructor ‘Inh_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6090:43: Warning: Defined but not used: ‘cat_Inh_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6090:75: Warning: Defined but not used: ‘flags_Inh_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6090:119: Warning: Defined but not used: ‘imCast_Inh_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6091:25: Warning: Defined but not used: data constructor ‘Syn_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6091:43: Warning: Defined but not used: ‘annotatedTree_Syn_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6091:90: Warning: Defined but not used: ‘originalTree_Syn_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6095:1: Warning: Defined but not used: ‘wrap_ParamDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6324:22: Warning: Defined but not used: data constructor ‘Inh_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6324:37: Warning: Defined but not used: ‘cat_Inh_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6324:66: Warning: Defined but not used: ‘expectedType_Inh_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6324:116: Warning: Defined but not used: ‘flags_Inh_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6324:157: Warning: Defined but not used: ‘imCast_Inh_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6324:199: Warning: Defined but not used: ‘outerDownEnv_Inh_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6325:22: Warning: Defined but not used: data constructor ‘Syn_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6325:37: Warning: Defined but not used: ‘annotatedTree_Syn_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6325:78: Warning: Defined but not used: ‘originalTree_Syn_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6325:118: Warning: Defined but not used: ‘upType_Syn_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:6329:1: Warning: Defined but not used: ‘wrap_QueryExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7235:58: Warning: Defined but not used: ‘originalTree_Syn_Root’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7389:26: Warning: Defined but not used: data constructor ‘Inh_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7389:45: Warning: Defined but not used: ‘cat_Inh_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7389:78: Warning: Defined but not used: ‘flags_Inh_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7389:123: Warning: Defined but not used: ‘imCast_Inh_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7390:26: Warning: Defined but not used: data constructor ‘Syn_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7390:45: Warning: Defined but not used: ‘annotatedTree_Syn_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7390:94: Warning: Defined but not used: ‘originalTree_Syn_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7394:1: Warning: Defined but not used: ‘wrap_RowConstraint’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7978:30: Warning: Defined but not used: data constructor ‘Inh_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7978:53: Warning: Defined but not used: ‘cat_Inh_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7978:90: Warning: Defined but not used: ‘flags_Inh_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7978:139: Warning: Defined but not used: ‘imCast_Inh_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7979:30: Warning: Defined but not used: data constructor ‘Syn_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7979:53: Warning: Defined but not used: ‘annotatedTree_Syn_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7979:110: Warning: Defined but not used: ‘originalTree_Syn_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:7983:1: Warning: Defined but not used: ‘wrap_RowConstraintList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8482:23: Warning: Defined but not used: data constructor ‘Inh_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8482:39: Warning: Defined but not used: ‘cat_Inh_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8482:69: Warning: Defined but not used: ‘downEnv_Inh_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8482:107: Warning: Defined but not used: ‘expectedCast_Inh_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8482:143: Warning: Defined but not used: ‘expectedType_Inh_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8482:192: Warning: Defined but not used: ‘flags_Inh_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8482:234: Warning: Defined but not used: ‘imCast_Inh_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8483:23: Warning: Defined but not used: data constructor ‘Syn_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8483:39: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8483:82: Warning: Defined but not used: ‘colExprs_Syn_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8483:156: Warning: Defined but not used: ‘originalTree_Syn_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8483:198: Warning: Defined but not used: ‘upType_Syn_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:8487:1: Warning: Defined but not used: ‘wrap_ScalarExpr’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13383:36: Warning: Defined but not used: data constructor ‘Inh_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13383:65: Warning: Defined but not used: ‘cat_Inh_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13383:108: Warning: Defined but not used: ‘downEnv_Inh_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13383:159: Warning: Defined but not used: ‘flags_Inh_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13383:214: Warning: Defined but not used: ‘imCast_Inh_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13384:36: Warning: Defined but not used: data constructor ‘Syn_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13384:65: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13384:134: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13388:1: Warning: Defined but not used: ‘wrap_ScalarExprDirectionPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13509:40: Warning: Defined but not used: data constructor ‘Inh_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13509:73: Warning: Defined but not used: ‘cat_Inh_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13509:120: Warning: Defined but not used: ‘downEnv_Inh_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13509:175: Warning: Defined but not used: ‘flags_Inh_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13509:234: Warning: Defined but not used: ‘imCast_Inh_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13510:40: Warning: Defined but not used: data constructor ‘Syn_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13510:73: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13510:150: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13514:1: Warning: Defined but not used: ‘wrap_ScalarExprDirectionPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13689:27: Warning: Defined but not used: data constructor ‘Inh_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13689:47: Warning: Defined but not used: ‘cat_Inh_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13689:81: Warning: Defined but not used: ‘downEnv_Inh_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13689:123: Warning: Defined but not used: ‘expectedCast_Inh_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13689:163: Warning: Defined but not used: ‘expectedTypes_Inh_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13689:213: Warning: Defined but not used: ‘flags_Inh_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13689:259: Warning: Defined but not used: ‘imCast_Inh_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13690:27: Warning: Defined but not used: data constructor ‘Syn_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13690:47: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13690:98: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13690:148: Warning: Defined but not used: ‘upTypes_Syn_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13694:1: Warning: Defined but not used: ‘wrap_ScalarExprList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13914:31: Warning: Defined but not used: data constructor ‘Inh_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13914:55: Warning: Defined but not used: ‘cat_Inh_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13914:93: Warning: Defined but not used: ‘downEnv_Inh_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13914:139: Warning: Defined but not used: ‘expectedCast_Inh_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13914:183: Warning: Defined but not used: ‘expectedType_Inh_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13914:242: Warning: Defined but not used: ‘flags_Inh_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13914:292: Warning: Defined but not used: ‘imCast_Inh_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13915:31: Warning: Defined but not used: data constructor ‘Syn_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13915:55: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13915:114: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13915:172: Warning: Defined but not used: ‘upType_Syn_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:13919:1: Warning: Defined but not used: ‘wrap_ScalarExprListList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14139:44: Warning: Defined but not used: data constructor ‘Inh_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14139:81: Warning: Defined but not used: ‘cat_Inh_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14139:132: Warning: Defined but not used: ‘flags_Inh_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14139:195: Warning: Defined but not used: ‘imCast_Inh_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14140:44: Warning: Defined but not used: data constructor ‘Syn_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14140:81: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14140:166: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14144:1: Warning: Defined but not used: ‘wrap_ScalarExprListStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14286:48: Warning: Defined but not used: data constructor ‘Inh_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14286:89: Warning: Defined but not used: ‘cat_Inh_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14286:144: Warning: Defined but not used: ‘flags_Inh_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14286:211: Warning: Defined but not used: ‘imCast_Inh_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14287:48: Warning: Defined but not used: data constructor ‘Syn_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14287:89: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14287:182: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14291:1: Warning: Defined but not used: ‘wrap_ScalarExprListStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14440:98: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprRoot’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14557:40: Warning: Defined but not used: data constructor ‘Inh_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14557:73: Warning: Defined but not used: ‘cat_Inh_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14557:120: Warning: Defined but not used: ‘flags_Inh_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14557:179: Warning: Defined but not used: ‘imCast_Inh_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14558:40: Warning: Defined but not used: data constructor ‘Syn_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14558:73: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14558:150: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14562:1: Warning: Defined but not used: ‘wrap_ScalarExprStatementListPair’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14705:44: Warning: Defined but not used: data constructor ‘Inh_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14705:81: Warning: Defined but not used: ‘cat_Inh_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14705:132: Warning: Defined but not used: ‘flags_Inh_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14705:195: Warning: Defined but not used: ‘imCast_Inh_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14706:44: Warning: Defined but not used: data constructor ‘Syn_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14706:81: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14706:166: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14710:1: Warning: Defined but not used: ‘wrap_ScalarExprStatementListPairList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14867:37: Warning: Defined but not used: data constructor ‘Inh_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14867:67: Warning: Defined but not used: ‘cat_Inh_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14867:111: Warning: Defined but not used: ‘expectedCast_Inh_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14867:161: Warning: Defined but not used: ‘expectedType_Inh_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14867:226: Warning: Defined but not used: ‘flags_Inh_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14867:282: Warning: Defined but not used: ‘imCast_Inh_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14868:37: Warning: Defined but not used: data constructor ‘Syn_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14868:67: Warning: Defined but not used: ‘annotatedTree_Syn_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14868:138: Warning: Defined but not used: ‘originalTree_Syn_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14868:208: Warning: Defined but not used: ‘upType_Syn_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:14872:1: Warning: Defined but not used: ‘wrap_ScalarExprTransposedList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15094:23: Warning: Defined but not used: data constructor ‘Inh_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15094:39: Warning: Defined but not used: ‘cat_Inh_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15094:69: Warning: Defined but not used: ‘downEnv_Inh_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15094:107: Warning: Defined but not used: ‘expectedCast_Inh_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15094:143: Warning: Defined but not used: ‘expectedType_Inh_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15094:192: Warning: Defined but not used: ‘flags_Inh_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15094:234: Warning: Defined but not used: ‘imCast_Inh_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15095:23: Warning: Defined but not used: data constructor ‘Syn_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15095:39: Warning: Defined but not used: ‘annotatedTree_Syn_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15095:82: Warning: Defined but not used: ‘colExprs_Syn_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15095:156: Warning: Defined but not used: ‘originalTree_Syn_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15099:1: Warning: Defined but not used: ‘wrap_SelectItem’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15403:27: Warning: Defined but not used: data constructor ‘Inh_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15403:47: Warning: Defined but not used: ‘cat_Inh_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15403:81: Warning: Defined but not used: ‘downEnv_Inh_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15403:123: Warning: Defined but not used: ‘expectedCast_Inh_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15403:163: Warning: Defined but not used: ‘expectedType_Inh_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15403:218: Warning: Defined but not used: ‘flags_Inh_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15403:264: Warning: Defined but not used: ‘imCast_Inh_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15404:27: Warning: Defined but not used: data constructor ‘Syn_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15404:47: Warning: Defined but not used: ‘annotatedTree_Syn_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15404:98: Warning: Defined but not used: ‘colExprs_Syn_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15404:176: Warning: Defined but not used: ‘originalTree_Syn_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15404:226: Warning: Defined but not used: ‘upEnv_Syn_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15404:266: Warning: Defined but not used: ‘upType_Syn_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15408:1: Warning: Defined but not used: ‘wrap_SelectItemList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15688:23: Warning: Defined but not used: data constructor ‘Inh_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15688:39: Warning: Defined but not used: ‘cat_Inh_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15688:69: Warning: Defined but not used: ‘downEnv_Inh_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15688:107: Warning: Defined but not used: ‘expectedCast_Inh_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15688:143: Warning: Defined but not used: ‘expectedType_Inh_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15688:194: Warning: Defined but not used: ‘flags_Inh_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15688:236: Warning: Defined but not used: ‘imCast_Inh_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15689:23: Warning: Defined but not used: data constructor ‘Syn_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15689:39: Warning: Defined but not used: ‘annotatedTree_Syn_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15689:82: Warning: Defined but not used: ‘colExprs_Syn_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15689:156: Warning: Defined but not used: ‘originalTree_Syn_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15689:198: Warning: Defined but not used: ‘upEnv_Syn_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15689:234: Warning: Defined but not used: ‘upType_Syn_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15693:1: Warning: Defined but not used: ‘wrap_SelectList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15876:22: Warning: Defined but not used: data constructor ‘Inh_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15876:37: Warning: Defined but not used: ‘cat_Inh_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15876:66: Warning: Defined but not used: ‘flags_Inh_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15876:107: Warning: Defined but not used: ‘imCast_Inh_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15877:22: Warning: Defined but not used: data constructor ‘Syn_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15877:37: Warning: Defined but not used: ‘annotatedTree_Syn_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15877:78: Warning: Defined but not used: ‘originalTree_Syn_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:15881:1: Warning: Defined but not used: ‘wrap_SetClause’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16147:26: Warning: Defined but not used: data constructor ‘Inh_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16147:45: Warning: Defined but not used: ‘cat_Inh_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16147:78: Warning: Defined but not used: ‘flags_Inh_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16147:123: Warning: Defined but not used: ‘imCast_Inh_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16148:26: Warning: Defined but not used: data constructor ‘Syn_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16148:45: Warning: Defined but not used: ‘annotatedTree_Syn_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16148:94: Warning: Defined but not used: ‘originalTree_Syn_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16152:1: Warning: Defined but not used: ‘wrap_SetClauseList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16862:22: Warning: Defined but not used: data constructor ‘Inh_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16862:37: Warning: Defined but not used: ‘cat_Inh_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16862:66: Warning: Defined but not used: ‘flags_Inh_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16862:107: Warning: Defined but not used: ‘imCast_Inh_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16863:22: Warning: Defined but not used: data constructor ‘Syn_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16863:37: Warning: Defined but not used: ‘annotatedTree_Syn_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16863:78: Warning: Defined but not used: ‘originalTree_Syn_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:16867:1: Warning: Defined but not used: ‘wrap_Statement’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23092:26: Warning: Defined but not used: data constructor ‘Inh_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23092:45: Warning: Defined but not used: ‘cat_Inh_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23092:78: Warning: Defined but not used: ‘flags_Inh_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23092:123: Warning: Defined but not used: ‘imCast_Inh_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23093:26: Warning: Defined but not used: data constructor ‘Syn_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23093:45: Warning: Defined but not used: ‘annotatedTree_Syn_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23093:94: Warning: Defined but not used: ‘originalTree_Syn_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23097:1: Warning: Defined but not used: ‘wrap_StatementList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23248:30: Warning: Defined but not used: data constructor ‘Inh_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23248:53: Warning: Defined but not used: ‘cat_Inh_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23248:90: Warning: Defined but not used: ‘flags_Inh_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23248:139: Warning: Defined but not used: ‘imCast_Inh_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23249:30: Warning: Defined but not used: data constructor ‘Syn_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23249:53: Warning: Defined but not used: ‘annotatedTree_Syn_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23249:110: Warning: Defined but not used: ‘originalTree_Syn_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23253:1: Warning: Defined but not used: ‘wrap_TablePartitionDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23429:21: Warning: Defined but not used: data constructor ‘Inh_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23429:35: Warning: Defined but not used: ‘cat_Inh_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23429:63: Warning: Defined but not used: ‘flags_Inh_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23429:103: Warning: Defined but not used: ‘imCast_Inh_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23430:21: Warning: Defined but not used: data constructor ‘Syn_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23430:35: Warning: Defined but not used: ‘annotatedTree_Syn_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23430:74: Warning: Defined but not used: ‘originalTree_Syn_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23430:112: Warning: Defined but not used: ‘upEnv_Syn_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:23434:1: Warning: Defined but not used: ‘wrap_TableRef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24450:25: Warning: Defined but not used: data constructor ‘Inh_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24450:43: Warning: Defined but not used: ‘cat_Inh_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24450:75: Warning: Defined but not used: ‘flags_Inh_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24450:119: Warning: Defined but not used: ‘imCast_Inh_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24451:25: Warning: Defined but not used: data constructor ‘Syn_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24451:43: Warning: Defined but not used: ‘annotatedTree_Syn_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24451:90: Warning: Defined but not used: ‘originalTree_Syn_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24451:136: Warning: Defined but not used: ‘upEnv_Syn_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24455:1: Warning: Defined but not used: ‘wrap_TableRefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24625:29: Warning: Defined but not used: data constructor ‘Inh_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24625:51: Warning: Defined but not used: ‘cat_Inh_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24625:87: Warning: Defined but not used: ‘flags_Inh_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24625:135: Warning: Defined but not used: ‘imCast_Inh_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24626:29: Warning: Defined but not used: data constructor ‘Syn_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24626:51: Warning: Defined but not used: ‘annotatedTree_Syn_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24626:106: Warning: Defined but not used: ‘originalTree_Syn_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24630:1: Warning: Defined but not used: ‘wrap_TypeAttributeDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24759:33: Warning: Defined but not used: data constructor ‘Inh_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24759:59: Warning: Defined but not used: ‘cat_Inh_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24759:99: Warning: Defined but not used: ‘flags_Inh_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24759:151: Warning: Defined but not used: ‘imCast_Inh_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24760:33: Warning: Defined but not used: data constructor ‘Syn_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24760:59: Warning: Defined but not used: ‘annotatedTree_Syn_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24760:122: Warning: Defined but not used: ‘originalTree_Syn_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24764:1: Warning: Defined but not used: ‘wrap_TypeAttributeDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24958:21: Warning: Defined but not used: data constructor ‘Inh_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24958:35: Warning: Defined but not used: ‘cat_Inh_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24958:63: Warning: Defined but not used: ‘flags_Inh_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24958:103: Warning: Defined but not used: ‘imCast_Inh_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24959:21: Warning: Defined but not used: data constructor ‘Syn_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24959:35: Warning: Defined but not used: ‘annotatedTree_Syn_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24959:74: Warning: Defined but not used: ‘namedType_Syn_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24959:118: Warning: Defined but not used: ‘originalTree_Syn_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:24963:1: Warning: Defined but not used: ‘wrap_TypeName’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25556:25: Warning: Defined but not used: data constructor ‘Inh_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25556:43: Warning: Defined but not used: ‘cat_Inh_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25556:75: Warning: Defined but not used: ‘flags_Inh_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25556:119: Warning: Defined but not used: ‘imCast_Inh_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25557:25: Warning: Defined but not used: data constructor ‘Syn_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25557:43: Warning: Defined but not used: ‘annotatedTree_Syn_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25557:90: Warning: Defined but not used: ‘originalTree_Syn_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25561:1: Warning: Defined but not used: ‘wrap_TypeNameList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25733:19: Warning: Defined but not used: data constructor ‘Inh_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25733:31: Warning: Defined but not used: ‘cat_Inh_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25733:57: Warning: Defined but not used: ‘flags_Inh_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25733:95: Warning: Defined but not used: ‘imCast_Inh_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25734:19: Warning: Defined but not used: data constructor ‘Syn_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25734:31: Warning: Defined but not used: ‘annotatedTree_Syn_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25734:66: Warning: Defined but not used: ‘originalTree_Syn_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:25738:1: Warning: Defined but not used: ‘wrap_VarDef’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26034:23: Warning: Defined but not used: data constructor ‘Inh_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26034:39: Warning: Defined but not used: ‘cat_Inh_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26034:69: Warning: Defined but not used: ‘flags_Inh_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26034:111: Warning: Defined but not used: ‘imCast_Inh_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26035:23: Warning: Defined but not used: data constructor ‘Syn_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26035:39: Warning: Defined but not used: ‘annotatedTree_Syn_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26035:82: Warning: Defined but not used: ‘originalTree_Syn_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26039:1: Warning: Defined but not used: ‘wrap_VarDefList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26190:22: Warning: Defined but not used: data constructor ‘Inh_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26190:37: Warning: Defined but not used: ‘cat_Inh_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26190:66: Warning: Defined but not used: ‘flags_Inh_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26190:107: Warning: Defined but not used: ‘imCast_Inh_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26191:22: Warning: Defined but not used: data constructor ‘Syn_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26191:37: Warning: Defined but not used: ‘annotatedTree_Syn_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26191:78: Warning: Defined but not used: ‘originalTree_Syn_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26195:1: Warning: Defined but not used: ‘wrap_WithQuery’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26339:26: Warning: Defined but not used: data constructor ‘Inh_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26339:45: Warning: Defined but not used: ‘cat_Inh_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26339:78: Warning: Defined but not used: ‘flags_Inh_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26339:123: Warning: Defined but not used: ‘imCast_Inh_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26340:26: Warning: Defined but not used: data constructor ‘Syn_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26340:45: Warning: Defined but not used: ‘annotatedTree_Syn_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26340:94: Warning: Defined but not used: ‘originalTree_Syn_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/AstInternal.hs:26344:1: Warning: Defined but not used: ‘wrap_WithQueryList’ hssqlppp/src/Database/HsSqlPpp/Internals/TypeChecking/TypeChecking.ag:75:38: Warning: Fields of ‘Inh_ScalarExprRoot’ not initialised: downEnv_Inh_ScalarExprRoot In the second argument of ‘wrap_ScalarExprRoot’, namely ‘Inh_ScalarExprRoot {cat_Inh_ScalarExprRoot = cat, flags_Inh_ScalarExprRoot = f}’ In the first argument of ‘annotatedTree_Syn_ScalarExprRoot’, namely ‘(wrap_ScalarExprRoot t (Inh_ScalarExprRoot {cat_Inh_ScalarExprRoot = cat, flags_Inh_ScalarExprRoot = f}))’ In the expression: (annotatedTree_Syn_ScalarExprRoot (wrap_ScalarExprRoot t (Inh_ScalarExprRoot {cat_Inh_ScalarExprRoot = cat, flags_Inh_ScalarExprRoot = f}))) hssqlppp/src/Database/HsSqlPpp/Internals/TypeChecking/TypeChecking.ag:260:1: Warning: Tab character hssqlppp/src/Database/HsSqlPpp/Internals/TypeChecking/TypeChecking.ag:261:1: Warning: Tab character hssqlppp/src/Database/HsSqlPpp/Internals/TypeChecking/TypeChecking.ag:262:1: Warning: Tab character hssqlppp/src/Database/HsSqlPpp/Internals/TypeChecking/TypeChecking.ag:268:1: Warning: Tab character hssqlppp/src/Database/HsSqlPpp/Internals/TypeChecking/TypeChecking.ag:269:1: Warning: Tab character hssqlppp/src/Database/HsSqlPpp/Internals/TypeChecking/TypeChecking.ag:270:1: Warning: Tab character src/Database/HsSqlPpp/Internals/AstInternal.hs:119:1: Warning: The import of ‘Control.Applicative’ is redundant except perhaps to import instances from ‘Control.Applicative’ To import instances alone, use: import Control.Applicative() [17 of 23] Compiling Database.HsSqlPpp.Annotation ( src/Database/HsSqlPpp/Annotation.lhs, dist/build/Database/HsSqlPpp/Annotation.o ) [18 of 23] Compiling Database.HsSqlPpp.TypeChecker ( src/Database/HsSqlPpp/TypeChecker.lhs, dist/build/Database/HsSqlPpp/TypeChecker.o ) [19 of 23] Compiling Database.HsSqlPpp.Ast ( src/Database/HsSqlPpp/Ast.lhs, dist/build/Database/HsSqlPpp/Ast.o ) [20 of 23] Compiling Database.HsSqlPpp.Parsing.ParserInternal ( src/Database/HsSqlPpp/Parsing/ParserInternal.lhs, dist/build/Database/HsSqlPpp/Parsing/ParserInternal.o ) src/Database/HsSqlPpp/Parsing/ParserInternal.lhs:38:3: Warning: The import of ‘Control.Applicative’ is redundant except perhaps to import instances from ‘Control.Applicative’ To import instances alone, use: import Control.Applicative() [21 of 23] Compiling Database.HsSqlPpp.Parser ( src/Database/HsSqlPpp/Parser.lhs, dist/build/Database/HsSqlPpp/Parser.o ) [22 of 23] Compiling Database.HsSqlPpp.Utility ( src/Database/HsSqlPpp/Utility.lhs, dist/build/Database/HsSqlPpp/Utility.o ) [23 of 23] Compiling Database.HsSqlPpp.Pretty ( src/Database/HsSqlPpp/Pretty.lhs, dist/build/Database/HsSqlPpp/Pretty.o ) src/Database/HsSqlPpp/Pretty.lhs:103:3: Warning: Pattern match(es) are non-exhaustive In an equation for ‘statement’: Patterns not matched: _ _ _ (CreateUser _ _ _) _ _ _ (CreateLogin _ _ _) _ _ _ (AlterUser _ _ _) _ _ _ (AlterLogin _ _ _) src/Database/HsSqlPpp/Pretty.lhs:781:31: Warning: Pattern match(es) are overlapped In a case alternative: _ -> ... In-place registering hssqlppp-0.5.18... real 9m3.447s user 12m19.704s sys 3m25.724s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler